From owner-disman@dorothy.peer.com Mon Jul 3 15:15:08 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 PAA06516 for ; Mon, 3 Jul 2000 15:15:08 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e63J8uF01620; Mon, 3 Jul 2000 14:08:57 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA29834 for disman-list; Mon, 3 Jul 2000 12:04:51 -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 MAA29828; Mon, 3 Jul 2000 12:04:47 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e63J5SF01407; Mon, 3 Jul 2000 14:05:28 -0500 (CDT) Received: from ramk-95.cisco.com (ramk-dsl4.cisco.com [10.19.11.157]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id MAA05347; Mon, 3 Jul 2000 12:05:21 -0700 (PDT) Message-Id: <4.1.20000703114438.00a10d20@sigma.cisco.com> X-Sender: ramk@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 03 Jul 2000 12:07:12 -0700 To: Randy Presuhn , bwijnen@lucent.com, rpresuhn@dorothy.peer.com From: "Ramanathan R. Kavasseri" Subject: RE: reminder: disman docs for "proposed" Cc: Disman@dorothy.peer.com In-Reply-To: <200006081909.MAA19062@Dorothy.Bmc.Com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list At 12:09 PM 6/8/00 -0700, Randy Presuhn wrote: > >Hi - > >> Message-ID: ><2413FED0DFE6D111B3F90008C7FA61FB07992DF8@nl0006exch002u.nl.lucent.com> >> From: "Wijnen, Bert (Bert)" >> To: ramk@cisco.com, Randy Presuhn >> Cc: Disman@dorothy.peer.com >> Subject: RE: reminder: disman docs for "proposed" >> Date: Thu, 8 Jun 2000 13:46:07 +0200 >> List-Id: IETF disman Working Group mailing list >... >> Before I do the IETF Last Call, I would indeed want to see >> the SMIv2 errors fixed. Other typo fixes can go along with >> them, but they can also be done at a later time. >> I would also prefer to fix SMI compile warnings if possible. >... > >This is fine with me. In addition to the fixes Frank has >identified (which are fine with me), here are the other typos >and potential IETF last-call issues that I've become aware of: > [...snipped out other items which I've done already...] >technical issue, discussed at WG meetings but not reflected >in document: >18) draft-ietf-disman-notif-log-mib-16.txt> pages 4/5 > Heirarchically structured log names have been repeatedly > shown to have subtle pitfalls. The approach the draft > recommends can produce surprises when the first subid of > the second index looks like punctuation, etc. For example, > with { nlmLogName, nlmLogIndex, nlmLogVariableIndex > }, nlmLogIndex could have the same value as "-", and > nlmLogVariableIndex could match a particular subgroup > name, thus (inappropriately) granting access Alas, Pittsburgh will be the first time I attend a disman WG meeting :-( So I'm unaware of what was the agreed upon change. Can someone send the proposed change to me? >editorial omission: >21) draft-ietf-disman-notif-log-mib-16.txt> page 24: what > is the condition for notificationLogDateGroup? [*] Couldn't follow what was wrong here? Thanks, Ram From owner-disman@dorothy.peer.com Mon Jul 3 20:45:19 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 UAA08722 for ; Mon, 3 Jul 2000 20:45:18 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e5UKHoh13218; Fri, 30 Jun 2000 15:17:50 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA15086 for disman-list; Fri, 30 Jun 2000 13:06:53 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA15080 for disman@dorothy.bmc.com; Fri, 30 Jun 2000 13:06:50 -0700 (PDT) Date: Fri, 30 Jun 2000 13:06:50 -0700 (PDT) From: Randy Presuhn Message-Id: <200006302006.NAA15080@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: test of disman list 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 - test, please ignore ------------------------------------------------------- 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 Jul 4 12:24:02 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28810 for ; Tue, 4 Jul 2000 12:24:02 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e64GMWW00355; Tue, 4 Jul 2000 11:22:33 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA02766 for disman-list; Tue, 4 Jul 2000 09:20:24 -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 JAA02761 for ; Tue, 4 Jul 2000 09:20:20 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e64GL1W00227 for ; Tue, 4 Jul 2000 11:21:01 -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 RAA23607; Tue, 4 Jul 2000 17:50:15 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA23718; Tue, 4 Jul 2000 17:50:09 +0200 Date: Tue, 4 Jul 2000 17:50:09 +0200 Message-Id: <200007041550.RAA23718@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: DISMAN Mailing List Subject: script mib suspend/resume issue Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list While working on the RFC 2592 revision, I ran into another interesting question. I tried to add a description of the suspend / resume operations to section 7. The interesting thing here is that the MIB does not require suspend/resume capabilities in a language runtime. So the procedure has to work correctly in all cases - regardless whether suspend/resume is supported or not. RFC 2592 says in the compliance statement the an implementation which is told to suspend a script but which is unable to do so will put the script into the suspending state until it either terminates or the managers gives the command to resume the script. The implication of this is that a manager can not figure out whether a script can be suspended or not. Setting smRunControl to `suspend' and then polling smRunState until the script is really suspended does not work (unless you invent some strange timeouts). Strawman: Change the compliance definition such that implementations which are unable to suspend a script keep the script in the executing state. This allows to set smRunControl to `suspend' and to poll smRunState until it either contains `running' or `suspended'. Comments? /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 Jul 4 13:28:27 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 NAA29310 for ; Tue, 4 Jul 2000 13:28:22 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e64HOoW10366; Tue, 4 Jul 2000 12:24:51 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA02993 for disman-list; Tue, 4 Jul 2000 10:23:22 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA02985 for ; Tue, 4 Jul 2000 10:22:53 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e64HNTW09983 for ; Tue, 4 Jul 2000 12:23:31 -0500 (CDT) Received: from ramk-95.cisco.com (ramk-dsl4.cisco.com [10.19.11.157]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id IAA17253; Tue, 4 Jul 2000 08:14:58 -0700 (PDT) Message-Id: <4.1.20000704081307.00a60ec0@sigma.cisco.com> X-Sender: ramk@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 04 Jul 2000 08:17:00 -0700 To: internet-drafts@ietf.org From: "Ramanathan R. Kavasseri" Subject: Re: draft-ietf-disman-event-mib-10.txt Cc: disman@dorothy.peer.com In-Reply-To: <200006291624.JAA12617@itech-view2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Hi, I'd submittied draft-ietf-disman-event-mib-10.txt for posting as an I-D last Thursday. I can't find it posted yet. Is this due to some technical problems with the draft, or are they in the process of being posted? Please let us know when this draft will be posted, and whether anything further is to be done. Note: I posted draft-ietf-disman-expr-mib-12.txt last Thursday as well, and it hasn't been posted yet. Could you let me know the status of this MIB as well? Thanks, Ram At 09:24 AM 6/29/00 -0700, Ram Kavasseri wrote: > >Please accept drafte-ietf-disman-event-mib-10.txt for posting >sa an interent draft. This draft contains changes to fix typos, >formatting issues etc. > >Thank you, > >Ram Kavasseri > > > > > > > > >Network Working Group Editor of this version: >Internet-Draft Ramanathan R. Kavasseri >Expires December 2000 Cisco Systems, Inc. > Author of previous version: > Bob Stewart > 7 June 2000 > > > > Event MIB > > draft-ietf-disman-event-mib-10.txt > > > 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. > >Distribution of this document is unlimited. Please send comments to the >Distributed Management Working Group, . > > >Copyright Notice > >Copyright (C) The Internet Society (2000). All Rights Reserved. > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > >1. Abstract > >This memo defines an experimental 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. > > >The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >document are to be interpreted as described in RFC 2119. > > >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], RFC 2579 [RFC2579] and 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 > > > > > >Expires 7 December 2000 [Page 2] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > 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. It may not be possible to meaningfully monitor Counter64 objects > using an SMIv1 version of the MIB. > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 3] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > >3. Overview > >With network sizes well beyond the ability of people to manage them >directly, automated, distributed management is vital. An important >aspect of such management is the ability of a system to monitor itself >or for some other system to monitor it. > >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. > >The MIB is intended to suit either a relatively powerful manager or mid- >level manager, as well as a somewhat more limited self-managing system. > > >4. Relationship to Other MIBs > >The Event MIB is based on extensive experience with the RMON MIB >[RFC1757] and provides a superset of the capabilities of the RMON alarm >and event groups. Conceptually, the key extension is the ability to >allow alarms to be generated for MIB objects that are on another network >element. The Event MIB calls "triggers" what the RMON MIB called >"alarms," but the concepts are the same. Event MIB triggers maintain >the RMON handling of thresholds and add the concept of booleans. Event >MIB events maintain the RMON concept of sending an SNMP notification in >response to a trigger and add the concept of setting a MIB object. > >The Event MIB is the successor and update to SNMPv2's Manager-to-Manager >MIB [RFC1451] which was declared Historic pending this work. > >The Event MIB depends on the services of the SNMPv3 Management Target >and Notification MIBs [RFC2573]. > >The Event MIB is nicely complemented by the Distributed Management >Expression MIB [RFCExpressionMIB], which is the expected source of >boolean objects to monitor. Note that there is considerable overlap >between the wildcard and delta sample capabilities of the Event and >Expression MIBs. A carefully-planned implementation might well use >common code to provide the overlapping functions. > > >5. MIB Sections > >The MIB has four sections: triggers, objects, events, and notifications. >Triggers define the conditions that lead to events. Events may cause > > > > > >Expires 7 December 2000 [Page 4] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > >notifications. > >The trigger table lists what objects are to be monitored and how and >relates each trigger to an event. It has supplementary, companion >tables for additional objects that depend on the type of test done for >the trigger. > >The objects table lists objects that can be added to notifications based >on the trigger, the trigger test type, or the event that resulted in the >notification. > >The event table defines what happens when an event is triggered: sending >a notification, setting a MIB object or both. It has supplementary, >companion tables for additional objects that depend on the action taken. > >The notification section defines a set of generic notifications to go >with the events and for Event MIB error handling, and it defines a set >of objects to put in those notifications. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 5] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > >The following diagram describes the relationships between the tables >in the Event MIB. > > >+-----------------------------+ >| mteTriggerEntry | subclassed by: >| { mteOwner, |---+ >| IMPLIED mteTriggerName } | +-- mteTriggerDeltaEntry >| | | >| | +-- mteTriggerExistenceEntry >| | | >| | +-- mteTriggerBooleanEntry >| | | >| | +-- mteTriggerThresholdEntry >| | >| mteTrigger*Event -------------------------------->+ >| | | >| mteTriggerObjects ------------------>+ | >+-----------------------------+ | | > | | >+-----------------------------+ V | >| mteObjectsEntry | | | >| { mteOwner, |<-------------+ | >| mteObjectsName, | | >| mteObjectsIndex } | | >+-----------------------------+ | > V >+---------------------------+ | >| mteEventEntry |<----------------------------+ >| { mteOwner, | >| IMPLIED mteEventName } | >| | >| mteEventAction---> + (condition) >+---------------------------+ | > V >+---------------------------+ | +---------------------------+ >| mteEventNotificationEntry | | | mteEventSetEntry | >| { mteOwner, |<--+-->| { mteOwner, | >| IMPLIED mteEventName } | | IMPLIED mteEventName } | >+---------------------------+ +---------------------------+ > > > > > > > > > > >Expires 7 December 2000 [Page 6] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > >6. Operation > >The Event MIB is instrumentation for a distributed management >application that monitors MIB objects. In its simplest form this >application monitors individual, local MIB objects, just as an RMON >probe fulfills the functions implied by RMON's alarm and event >operation. Additionally the application can monitor remote objects and >wildcarded groups of objects. > >Remote monitoring uses the tag service of the Management Target MIB >[RFC2573] to select and access remote systems as an ordinary SNMP-based >management application. Local monitoring may be via a more intimate, >local interface which may, for example, bypass SNMP encoding but >otherwise is functionally identical to remote SNMP operation, including >the application of access control. A self-management only system MAY >not implement remote monitoring. > >Wildcards indicate that the application SHOULD use a GetNext-type >operation to find the zero or more instances implied by a truncated >object identifier, just like an ordinary SNMP-based management >application. Each instance of a wildcard is treated as if it were a >separate entry, that is the instances of a wildcarded object are >independent of one another. For example, a wild-carded object may >trigger an event, and result in the setting of another wildcarded >object. The instance that satisfied the trigger function is used to >perform the set function. All of this takes place independently of any >additional instances that may fill the wildcard. > >Error handling is by notification. These error notifications SHOULD be >enabled only for the diagnosis of problems indicated by error counters. >If minimizing the probability of notification loss is a concern they >SHOULD be transmitted as Inform PDUs as described in the [SNMP-TARGET- >MIB] or directed to a log as described in the Notification Log MIB >[rfcNotificationLogMIB]. Note that this does not mean the Notification >Log MIB is REQUIRED, since in fact notifications usually are not lost, >but that the Notification Log MIB can be helpful with this as well as >other MIBs that include notifications. > >Although like most MIBs this one has no explicit controls for the >persistence of the values set in configuring events, a robust, polite >implementation would certainly not force its managing applications to >reconfigure it whenever it resets. > >Again, as with most MIBs, it is implementation-specific how a system >provides and manages such persistence. To speculate, one could imagine, > > > > > >Expires 7 December 2000 [Page 7] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > >for example, that persistence depended on the context in which the >expression was configured, or perhaps system-specific characteristics of >the expression's owner. Or perhaps everything in a MIB such as this >one, which is clearly aimed at persistent configuration, is >automatically part of a system's other persistent configuration. > > >7. Security > >Security of Event MIB entries depends on SNMPv3 access control for the >entire MIB or for subsets based on entry owner names. > >Security of monitored objects for remote access depends on the >Management Target MIB [RFC2573]. Security for local access can depend >on the Management Target MIB or on recording appropriate security >credentials of the creator of an entry and using those to access the >local objects. These security credentials are the parameters necessary >as inputs to isAccessAllowed from the Architecture for Describing SNMP >Management Frameworks. When accessing local objects without using a >local target tag, the system MUST (conceptually) use isAccessAllowed to >ensure that it does not violate security. > >To facilitate the provisioning of access control by a security >administrator for this MIB itself using the View-Based Access Control >Model (VACM) defined in RFC 2275 [RFC2575] for tables in which multiple >users may need to independently create or modify entries, the initial >index is used as an "owner index". Such an initial index has a syntax of >SnmpAdminString, and can thus be trivially mapped to a securityName or >groupName as defined in VACM, in accordance with a security policy. > >If a security administrator were to employ such an approach, all entries >in related tables belonging to a particular user will have the same >value for this initial index. For a given user's entries in a >particular table, the object identifiers for the information in these >entries will have the same sub-identifiers (except for the "column" sub- >identifier) up to the end of the encoded owner index. To configure VACM >to permit access to this portion of the table, one would create >vacmViewTreeFamilyTable entries with the value of >vacmViewTreeFamilySubtree including the owner index portion, and >vacmViewTreeFamilyMask "wildcarding" the column sub-identifier. More >elaborate configurations are possible. > > > > > > > > > >Expires 7 December 2000 [Page 8] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > >8. Definitions > >DISMAN-EVENT-MIB DEFINITIONS ::= BEGIN > >IMPORTS > MODULE-IDENTITY, OBJECT-TYPE, > Integer32, Unsigned32, > NOTIFICATION-TYPE, Counter32, > Gauge32, mib-2, zeroDotZero FROM SNMPv2-SMI > TEXTUAL-CONVENTION, RowStatus, > TruthValue FROM SNMPv2-TC > MODULE-COMPLIANCE, OBJECT-GROUP, > NOTIFICATION-GROUP FROM SNMPv2-CONF > sysUpTime FROM SNMPv2-MIB > SnmpTagValue FROM SNMP-TARGET-MIB > SnmpAdminString FROM SNMP-FRAMEWORK-MIB; > >dismanEventMIB MODULE-IDENTITY > LAST-UPDATED "200006070000Z" -- 7 June 2000 > ORGANIZATION "IETF Distributed Management Working Group" > CONTACT-INFO "Ramanathan Kavasseri > Cisco Systems, Inc. > 170 West Tasman Drive, > San Jose CA 95134-1706. > Phone: +1 408 526 4527 > Email: ramk@cisco.com" > DESCRIPTION > "The MIB module for defining event triggers and actions > for network management purposes." >-- Revision History > > REVISION "200006070000Z" -- 7 June 2000 > DESCRIPTION "This is the initial version of this MIB. > Published as RFC xxxx" > ::= { mib-2 xx } -- final assignment by IANA at publication time > >dismanEventMIBObjects OBJECT IDENTIFIER ::= { dismanEventMIB 1 } > >-- Management Triggered Event (MTE) objects > >mteResource OBJECT IDENTIFIER ::= { dismanEventMIBObjects 1 } >mteTrigger OBJECT IDENTIFIER ::= { dismanEventMIBObjects 2 } >mteObjects OBJECT IDENTIFIER ::= { dismanEventMIBObjects 3 } >mteEvent OBJECT IDENTIFIER ::= { dismanEventMIBObjects 4 } > > > > > > >Expires 7 December 2000 [Page 9] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > >-- >-- Textual Conventions >-- > >FailureReason ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "Reasons for failures in an attempt to perform a management > request. > > The first group of errors, numbered less than 0, are related > to problems in sending the request. The existence of a > particular error code here does not imply that all > implementations are capable of sensing that error and > returning that code. > > The second group, numbered greater than 0, are copied > directly from SNMP protocol operations and are intended to > carry exactly the meanings defined for the protocol as returned > in an SNMP response. > > localResourceLack some local resource such as memory lacking > or mteResourceSampleInstanceMaximum > exceeded > badDestination unrecognized domain name or otherwise > invalid destination address > destinationUnreachable can't get to destination address > noResponse no response to SNMP request > badType the data syntax of a retrieved object > as not as expected > sampleOverrun another sample attempt occurred before > the previous one completed" > > SYNTAX INTEGER { localResourceLack(-1), > badDestination(-2), > destinationUnreachable(-3), > noResponse(-4), > badType(-5), > sampleOverrun(-6), > > noError(0), > > tooBig(1), > noSuchName(2), > badValue(3), > > > > > >Expires 7 December 2000 [Page 10] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > readOnly(4), > genErr(5), > noAccess(6), > wrongType(7), > wrongLength(8), > wrongEncoding(9), > wrongValue(10), > noCreation(11), > inconsistentValue(12), > resourceUnavailable(13), > commitFailed(14), > undoFailed(15), > authorizationError(16), > notWritable(17), > inconsistentName(18) } >-- >-- Resource Control Section >-- > >mteResourceSampleMinimum OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > UNITS "seconds" > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The minimum mteTriggerFrequency this system will > accept. A system may use the larger values of this minimum to > lessen the impact of constant sampling. For larger > sampling intervals the system samples less often and > suffers less overhead. This object provides a way to enforce > such lower overhead for all triggers created after it is > set. > > Unless explicitly resource limited, a system's value for > this object SHOULD be 1, allowing as small as a 1 second > interval for ongoing trigger sampling. > > Changing this value will not invalidate an existing setting > of mteTriggerFrequency." > ::= { mteResource 1 } > >mteResourceSampleInstanceMaximum OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "instances" > MAX-ACCESS read-write > > > > > >Expires 7 December 2000 [Page 11] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > STATUS current > DESCRIPTION > "The maximum number of instance entries this system will > support for sampling. > > These are the entries that maintain state, one for each > instance of each sampled object as selected by > mteTriggerValueID. Note that wildcarded objects result > in multiple instances of this state. > > A value of 0 indicates no preset limit, that is, the limit > is dynamic based on system operation and resources. > > Unless explicitly resource limited, a system's value for > this object SHOULD be 0. > > Changing this value will not eliminate or inhibit existing > sample state but could prevent allocation of additional state > information." > ::= { mteResource 2 } > >mteResourceSampleInstances OBJECT-TYPE > SYNTAX Gauge32 > UNITS "instances" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of currently active instance entries as > defined for mteResourceSampleInstanceMaximum." > ::= { mteResource 3 } > >mteResourceSampleInstancesHigh OBJECT-TYPE > SYNTAX Gauge32 > UNITS "instances" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The highest value of mteResourceSampleInstances that has > occurred since initialization of the management system." > ::= { mteResource 4 } > >mteResourceSampleInstanceLacks OBJECT-TYPE > SYNTAX Counter32 > UNITS "instances" > MAX-ACCESS read-only > > > > > >Expires 7 December 2000 [Page 12] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > STATUS current > DESCRIPTION > "The number of times this system could not take a new sample > because that allocation would have exceeded the limit set by > mteResourceSampleInstanceMaximum." > ::= { mteResource 5 } > > >-- >-- Trigger Section >-- > >-- Counters > >mteTriggerFailures OBJECT-TYPE > SYNTAX Counter32 > UNITS "failures" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of times an attempt to check for a trigger > condition has failed. This counts individually for each > attempt in a group of targets or each attempt for a > wildcarded object." > ::= { mteTrigger 1 } > > >-- >-- Trigger Table >-- > >mteTriggerTable OBJECT-TYPE > SYNTAX SEQUENCE OF MteTriggerEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of management event trigger information." > ::= { mteTrigger 2 } > >mteTriggerEntry OBJECT-TYPE > SYNTAX MteTriggerEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about a single trigger. Applications create and > > > > > >Expires 7 December 2000 [Page 13] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > delete entries using mteTriggerEntryStatus." > INDEX { mteOwner, IMPLIED mteTriggerName } > ::= { mteTriggerTable 1 } > >MteTriggerEntry ::= SEQUENCE { > mteOwner SnmpAdminString, > mteTriggerName SnmpAdminString, > mteTriggerComment SnmpAdminString, > mteTriggerTest BITS, > mteTriggerSampleType INTEGER, > mteTriggerValueID OBJECT IDENTIFIER, > mteTriggerValueIDWildcard TruthValue, > mteTriggerTargetTag SnmpTagValue, > mteTriggerContextName SnmpAdminString, > mteTriggerContextNameWildcard TruthValue, > mteTriggerFrequency Unsigned32, > mteTriggerObjectsOwner SnmpAdminString, > mteTriggerObjects SnmpAdminString, > mteTriggerEnabled TruthValue, > mteTriggerEntryStatus RowStatus >} > >mteOwner OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE(0..32)) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The owner of this entry. The exact semantics of this > string are subject to the security policy defined by the > security administrator." > ::= { mteTriggerEntry 1 } > >mteTriggerName OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (1..32)) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A locally-unique, administratively assigned name for the > trigger within the scope of mteOwner." > ::= { mteTriggerEntry 2 } > >mteTriggerComment OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-create > STATUS current > > > > > >Expires 7 December 2000 [Page 14] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > DESCRIPTION > "A description of the trigger's function and use." > DEFVAL { ''H } > ::= { mteTriggerEntry 3 } > >mteTriggerTest OBJECT-TYPE > SYNTAX BITS { existence(0), boolean(1), threshold(2) } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The type of trigger test to perform. For 'boolean' and > 'threshold' tests, the object at mteTriggerValueID MUST > evaluate to an integer, that is, anything that ends up encoded > for transmission (that is, in BER, not ASN.1) as an integer. > > For 'existence', the specific test is as selected by > mteTriggerExistenceTest. When an object appears, vanishes > or changes value, the trigger fires. If the object's > appearance caused the trigger firing, the object MUST > vanish before the trigger can be fired again for it, and > vice versa. If the trigger fired due to a change in the > object's value, it will be fired again on every successive > value change for that object. > > For 'boolean', the specific test is as selected by > mteTriggerBooleanTest. If the test result is true the trigger > fires. The trigger will not fire again until the value has > become false and come back to true. > > For 'threshold' the test works as described below for > mteTriggerThresholdStartup, mteTriggerThresholdRising, and > mteTriggerThresholdFalling. > > Note that combining 'boolean' and 'threshold' tests on the > same object may be somewhat redundant." > DEFVAL { { boolean } } > ::= { mteTriggerEntry 4 } > >mteTriggerSampleType OBJECT-TYPE > SYNTAX INTEGER { absoluteValue(1), deltaValue(2) } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The type of sampling to perform. > > > > > > >Expires 7 December 2000 [Page 15] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > An 'absoluteValue' sample requires only a single sample to be > meaningful, and is exactly the value of the object at > mteTriggerValueID at the sample time. > > A 'deltaValue' requires two samples to be meaningful and is > thus not available for testing until the second and subsequent > samples after the object at mteTriggerValueID is first found > to exist. It is the difference between the two samples. For > unsigned values it is always positive, based on unsigned > arithmetic. For signed values it can be positive or negative. > > For SNMP counters to be meaningful they should be sampled as a > 'deltaValue'. > > For 'deltaValue' mteTriggerDeltaTable contains further > parameters. > > If only 'existence' is set in mteTriggerTest this object has > no meaning." > DEFVAL { absoluteValue } > ::= { mteTriggerEntry 5 } > >mteTriggerValueID OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The object identifier of the MIB object to sample to see > if the trigger should fire. > > This may be wildcarded by truncating all or part of the > instance portion, in which case the value is obtained > as if with a GetNext function, checking multiple values > if they exist. If such wildcarding is applied, > mteTriggerValueIDWildcard must be 'true' and if not it must > be 'false'. > > Bad object identifiers or a mismatch between truncating the > identifier and the value of mteTriggerValueIDWildcard result > in operation as one would expect when providing the wrong > identifier to a Get or GetNext operation. The Get will fail > or get the wrong object. The GetNext will indeed get whatever > is next, proceeding until it runs past the initial part of the > identifier and perhaps many unintended objects for confusing > results. If the value syntax of those objects is not usable, > > > > > >Expires 7 December 2000 [Page 16] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > that results in a 'badType' error that terminates the scan. > > Each instance that fills the wildcard is independent of any > additional instances, that is, wildcarded objects operate > as if there were a separate table entry for each instance > that fills the wildcard without having to actually predict > all possible instances ahead of time." > DEFVAL { zeroDotZero } > ::= { mteTriggerEntry 6 } > >mteTriggerValueIDWildcard OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Control for whether mteTriggerValueID is to be treated as > fully-specified or wildcarded, with 'true' indicating wildcard." > DEFVAL { false } > ::= { mteTriggerEntry 7 } > >mteTriggerTargetTag OBJECT-TYPE > SYNTAX SnmpTagValue > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The tag for the target(s) from which to obtain the condition > for a trigger check. > > A length of 0 indicates the local system. In this case, > access to the objects indicated by mteTriggerValueID is under > the security credentials of the requester that set > mteTriggerEntryStatus to 'active'. Those credentials are the > input parameters for isAccessAllowed from the Architecture for > Describing SNMP Management Frameworks. > > Otherwise access rights are checked according to the security > parameters resulting from the tag." > DEFVAL { ''H } > ::= { mteTriggerEntry 8 } > >mteTriggerContextName OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-create > STATUS current > DESCRIPTION > > > > > >Expires 7 December 2000 [Page 17] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > "The management context from which to obtain mteTriggerValueID. > > This may be wildcarded by leaving characters off the end. For > example use 'Repeater' to wildcard to 'Repeater1', > 'Repeater2', 'Repeater-999.87b', and so on. To indicate such > wildcarding is intended, mteTriggerContextNameWildcard must > be 'true'. > > Each instance that fills the wildcard is independent of any > additional instances, that is, wildcarded objects operate > as if there were a separate table entry for each instance > that fills the wildcard without having to actually predict > all possible instances ahead of time. > > Operation of this feature assumes that the local system has a > list of available contexts against which to apply the > wildcard. If the objects are being read from the local > system, this is clearly the system's own list of contexts. > For a remote system a local version of such a list is not > defined by any current standard and may not be available, so > this function MAY not be supported." > DEFVAL { ''H } > ::= { mteTriggerEntry 9 } > >mteTriggerContextNameWildcard OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Control for whether mteTriggerContextName is to be treated as > fully-specified or wildcarded, with 'true' indicating wildcard." > DEFVAL { false } > ::= { mteTriggerEntry 10 } > >mteTriggerFrequency OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "seconds" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The number of seconds to wait between trigger samples. To > encourage consistency in sampling, the interval is measured > from the beginning of one check to the beginning of the next > and the timer is restarted immediately when it expires, not > when the check completes. > > > > > >Expires 7 December 2000 [Page 18] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > If the next sample begins before the previous one completed the > system may either attempt to make the check or treat this as an > error condition with the error 'sampleOverrun'. > > A frequency of 0 indicates instantaneous recognition of the > condition. This is not possible in many cases, but may > be supported in cases where it makes sense and the system is > able to do so. This feature allows the MIB to be used in > implementations where such interrupt-driven behavior is > possible and is not likely to be supported for all MIB objects > even then since such sampling generally has to be tightly > integrated into low-level code. > > Systems that can support this SHOULD document those cases > where it can be used. In cases where it can not, setting this > object to 0 should be disallowed." > DEFVAL { 600 } > ::= { mteTriggerEntry 11 } > >mteTriggerObjectsOwner OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "To go with mteTriggerObjects, the mteOwner of a group of > objects from mteObjectsTable." > DEFVAL { ''H } > ::= { mteTriggerEntry 12 } > >mteTriggerObjects OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The mteObjectsName of a group of objects from > mteObjectsTable. These objects are to be added to any > Notification resulting from the firing of this trigger. > > A list of objects may also be added based on the event or on > the value of mteTriggerTest. > > A length of 0 indicates no additional objects." > DEFVAL { ''H } > ::= { mteTriggerEntry 13 } > > > > > > >Expires 7 December 2000 [Page 19] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > >mteTriggerEnabled OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "A control to allow a trigger to be configured but not used. > When the value is 'false' the trigger is not sampled." > DEFVAL { false } > ::= { mteTriggerEntry 14 } > >mteTriggerEntryStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The control that allows creation and deletion of entries. > Once made active an entry may not be modified except to > delete it." > ::= { mteTriggerEntry 15 } > > >-- >-- Trigger Delta Table >-- > >mteTriggerDeltaTable OBJECT-TYPE > SYNTAX SEQUENCE OF MteTriggerDeltaEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of management event trigger information for delta > sampling." > ::= { mteTrigger 3 } > >mteTriggerDeltaEntry OBJECT-TYPE > SYNTAX MteTriggerDeltaEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about a single trigger's delta sampling. Entries > automatically exist in this this table for each mteTriggerEntry > that has mteTriggerSampleType set to 'deltaValue'." > INDEX { mteOwner, IMPLIED mteTriggerName } > ::= { mteTriggerDeltaTable 1 } > > > > > > >Expires 7 December 2000 [Page 20] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > >MteTriggerDeltaEntry ::= SEQUENCE { > mteTriggerDeltaDiscontinuityID OBJECT IDENTIFIER, > mteTriggerDeltaDiscontinuityIDWildcard TruthValue, > mteTriggerDeltaDiscontinuityIDType INTEGER >} > > >sysUpTimeInstance OBJECT IDENTIFIER ::= { sysUpTime 0 } > >mteTriggerDeltaDiscontinuityID OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The OBJECT IDENTIFIER (OID) of a TimeTicks, TimeStamp, or > DateAndTime object that indicates a discontinuity in the value > at mteTriggerValueID. > > The OID may be for a leaf object (e.g. sysUpTime.0) or may > be wildcarded to match mteTriggerValueID. > > This object supports normal checking for a discontinuity in a > counter. Note that if this object does not point to sysUpTime > discontinuity checking MUST still check sysUpTime for an overall > discontinuity. > > If the object identified is not accessible the sample attempt > is in error, with the error code as from an SNMP request. > > Bad object identifiers or a mismatch between truncating the > identifier and the value of mteDeltaDiscontinuityIDWildcard > result in operation as one would expect when providing the > wrong identifier to a Get operation. The Get will fail or get > the wrong object. If the value syntax of those objects is not > usable, that results in an error that terminates the sample > with a 'badType' error code." > DEFVAL { sysUpTimeInstance } > ::= { mteTriggerDeltaEntry 1 } > >mteTriggerDeltaDiscontinuityIDWildcard OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Control for whether mteTriggerDeltaDiscontinuityID is to be > > > > > >Expires 7 December 2000 [Page 21] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > treated as fully-specified or wildcarded, with 'true' > indicating wildcard. Note that the value of this object will > be the same as that of the corresponding instance of > mteTriggerValueIDWildcard when the corresponding > mteTriggerSampleType is 'deltaValue'." > DEFVAL { false } > ::= { mteTriggerDeltaEntry 2 } > >mteTriggerDeltaDiscontinuityIDType OBJECT-TYPE > SYNTAX INTEGER { timeTicks(1), timeStamp(2), dateAndTime(3) } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The value 'timeTicks' indicates the > mteTriggerDeltaDiscontinuityID of this row is of syntax > TimeTicks. The value 'timeStamp' indicates syntax TimeStamp. > The value 'dateAndTime' indicates syntax DateAndTime." > DEFVAL { timeTicks } > ::= { mteTriggerDeltaEntry 3 } > > >-- >-- Trigger Existence Table >-- > >mteTriggerExistenceTable OBJECT-TYPE > SYNTAX SEQUENCE OF MteTriggerExistenceEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of management event trigger information for existence > triggers." > ::= { mteTrigger 4 } > >mteTriggerExistenceEntry OBJECT-TYPE > SYNTAX MteTriggerExistenceEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about a single existence trigger. Entries > automatically exist in this this table for each mteTriggerEntry > that has 'existence' set in mteTriggerTest." > INDEX { mteOwner, IMPLIED mteTriggerName } > ::= { mteTriggerExistenceTable 1 } > > > > > > >Expires 7 December 2000 [Page 22] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > >MteTriggerExistenceEntry ::= SEQUENCE { > mteTriggerExistenceTest BITS, > mteTriggerExistenceStartup BITS, > mteTriggerExistenceObjectsOwner SnmpAdminString, > mteTriggerExistenceObjects SnmpAdminString, > mteTriggerExistenceEventOwner SnmpAdminString, > mteTriggerExistenceEvent SnmpAdminString >} > >mteTriggerExistenceTest OBJECT-TYPE > SYNTAX BITS { present(0), absent(1), changed(2) } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The type of existence test to perform. The trigger fires > when the object at mteTriggerValueID is seen to go from > present to absent, from absent to present, or to have it's > value changed, depending on which tests are selected: > > present(0) - when this test is selected, the trigger fires > when the mteTriggerValueID object goes from absent to present. > > absent(1) - when this test is selected, the trigger fires > when the mteTriggerValueID object goes from present to absent. > changed(2) - when this test is selected, the trigger fires > the mteTriggerValueID object value changes. > > Once the trigger has fired for either presence or absence it > will not fire again for that state until the object has been > to the other state. " > DEFVAL { { present, absent } } > ::= { mteTriggerExistenceEntry 1 } > >mteTriggerExistenceStartup OBJECT-TYPE > SYNTAX BITS { present(0), absent(1) } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Control for whether an event may be triggered when this entry > is first set to 'active' and the test specified by > mteTriggerExistenceTest is true. Setting an option causes > that trigger to fire when its test is true." > DEFVAL { { present, absent } } > ::= { mteTriggerExistenceEntry 2 } > > > > > > >Expires 7 December 2000 [Page 23] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > >mteTriggerExistenceObjectsOwner OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "To go with mteTriggerExistenceObjects, the mteOwner of a > group of objects from mteObjectsTable." > DEFVAL { ''H } > ::= { mteTriggerExistenceEntry 3 } > >mteTriggerExistenceObjects OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The mteObjectsName of a group of objects from > mteObjectsTable. These objects are to be added to any > Notification resulting from the firing of this trigger for > this test. > > A list of objects may also be added based on the overall > trigger, the event or other settings in mteTriggerTest. > > A length of 0 indicates no additional objects." > DEFVAL { ''H } > ::= { mteTriggerExistenceEntry 4 } > >mteTriggerExistenceEventOwner OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "To go with mteTriggerExistenceEvent, the mteOwner of an event > entry from the mteEventTable." > DEFVAL { ''H } > ::= { mteTriggerExistenceEntry 5 } > >mteTriggerExistenceEvent OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The mteEventName of the event to invoke when mteTriggerType is > 'existence' and this trigger fires. A length of 0 indicates no > event." > > > > > >Expires 7 December 2000 [Page 24] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > DEFVAL { ''H } > ::= { mteTriggerExistenceEntry 6 } > > >-- >-- Trigger Boolean Table >-- > >mteTriggerBooleanTable OBJECT-TYPE > SYNTAX SEQUENCE OF MteTriggerBooleanEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of management event trigger information for boolean > triggers." > ::= { mteTrigger 5 } > >mteTriggerBooleanEntry OBJECT-TYPE > SYNTAX MteTriggerBooleanEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about a single boolean trigger. Entries > automatically exist in this this table for each mteTriggerEntry > that has 'boolean' set in mteTriggerTest." > INDEX { mteOwner, IMPLIED mteTriggerName } > ::= { mteTriggerBooleanTable 1 } > >MteTriggerBooleanEntry ::= SEQUENCE { > mteTriggerBooleanComparison INTEGER, > mteTriggerBooleanValue Integer32, > mteTriggerBooleanStartup TruthValue, > mteTriggerBooleanObjectsOwner SnmpAdminString, > mteTriggerBooleanObjects SnmpAdminString, > mteTriggerBooleanEventOwner SnmpAdminString, > mteTriggerBooleanEvent SnmpAdminString >} > >mteTriggerBooleanComparison OBJECT-TYPE > SYNTAX INTEGER { unequal(1), equal(2), > less(3), lessOrEqual(4), > greater(5), greaterOrEqual(6) } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > > > > > >Expires 7 December 2000 [Page 25] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > "The type of boolean comparison to perform. > > The value at mteTriggerValueID is compared to > mteTriggerBooleanValue, so for example if > mteTriggerBooleanComparison is 'less' the result would be true > if the value at mteTriggerValueID is less than the value of > mteTriggerBooleanValue." > DEFVAL { unequal } > ::= { mteTriggerBooleanEntry 1 } > >mteTriggerBooleanValue OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The value to use for the test specified by > mteTriggerBooleanTest." > DEFVAL { 0 } > ::= { mteTriggerBooleanEntry 2 } > >mteTriggerBooleanStartup OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Control for whether an event may be triggered when this entry > is first set to 'active' or a new instance of the object at > mteTriggerValueID is found and the test specified by > mteTriggerBooleanComparison is true. In that case an event is > triggered if mteTriggerBooleanStartup is 'true'." > DEFVAL { true } > ::= { mteTriggerBooleanEntry 3 } > >mteTriggerBooleanObjectsOwner OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "To go with mteTriggerBooleanObjects, the mteOwner of a group > of objects from mteObjectsTable." > DEFVAL { ''H } > ::= { mteTriggerBooleanEntry 4 } > >mteTriggerBooleanObjects OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > > > > > >Expires 7 December 2000 [Page 26] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The mteObjectsName of a group of objects from > mteObjectsTable. These objects are to be added to any > Notification resulting from the firing of this trigger for > this test. > > A list of objects may also be added based on the overall > trigger, the event or other settings in mteTriggerTest. > > A length of 0 indicates no additional objects." > DEFVAL { ''H } > ::= { mteTriggerBooleanEntry 5 } > >mteTriggerBooleanEventOwner OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "To go with mteTriggerBooleanEvent, the mteOwner of an event > entry from mteEventTable." > DEFVAL { ''H } > ::= { mteTriggerBooleanEntry 6 } > >mteTriggerBooleanEvent OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The mteEventName of the event to invoke when mteTriggerType is > 'boolean' and this trigger fires. A length of 0 indicates no > event." > DEFVAL { ''H } > ::= { mteTriggerBooleanEntry 7 } > > >-- >-- Trigger Threshold Table >-- > >mteTriggerThresholdTable OBJECT-TYPE > SYNTAX SEQUENCE OF MteTriggerThresholdEntry > MAX-ACCESS not-accessible > STATUS current > > > > > >Expires 7 December 2000 [Page 27] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > DESCRIPTION > "A table of management event trigger information for threshold > triggers." > ::= { mteTrigger 6 } > >mteTriggerThresholdEntry OBJECT-TYPE > SYNTAX MteTriggerThresholdEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about a single threshold trigger. Entries > automatically exist in this table for each mteTriggerEntry > that has 'threshold' set in mteTriggerTest." > INDEX { mteOwner, IMPLIED mteTriggerName } > ::= { mteTriggerThresholdTable 1 } > >MteTriggerThresholdEntry ::= SEQUENCE { > mteTriggerThresholdStartup INTEGER, > mteTriggerThresholdRising Integer32, > mteTriggerThresholdFalling Integer32, > mteTriggerThresholdDeltaRising Integer32, > mteTriggerThresholdDeltaFalling Integer32, > mteTriggerThresholdObjectsOwner SnmpAdminString, > mteTriggerThresholdObjects SnmpAdminString, > mteTriggerThresholdRisingEventOwner SnmpAdminString, > mteTriggerThresholdRisingEvent SnmpAdminString, > mteTriggerThresholdFallingEventOwner SnmpAdminString, > mteTriggerThresholdFallingEvent SnmpAdminString, > mteTriggerThresholdDeltaRisingEventOwner SnmpAdminString, > mteTriggerThresholdDeltaRisingEvent SnmpAdminString, > mteTriggerThresholdDeltaFallingEventOwner SnmpAdminString, > mteTriggerThresholdDeltaFallingEvent SnmpAdminString >} > >mteTriggerThresholdStartup OBJECT-TYPE > SYNTAX INTEGER { rising(1), falling(2), risingOrFalling(3) } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The event that may be triggered when this entry is first > set to 'active' and a new instance of the object at > mteTriggerValueID is found. If the first sample after this > instance becomes active is greater than or equal to > mteTriggerThresholdRising and mteTriggerThresholdStartup is > equal to 'rising' or 'risingOrFalling', then one > > > > > >Expires 7 December 2000 [Page 28] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > mteTriggerThresholdRisingEvent is triggered for that instance. > If the first sample after this entry becomes active is less > than or equal to mteTriggerThresholdFalling and > mteTriggerThresholdStartup is equal to 'falling' or > 'risingOrFalling', then one mteTriggerThresholdRisingEvent is > triggered for that instance." > DEFVAL { risingOrFalling } > ::= { mteTriggerThresholdEntry 1 } > >mteTriggerThresholdRising OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A threshold value to check against if mteTriggerType is > 'threshold'. > > When the current sampled value is greater than or equal to > this threshold, and the value at the last sampling interval > was less than this threshold, one > mteTriggerThresholdRisingEvent is triggered. That event is > also triggered if the first sample after this entry becomes > active is greater than or equal to this threshold and > mteTriggerThresholdStartup is equal to 'rising' or > 'risingOrFalling'. > > After a rising event is generated, another such event is not > triggered until the sampled value falls below this threshold > and reaches mteTriggerThresholdFalling." > DEFVAL { 0 } > ::= { mteTriggerThresholdEntry 2 } > >mteTriggerThresholdFalling OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A threshold value to check against if mteTriggerType is > 'threshold'. > > When the current sampled value is less than or equal to this > threshold, and the value at the last sampling interval was > greater than this threshold, one > mteTriggerThresholdFallingEvent is triggered. That event is > also triggered if the first sample afer this entry becomes > > > > > >Expires 7 December 2000 [Page 29] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > active is less than or equal to this threshold and > mteTriggerThresholdStartup is equal to 'falling' or > 'risingOrFalling'. > > After a falling event is generated, another such event is not > triggered until the sampled value rises above this threshold > and reaches mteTriggerThresholdRising." > DEFVAL { 0 } > ::= { mteTriggerThresholdEntry 3 } > >mteTriggerThresholdDeltaRising OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A threshold value to check against if mteTriggerType is > 'threshold'. > > When the delta value (difference) between the current sampled > value (value(n)) and the previous sampled value (value(n-1)) > is greater than or equal to this threshold, > and the delta value calculated at the last sampling interval > (i.e. value(n-1) - value(n-2)) was less than this threshold, > one mteTriggerThresholdDeltaRisingEvent is triggered. That event is > also triggered if the first delta value calculated after this > entry becomes active, i.e. value(2) - value(1), where value(1) > is the first sample taken of that instance, is greater than or > equal to this threshold. > > After a rising event is generated, another such event is not > triggered until the delta value falls below this threshold and > reaches mteTriggerThresholdDeltaFalling." > DEFVAL { 0 } > ::= { mteTriggerThresholdEntry 4 } > >mteTriggerThresholdDeltaFalling OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A threshold value to check against if mteTriggerType is > 'threshold'. > > When the delta value (difference) between the current sampled > value (value(n)) and the previous sampled value (value(n-1)) > > > > > >Expires 7 December 2000 [Page 30] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > is less than or equal to this threshold, > and the delta value calculated at the last sampling interval > (i.e. value(n-1) - value(n-2)) was greater than this threshold, > one mteTriggerThresholdDeltaFallingEvent is triggered. That event is > also triggered if the first delta value calculated after this > entry becomes active, i.e. value(2) - value(1), where value(1) > is the first sample taken of that instance, is less than or > equal to this threshold. > > After a falling event is generated, another such event is not > triggered until the delta value falls below this threshold and > reaches mteTriggerThresholdDeltaRising." > DEFVAL { 0 } > ::= { mteTriggerThresholdEntry 5 } > >mteTriggerThresholdObjectsOwner OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "To go with mteTriggerThresholdObjects, the mteOwner of a group > of objects from mteObjectsTable." > DEFVAL { ''H } > ::= { mteTriggerThresholdEntry 6 } > >mteTriggerThresholdObjects OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The mteObjectsName of a group of objects from > mteObjectsTable. These objects are to be added to any > Notification resulting from the firing of this trigger for > this test. > > A list of objects may also be added based on the overall > trigger, the event or other settings in mteTriggerTest. > > A length of 0 indicates no additional objects." > DEFVAL { ''H } > ::= { mteTriggerThresholdEntry 7 } > >mteTriggerThresholdRisingEventOwner OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-write > > > > > >Expires 7 December 2000 [Page 31] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > STATUS current > DESCRIPTION > "To go with mteTriggerThresholdRisingEvent, the mteOwner of an > event entry from mteEventTable." > DEFVAL { ''H } > ::= { mteTriggerThresholdEntry 8 } > >mteTriggerThresholdRisingEvent OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The mteEventName of the event to invoke when mteTriggerType is > 'threshold' and this trigger fires based on > mteTriggerThresholdRising. A length of 0 indicates no event." > DEFVAL { ''H } > ::= { mteTriggerThresholdEntry 9 } > >mteTriggerThresholdFallingEventOwner OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "To go with mteTriggerThresholdFallingEvent, the mteOwner of an > event entry from mteEventTable." > DEFVAL { ''H } > ::= { mteTriggerThresholdEntry 10 } > >mteTriggerThresholdFallingEvent OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The mteEventName of the event to invoke when mteTriggerType is > 'threshold' and this trigger fires based on > mteTriggerThresholdFalling. A length of 0 indicates no event." > DEFVAL { ''H } > ::= { mteTriggerThresholdEntry 11 } > >mteTriggerThresholdDeltaRisingEventOwner OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "To go with mteTriggerThresholdDeltaRisingEvent, the mteOwner > > > > > >Expires 7 December 2000 [Page 32] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > of an event entry from mteEventTable." > DEFVAL { ''H } > ::= { mteTriggerThresholdEntry 12 } > >mteTriggerThresholdDeltaRisingEvent OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The mteEventName of the event to invoke when mteTriggerType is > 'threshold' and this trigger fires based on > mteTriggerThresholdDeltaRising. A length of 0 indicates > no event." > DEFVAL { ''H } > ::= { mteTriggerThresholdEntry 13 } > >mteTriggerThresholdDeltaFallingEventOwner OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "To go with mteTriggerThresholdDeltaFallingEvent, the mteOwner > of an event entry from mteEventTable." > DEFVAL { ''H } > ::= { mteTriggerThresholdEntry 14 } > >mteTriggerThresholdDeltaFallingEvent OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The mteEventName of the event to invoke when mteTriggerType is > 'threshold' and this trigger fires based on > mteTriggerThresholdDeltaFalling. A length of 0 indicates > no event." > DEFVAL { ''H } > ::= { mteTriggerThresholdEntry 15 } > > >-- >-- Objects Table >-- > >mteObjectsTable OBJECT-TYPE > SYNTAX SEQUENCE OF MteObjectsEntry > > > > > >Expires 7 December 2000 [Page 33] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of objects that can be added to notifications based > on the trigger, trigger test, or event, as pointed to by > entries in those tables." > ::= { mteObjects 1 } > >mteObjectsEntry OBJECT-TYPE > SYNTAX MteObjectsEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A group of objects. Applications create and delete entries > using mteObjectsEntryStatus. > > When adding objects to a notification they are added in the > lexical order of their index in this table. Those associated > with a trigger come first, then trigger test, then event." > INDEX { mteOwner, mteObjectsName, mteObjectsIndex } > ::= { mteObjectsTable 1 } > >MteObjectsEntry ::= SEQUENCE { > mteObjectsName SnmpAdminString, > mteObjectsIndex Unsigned32, > mteObjectsID OBJECT IDENTIFIER, > mteObjectsIDWildcard TruthValue, > mteObjectsEntryStatus RowStatus > } > >mteObjectsName OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (1..32)) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A locally-unique, administratively assigned name for a group > of objects." > ::= { mteObjectsEntry 1 } > >mteObjectsIndex OBJECT-TYPE > SYNTAX Unsigned32 (1..4294967295) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An arbitrary integer for the purpose of identifying > > > > > >Expires 7 December 2000 [Page 34] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > individual objects within a mteObjectsName group. > > Objects within a group are placed in the notification in the > numerical order of this index. > > Groups are placed in the notification in the order of the > selections for overall trigger, trigger test, and event. > Within trigger test they are in the same order as the > numerical values of the bits defined for mteTriggerTest. > > Bad object identifiers or a mismatch between truncating the > identifier and the value of mteDeltaDiscontinuityIDWildcard > result in operation as one would expect when providing the > wrong identifier to a Get operation. The Get will fail or get > the wrong object. If the object is not available it is omitted > from the notification." > ::= { mteObjectsEntry 2 } > >mteObjectsID OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The object identifier of a MIB object to add to a > Notification that results from the firing of a trigger. > > This may be wildcarded by truncating all or part of the > instance portion, in which case the instance portion of the > OID for obtaining this object will be the same as that used > in obtaining the mteTriggerValueID that fired. If such > wildcarding is applied, mteObjectsIDWildcard must be > 'true' and if not it must be 'false'. > > Each instance that fills the wildcard is independent of any > additional instances, that is, wildcarded objects operate > as if there were a separate table entry for each instance > that fills the wildcard without having to actually predict > all possible instances ahead of time." > DEFVAL { zeroDotZero } > ::= { mteObjectsEntry 3 } > >mteObjectsIDWildcard OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-create > STATUS current > > > > > >Expires 7 December 2000 [Page 35] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > DESCRIPTION > "Control for whether mteObjectsID is to be treated as > fully-specified or wildcarded, with 'true' indicating wildcard." > DEFVAL { false } > ::= { mteObjectsEntry 4 } > >mteObjectsEntryStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The control that allows creation and deletion of entries. > Once made active an entry MAY not be modified except to > delete it." > ::= { mteObjectsEntry 5 } > > >-- >-- Event Section >-- > >-- Counters > >mteEventFailures OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of times an attempt to invoke an event > has failed. This counts individually for each > attempt in a group of targets or each attempt for a > wildcarded trigger object." > ::= { mteEvent 1 } > > >-- >-- Event Table >-- > >mteEventTable OBJECT-TYPE > SYNTAX SEQUENCE OF MteEventEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of management event action information." > > > > > >Expires 7 December 2000 [Page 36] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > ::= { mteEvent 2 } > >mteEventEntry OBJECT-TYPE > SYNTAX MteEventEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about a single event. Applications create and > delete entries using mteEventEntryStatus." > INDEX { mteOwner, IMPLIED mteEventName } > ::= { mteEventTable 1 } > >MteEventEntry ::= SEQUENCE { > mteEventName SnmpAdminString, > mteEventComment SnmpAdminString, > mteEventActions BITS, > mteEventEnabled TruthValue, > mteEventEntryStatus RowStatus > } > >mteEventName OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (1..32)) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A locally-unique, administratively assigned name for the > event." > ::= { mteEventEntry 1 } > >mteEventComment OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "A description of the event's function and use." > DEFVAL { ''H } > ::= { mteEventEntry 2 } > >mteEventActions OBJECT-TYPE > SYNTAX BITS { notification(0), set(1) } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The actions to perform when this event occurs. > > > > > > >Expires 7 December 2000 [Page 37] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > For 'notification', Traps and/or Informs are sent according > to the configuration in the SNMP Notification MIB. > > For 'set', an SNMP Set operation is performed according to > control values in this entry." > DEFVAL { {} } -- No bits set. > ::= { mteEventEntry 3 } > >mteEventEnabled OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "A control to allow an event to be configured but not used. > When the value is 'false' the event does not execute even if > triggered." > DEFVAL { false } > ::= { mteEventEntry 4 } > >mteEventEntryStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The control that allows creation and deletion of entries. > Once made active an entry MAY not be modified except to > delete it." > ::= { mteEventEntry 5 } > > >-- >-- Event Notification Table >-- > >mteEventNotificationTable OBJECT-TYPE > SYNTAX SEQUENCE OF MteEventNotificationEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of information about notifications to be sent as a > consequence of management events." > ::= { mteEvent 3 } > >mteEventNotificationEntry OBJECT-TYPE > SYNTAX MteEventNotificationEntry > > > > > >Expires 7 December 2000 [Page 38] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about a single event's notification. Entries > automatically exist in this this table for each mteEventEntry > that has 'notification' set in mteEventActions." > INDEX { mteOwner, IMPLIED mteEventName } > ::= { mteEventNotificationTable 1 } > >MteEventNotificationEntry ::= SEQUENCE { > mteEventNotification OBJECT IDENTIFIER, > mteEventNotificationObjectsOwner SnmpAdminString, > mteEventNotificationObjects SnmpAdminString > } > >mteEventNotification OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The object identifier from the NOTIFICATION-TYPE for the > notification to use if metEventActions has 'notification' set." > DEFVAL { zeroDotZero } > ::= { mteEventNotificationEntry 1 } > >mteEventNotificationObjectsOwner OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "To go with mteEventNotificationObjects, the mteOwner of a > group of objects from mteObjectsTable." > DEFVAL { ''H } > ::= { mteEventNotificationEntry 2 } > >mteEventNotificationObjects OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..32)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The mteObjectsName of a group of objects from > mteObjectsTable if mteEventActions has 'notification' set. > These objects are to be added to any Notification generated by > this event. > > > > > > >Expires 7 December 2000 [Page 39] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > Objects may also be added based on the trigger that stimulated > the event. > > A length of 0 indicates no additional objects." > DEFVAL { ''H } > ::= { mteEventNotificationEntry 3 } > > >-- >-- Event Set Table >-- > >mteEventSetTable OBJECT-TYPE > SYNTAX SEQUENCE OF MteEventSetEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of management event action information." > ::= { mteEvent 4 } > >mteEventSetEntry OBJECT-TYPE > SYNTAX MteEventSetEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about a single event's set option. Entries > automatically exist in this this table for each mteEventEntry > that has 'set' set in mteEventActions." > INDEX { mteOwner, IMPLIED mteEventName } > ::= { mteEventSetTable 1 } > >MteEventSetEntry ::= SEQUENCE { > mteEventSetObject OBJECT IDENTIFIER, > mteEventSetObjectWildcard TruthValue, > mteEventSetValue Integer32, > mteEventSetTargetTag SnmpTagValue, > mteEventSetContextName SnmpAdminString, > mteEventSetContextNameWildcard TruthValue > } > >mteEventSetObject OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS read-write > STATUS current > DESCRIPTION > > > > > >Expires 7 December 2000 [Page 40] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > "The object identifier from the MIB object to set if > mteEventActions has 'set' set. > > This object identifier may be wildcarded by leaving > sub-identifiers off the end, in which case > nteEventSetObjectWildCard must be 'true'. > > If mteEventSetObject is wildcarded the instance used to set the > object to which it points is the same as the instance from the > value of mteTriggerValueID that triggered the event. > > Each instance that fills the wildcard is independent of any > additional instances, that is, wildcarded objects operate > as if there were a separate table entry for each instance > that fills the wildcard without having to actually predict > all possible instances ahead of time. > > Bad object identifiers or a mismatch between truncating the > identifier and the value of mteSetObjectWildcard > result in operation as one would expect when providing the > wrong identifier to a Set operation. The Set will fail or set > the wrong object. If the value syntax of the destination > object is not correct, the Set fails with the normal SNMP > error code." > DEFVAL { zeroDotZero } > ::= { mteEventSetEntry 1 } > >mteEventSetObjectWildcard OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Control over whether mteEventSetObject is to be treated as > fully-specified or wildcarded, with 'true' indicating wildcard > if mteEventActions has 'set' set." > DEFVAL { false } > ::= { mteEventSetEntry 2 } > >mteEventSetValue OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The value to which to set the object at mteEventSetObject > if mteEventActions has 'set' set." > > > > > >Expires 7 December 2000 [Page 41] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > DEFVAL { 0 } > ::= { mteEventSetEntry 3 } > >mteEventSetTargetTag OBJECT-TYPE > SYNTAX SnmpTagValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The tag for the target(s) at which to set the object at > mteEventSetObject to mteEventSetValue if mteEventActions > has 'set' set. > > Systems limited to self management MAY reject a non-zero > length for the value of this object. > > A length of 0 indicates the local system. In this case, > access to the objects indicated by mteEventSetObject is under > the security credentials of the requester that set > mteTriggerEntryStatus to 'active'. Those credentials are the > input parameters for isAccessAllowed from the Architecture for > Describing SNMP Management Frameworks. > > Otherwise access rights are checked according to the security > parameters resulting from the tag." > DEFVAL { ''H } > ::= { mteEventSetEntry 4 } > >mteEventSetContextName OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The management context in which to set mteEventObjectID. > if mteEventActions has 'set' set. > > This may be wildcarded by leaving characters off the end. To > indicate such wildcarding mteEventSetContextNameWildcard must > be 'true'. > > If this context name is wildcarded the value used to complete > the wildcarding of mteTriggerContextName will be appended." > DEFVAL { ''H } > ::= { mteEventSetEntry 5 } > >mteEventSetContextNameWildcard OBJECT-TYPE > > > > > >Expires 7 December 2000 [Page 42] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > SYNTAX TruthValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Control for whether mteEventSetContextName is to be treated as > fully-specified or wildcarded, with 'true' indicating wildcard > if mteEventActions has 'set' set." > DEFVAL { false } > ::= { mteEventSetEntry 6 } > > >-- >-- Notifications >-- > >dismanEventMIBNotificationPrefix OBJECT IDENTIFIER ::= > { dismanEventMIB 2 } >dismanEventMIBNotifications OBJECT IDENTIFIER ::= > { dismanEventMIBNotificationPrefix 0 } >dismanEventMIBNotificationObjects OBJECT IDENTIFIER > ::= { dismanEventMIBNotificationPrefix 1 } > >-- >-- Notification Objects >-- > >mteHotTrigger OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "The name of the trigger causing the notification." > ::= { dismanEventMIBNotificationObjects 1 } > >mteHotTargetName OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "The SNMP Target MIB's snmpTargetAddrName related to the > notification." > ::= { dismanEventMIBNotificationObjects 2 } > >mteHotContextName OBJECT-TYPE > SYNTAX SnmpAdminString > > > > > >Expires 7 December 2000 [Page 43] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "The context name related to the notification. This MUST be as > fully-qualified as possible, including filling in wildcard > information determined in processing." > ::= { dismanEventMIBNotificationObjects 3 } > >mteHotOID OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "The object identifier of the destination object related to the > notification. This MUST be as fully-qualified as possible, > inluding filling in wildcard information determined in > processing. > > For a trigger-related notification this is from > mteTriggerValueID. > > For a set failure this is from mteEventSetObject." > ::= { dismanEventMIBNotificationObjects 4 } > >mteHotValue OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "The value of the object at mteTriggerValueID when a > trigger fired." > ::= { dismanEventMIBNotificationObjects 5 } > >mteFailedReason OBJECT-TYPE > SYNTAX FailureReason > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "The reason for the failure of an attempt to check for a > trigger condition or set an object in response to an event." > ::= { dismanEventMIBNotificationObjects 6 } > >-- >-- Notifications >-- > > > > > >Expires 7 December 2000 [Page 44] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > >mteTriggerFired NOTIFICATION-TYPE > OBJECTS { mteHotTrigger, > mteHotTargetName, > mteHotContextName, > mteHotOID, > mteHotValue } > STATUS current > DESCRIPTION > "Notification that the trigger indicated by the object > instances has fired, for triggers with mteTriggerType > 'boolean' or 'existence'." > ::= { dismanEventMIBNotifications 1 } > >mteTriggerRising NOTIFICATION-TYPE > OBJECTS { mteHotTrigger, > mteHotTargetName, > mteHotContextName, > mteHotOID, > mteHotValue } > STATUS current > DESCRIPTION > "Notification that the rising threshold was met for triggers > with mteTriggerType 'threshold'." > ::= { dismanEventMIBNotifications 2 } > >mteTriggerFalling NOTIFICATION-TYPE > OBJECTS { mteHotTrigger, > mteHotTargetName, > mteHotContextName, > mteHotOID, > mteHotValue } > STATUS current > DESCRIPTION > "Notification that the falling threshold was met for triggers > with mteTriggerType 'threshold'." > ::= { dismanEventMIBNotifications 3 } > >mteTriggerFailure NOTIFICATION-TYPE > OBJECTS { mteHotTrigger, > mteHotTargetName, > mteHotContextName, > mteHotOID, > mteFailedReason } > STATUS current > DESCRIPTION > > > > > >Expires 7 December 2000 [Page 45] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > "Notification that an attempt to check a trigger has failed. > > The network manager must enable this notification only with > a certain fear and trembling, as it can easily crowd out more > important information. It should be used only to help diagnose > a problem that has appeared in the error counters and can not > be found otherwise." > ::= { dismanEventMIBNotifications 4 } > >mteEventSetFailure NOTIFICATION-TYPE > OBJECTS { mteHotTrigger, > mteHotTargetName, > mteHotContextName, > mteHotOID, > mteFailedReason } > STATUS current > DESCRIPTION > "Notification that an attempt to do a set in response to an > event has failed. > > The network manager must enable this notification only with > a certain fear and trembling, as it can easily crowd out more > important information. It should be used only to help diagnose > a problem that has appeared in the error counters and can not > be found otherwise." > ::= { dismanEventMIBNotifications 5 } > > >-- >-- Conformance >-- > >dismanEventMIBConformance OBJECT IDENTIFIER ::= { dismanEventMIB 3 } >dismanEventMIBCompliances OBJECT IDENTIFIER ::= > { dismanEventMIBConformance 1 } >dismanEventMIBGroups OBJECT IDENTIFIER ::= > { dismanEventMIBConformance 2 } > >-- Compliance > >dismanEventMIBCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for entities which implement > the Event MIB." > > > > > >Expires 7 December 2000 [Page 46] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > MODULE -- this module > MANDATORY-GROUPS { > dismanEventResourceGroup, > dismanEventTriggerGroup, > dismanEventObjectsGroup, > dismanEventEventGroup, > dismanEventNotificationObjectGroup, > dismanEventNotificationGroup > } > > OBJECT mteTriggerTargetTag > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required, thus limiting > monitoring to the local system or pre-configured > remote systems." > > OBJECT mteEventSetTargetTag > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required, thus limiting > setting to the local system or pre-configured > remote systems." > > OBJECT mteTriggerValueIDWildcard > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required, thus allowing > the system not to implement wildcarding." > > OBJECT mteTriggerContextNameWildcard > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required, thus allowing > the system not to implement wildcarding." > > > OBJECT mteObjectsIDWildcard > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required, thus allowing > the system not to implement wildcarding." > > OBJECT mteEventSetContextNameWildcard > MIN-ACCESS read-only > > > > > >Expires 7 December 2000 [Page 47] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > DESCRIPTION > "Write access is not required, thus allowing > the system not to implement wildcarding." > > ::= { dismanEventMIBCompliances 1 } > >-- Units of Conformance > > > >dismanEventResourceGroup OBJECT-GROUP > OBJECTS { > mteResourceSampleMinimum, > mteResourceSampleInstanceMaximum, > mteResourceSampleInstances, > mteResourceSampleInstancesHigh, > mteResourceSampleInstanceLacks > } > STATUS current > DESCRIPTION > "Event resource status and control objects." > ::= { dismanEventMIBGroups 1 } > >dismanEventTriggerGroup OBJECT-GROUP > OBJECTS { > mteTriggerFailures, > > mteTriggerComment, > mteTriggerTest, > mteTriggerSampleType, > mteTriggerValueID, > mteTriggerValueIDWildcard, > mteTriggerTargetTag, > mteTriggerContextName, > mteTriggerContextNameWildcard, > mteTriggerFrequency, > mteTriggerObjectsOwner, > mteTriggerObjects, > mteTriggerEnabled, > mteTriggerEntryStatus, > > mteTriggerDeltaDiscontinuityID, > mteTriggerDeltaDiscontinuityIDWildcard, > mteTriggerDeltaDiscontinuityIDType, > > > > > > >Expires 7 December 2000 [Page 48] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > mteTriggerExistenceTest, > mteTriggerExistenceStartup, > mteTriggerExistenceObjectsOwner, > mteTriggerExistenceObjects, > mteTriggerExistenceEventOwner, > mteTriggerExistenceEvent, > > mteTriggerBooleanComparison, > mteTriggerBooleanValue, > mteTriggerBooleanStartup, > mteTriggerBooleanObjectsOwner, > mteTriggerBooleanObjects, > mteTriggerBooleanEventOwner, > mteTriggerBooleanEvent, > > mteTriggerThresholdStartup, > mteTriggerThresholdObjectsOwner, > mteTriggerThresholdObjects, > mteTriggerThresholdRising, > mteTriggerThresholdFalling, > mteTriggerThresholdDeltaRising, > mteTriggerThresholdDeltaFalling, > mteTriggerThresholdRisingEventOwner, > mteTriggerThresholdRisingEvent, > mteTriggerThresholdFallingEventOwner, > mteTriggerThresholdFallingEvent, > mteTriggerThresholdDeltaRisingEventOwner, > mteTriggerThresholdDeltaRisingEvent, > mteTriggerThresholdDeltaFallingEventOwner, > mteTriggerThresholdDeltaFallingEvent > } > STATUS current > DESCRIPTION > "Event triggers." > ::= { dismanEventMIBGroups 2 } > >dismanEventObjectsGroup OBJECT-GROUP > OBJECTS { > mteObjectsID, > mteObjectsIDWildcard, > mteObjectsEntryStatus > } > STATUS current > DESCRIPTION > "Supplemental objects." > > > > > >Expires 7 December 2000 [Page 49] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > ::= { dismanEventMIBGroups 3 } > >dismanEventEventGroup OBJECT-GROUP > OBJECTS { > mteEventFailures, > > mteEventComment, > mteEventActions, > mteEventEnabled, > mteEventEntryStatus, > > mteEventNotification, > mteEventNotificationObjectsOwner, > mteEventNotificationObjects, > > mteEventSetObject, > mteEventSetObjectWildcard, > mteEventSetValue, > mteEventSetTargetTag, > mteEventSetContextName, > mteEventSetContextNameWildcard > } > STATUS current > DESCRIPTION > "Events." > ::= { dismanEventMIBGroups 4 } > >dismanEventNotificationObjectGroup OBJECT-GROUP > OBJECTS { > mteHotTrigger, > mteHotTargetName, > mteHotContextName, > mteHotOID, > mteHotValue, > mteFailedReason > } > STATUS current > DESCRIPTION > "Notification objects." > ::= { dismanEventMIBGroups 5 } > >dismanEventNotificationGroup NOTIFICATION-GROUP > NOTIFICATIONS { > mteTriggerFired, > mteTriggerRising, > > > > > >Expires 7 December 2000 [Page 50] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > mteTriggerFalling, > mteTriggerFailure, > mteEventSetFailure > } > STATUS current > DESCRIPTION > "Notifications." > ::= { dismanEventMIBGroups 6 } > >END > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 51] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > >9. Intellectual Property > >The IETF takes no position regarding the validity or scope of any >intellectual property or other rights that might be claimed to pertain >to the implementation or use of the technology described in this >document or the extent to which any license under such rights might or >might not be available; neither does it represent that it has made any >effort to identify any such rights. Information on the IETF's >procedures with respect to rights in standards-track and standards- >related documentation can be found in BCP-11. Copies of claims of >rights made available for publication and any assurances of licenses to >be made available, or the result of an attempt made to obtain a general >license or permission for the use of such proprietary rights by >implementors or users of this specification can be obtained from the >IETF Secretariat. > >The IETF invites any interested party to bring to its attention any >copyrights, patents or patent applications, or other proprietary rights >which may cover technology that may be required to practice this >standard. Please address the information to the IETF Executive >Director. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 52] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > >10. Acknowledgements > >This MIB contains considerable contributions from the RMON MIB, the >Distributed Management Design Team (Andy Bierman, Maria Greene, Bob >Stewart, and Steve Waldbusser), the Distributed Management Working >Group, and colleagues at Cisco. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 53] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > >11. References > >[RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture > for Describing SNMP Management Frameworks", RFC 2571, April > 1999 > >[RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification > of Management Information for TCP/IP-based Internets", STD > 16, RFC 1155, May 1990 > >[RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD > 16, RFC 1212, March 1991 > >[RFC1215] M. Rose, "A Convention for Defining Traps for use with the > SNMP", RFC 1215, March 1991 > >[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., > Rose, M., and S. Waldbusser, "Structure of Management > Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999 > >[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., > Rose, M., and S. Waldbusser, "Textual Conventions for > SMIv2", STD 58, RFC 2579, April 1999 > >[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., > Rose, M., and S. Waldbusser, "Conformance Statements for > SMIv2", STD 58, RFC 2580, April 1999 > >[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple > Network Management Protocol", STD 15, RFC 1157, May 1990. > >[RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, > "Introduction to Community-based SNMPv2", RFC 1901, January > 1996. > >[RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, > "Transport Mappings for Version 2 of the Simple Network > Management Protocol (SNMPv2)", RFC 1906, January 1996. > >[RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message > Processing and Dispatching for the Simple Network Management > Protocol (SNMP)", RFC 2572, April 1999 > >[RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model > (USM) for version 3 of the Simple Network Management > > > > > >Expires 7 December 2000 [Page 54] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > Protocol (SNMPv3)", RFC 2574, April 1999 > >[RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, > "Protocol Operations for Version 2 of the Simple Network > Management Protocol (SNMPv2)", RFC 1905, January 1996. > >[RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", > RFC 2573, April 1999 > >[RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based > Access Control Model (VACM) for the Simple Network > Management Protocol (SNMP)", RFC 2575, April 1999 > >[RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, > "Introduction to Version 3 of the Internet-standard Network > Management Framework", RFC 2570, April 1999 > >[RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, > "Coexistence between Version 1 and version 2 of the > Internet-standard Network Management Framework", RFC 1903, > January 1996. > >[RFCEventMIB] > Stewart, B., "Event MIB", RFC ????, ?Month? 1999. > >[RFC1757] > Waldbusser, S., "Remote Network Monitoring Management Information > Base", RFC 1757, February 1995. > >[RFC1451] > Case, J., McCloghrie, K., Rose, M., Waldbusser, S., "Manager-to- > Manager Management Information Base", RFC 1451, April 1993. > >[RFCExpressionMIB] > Stewart, B., "Expression MIB", RFC ????, ?Month? 1999. > >[RFCNotificationLogMIB] > Stewart, B., "Notification Log MIB", RFC ????, ?Month? 1999. > > > > > > > > > > > > >Expires 7 December 2000 [Page 55] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > >12. Security Considerations > >Security issues are discussed in the Security section and in the >DESCRIPTION clauses of relevant objects. > > >13. Author's Address > > Bob Stewart > Cisco Systems, Inc. > 170 West Tasman Drive > San Jose, CA 95134-1706 > U.S.A. > > >14. Editor's Address > > Ramanathan Kavasseri > Cisco Systems, Inc. > 170 West Tasman Drive > San Jose, CA 95134-1706 > U.S.A. > > Phone: +1 408 527 2446 > Email: ramk@cisco.com > > > > > > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 56] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > >15. 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. > > > > > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 57] > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > >Table of Contents > > >1 Abstract ........................................................ 2 >2 The SNMP Management Framework ................................... 2 >3 Overview ........................................................ 4 >4 Relationship to Other MIBs ...................................... 4 >5 MIB Sections .................................................... 4 >6 Operation ....................................................... 7 >7 Security ........................................................ 8 >8 Definitions ..................................................... 9 >9 Intellectual Property ........................................... 52 >10 Acknowledgements ............................................... 53 >11 References ..................................................... 54 >12 Security Considerations ........................................ 56 >13 Author's Address ............................................... 56 >14 Editor's Address ............................................... 56 >15 Full Copyright Statement ....................................... 57 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 58] > > From owner-disman@dorothy.peer.com Tue Jul 4 13:31:48 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 NAA29391 for ; Tue, 4 Jul 2000 13:31:48 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e64HTiW12119; Tue, 4 Jul 2000 12:29:44 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA03016 for disman-list; Tue, 4 Jul 2000 10:28:50 -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 KAA03011 for ; Tue, 4 Jul 2000 10:28:46 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e64HTNW12026 for ; Tue, 4 Jul 2000 12:29:26 -0500 (CDT) Received: from sunfra.France.Sun.COM ([129.157.188.1]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22254; Tue, 4 Jul 2000 09:45:22 -0700 (PDT) Received: from sutur.France.Sun.COM (sutur [129.157.203.2]) by sunfra.France.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with ESMTP id SAA23374; Tue, 4 Jul 2000 18:45:20 +0200 (MET DST) Received: from oneman.France.Sun.COM by sutur.France.Sun.COM (8.9.3+Sun/SMI-SVR4) id SAA16386; Tue, 4 Jul 2000 18:45:18 +0200 (MET DST) Received: from france.sun.com (localhost [127.0.0.1]) by oneman.France.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA09011; Tue, 4 Jul 2000 18:45:23 +0200 (MEST) Message-ID: <396214A3.7C0EBFAB@france.sun.com> Date: Tue, 04 Jul 2000 18:45:23 +0200 From: Eamonn McManus Organization: Sun Microsystems, France X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) MIME-Version: 1.0 To: Juergen Schoenwaelder CC: DISMAN Mailing List Subject: Re: script mib suspend/resume issue References: <200007041550.RAA23718@henkell.ibr.cs.tu-bs.de> 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 KAA03012 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Juergen Schoenwaelder wrote: > RFC 2592 says in the compliance statement the an implementation which > is told to suspend a script but which is unable to do so will put the > script into the suspending state until it either terminates or the > managers gives the command to resume the script. > > The implication of this is that a manager can not figure out whether a > script can be suspended or not. Setting smRunControl to `suspend' and > then polling smRunState until the script is really suspended does not > work (unless you invent some strange timeouts). > > Strawman: Change the compliance definition such that implementations > which are unable to suspend a script keep the script in the executing > state. This allows to set smRunControl to `suspend' and to poll > smRunState until it either contains `running' or `suspended'. I do not understand your last sentence. It seems to me that if the semantics are changed to what you suggest, the way to know whether suspension is supported is to set smRunControl to "suspend" and then immediately read smRunState. If it is either "suspending" or "suspended", then suspension is supported. If it is "running", then suspension is not supported (or, someone else resumed the script behind your back). There is no need to poll. I quite like today's semantics, where unsupported suspend appears like a suspend that just takes forever to take effect. But if you do want to have an indication of whether your suspend is going to succeed or not, I think the right thing is an appropriate SNMP error for the operation that tries to set smRunControl to "suspend". Éamonn From owner-disman@dorothy.peer.com Wed Jul 5 05:11: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 FAA18932 for ; Wed, 5 Jul 2000 05:11:28 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e65999W26258; Wed, 5 Jul 2000 04:09:09 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id CAA05292 for disman-list; Wed, 5 Jul 2000 02:05:50 -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 CAA05287 for ; Wed, 5 Jul 2000 02:05:46 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e6596LW26096 for ; Wed, 5 Jul 2000 04:06:27 -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 KAA17968; Wed, 5 Jul 2000 10:01:22 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA10518; Wed, 5 Jul 2000 10:01:22 +0200 Date: Wed, 5 Jul 2000 10:01:22 +0200 Message-Id: <200007050801.KAA10518@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: eamonn.mcmanus@france.sun.com CC: disman@dorothy.peer.com In-reply-to: <396214A3.7C0EBFAB@france.sun.com> (message from Eamonn McManus on Tue, 04 Jul 2000 18:45:23 +0200) Subject: Re: script mib suspend/resume issue References: <200007041550.RAA23718@henkell.ibr.cs.tu-bs.de> <396214A3.7C0EBFAB@france.sun.com> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Eamonn McManus writes: >> Strawman: Change the compliance definition such that >> implementations which are unable to suspend a script keep the >> script in the executing state. This allows to set smRunControl to >> `suspend' and to poll smRunState until it either contains `running' >> or `suspended'. Eamonn> I do not understand your last sentence. It seems to me that Eamonn> if the semantics are changed to what you suggest, the way to Eamonn> know whether suspension is supported is to set smRunControl to Eamonn> "suspend" and then immediately read smRunState. If it is Eamonn> either "suspending" or "suspended", then suspension is Eamonn> supported. If it is "running", then suspension is not Eamonn> supported (or, someone else resumed the script behind your Eamonn> back). There is no need to poll. What I propose is to make suspending a truly temporary state which either leads to suspended or executing (if the operation failed for a give script/runtime. Eamonn> I quite like today's semantics, where unsupported suspend Eamonn> appears like a suspend that just takes forever to take effect. Eamonn> But if you do want to have an indication of whether your Eamonn> suspend is going to succeed or not, I think the right thing is Eamonn> an appropriate SNMP error for the operation that tries to set Eamonn> smRunControl to "suspend". The drawback of this option is that the suspend operation now becomes synchronous. The agent has to wait until the script got suspended or the suspend failed before it can send the response to the set request. Depending on your implementation, this may not be desirable. In our implementation, the SNMP agent sends out an SMX message to the runtime system in order to suspend a running script. The response to this SMX message indicates whether the suspend operation succeeded or not. It would be hard to make assumptions on the time a runtime needs to come back with a response. smRunState runtime executing | | smRunControl = suspend | SMX suspend ----------------------> suspending -------------> -+ <--------------------- | | | SMX response | executing <------------ -+ ----------------------> | <--------------------- | get smRunState = executing | | | | smRunControl = suspend | SMX suspend ----------------------> suspending -------------> -+ <--------------------- | | | SMX response | suspended <------------ -+ ----------------------> | <--------------------- | get smRunState = suspended | The figure above may be helpful to understand the proposal. Note that I do not require a suspending state. If an implemen From owner-disman@dorothy.peer.com Wed Jul 5 07:09:31 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19830 for ; Wed, 5 Jul 2000 07:09:31 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e65B7PW04525; Wed, 5 Jul 2000 06:07:25 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA05531 for disman-list; Wed, 5 Jul 2000 04:05:38 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA05526 for ; Wed, 5 Jul 2000 04:05:34 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e65B6DW04152 for ; Wed, 5 Jul 2000 06:06:14 -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 MAA29415; Wed, 5 Jul 2000 12:53:19 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id MAA13657; Wed, 5 Jul 2000 12:53:19 +0200 Date: Wed, 5 Jul 2000 12:53:19 +0200 Message-Id: <200007051053.MAA13657@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: eamonn.mcmanus@france.sun.com CC: disman@dorothy.peer.com In-reply-to: <39630C0F.88BDE106@france.sun.com> (message from Eamonn McManus on Wed, 05 Jul 2000 12:21:03 +0200) Subject: Re: script mib suspend/resume issue References: <200007041550.RAA23718@henkell.ibr.cs.tu-bs.de> <396214A3.7C0EBFAB@france.sun.com> <200007050801.KAA10518@henkell.ibr.cs.tu-bs.de> <39630C0F.88BDE106@france.sun.com> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Eamonn McManus writes: Eamonn> If an implementation is always unable to suspend scripts, it Eamonn> will know that, and can immediately say so. What you are Eamonn> saying, though, is that an implementation might not know Eamonn> whether it can actually suspend a given script at a given Eamonn> moment until it actually tries it. I knew that suspending a Eamonn> script was not an instantaneous action, but what you are Eamonn> saying is that even knowing whether suspending will work is Eamonn> not necessarily instantaneous. I think there are at least three different cases: (a) The agent knows that you will never be able to suspend a script. The easiest case. (b) The agent supports arbitrary runtime engines and it is not aware of the capabilities of each particular runtime. However, once the agent is aware of the runtime engine capabilities, then it knows whether the runtime supports suspend/resume or not. A bit more complex case because you need to invent a way to "learn" the suspend/resume capabilities of an arbitrary runtime engine. (c) The runtime itself allows scripts to ignore suspend/resume. In this case, you will only find out whether suspend/resume works by actually trying it. We are facing (b) and perhaps (c). An example for (c) would be a UNIX process which ignores signals to stop the process. (To be fair, this example is not too convincing since your can't ignore the STOP signal as far as I know.) Another example would be a runtime engine which uses a cooperative threading mechanism and which requires that the thread actually returns the CPU and suspends itself. Eamonn> This is only a problem if a script's suspendability can change Eamonn> during its execution. Is this the case for your SMX-based Eamonn> implementation, or would it be possible to know at the moment Eamonn> a script is launched whether future suspend requests for that Eamonn> script will work? We can solve the problem in our implementation if we define that runtimes may never show the behaviour (c) and by inventing a mechanism to "learn" whether a runtime is capable to do a suspend/resume (either by having this information statically in a configuration file or by doing a test suspend/resume when a script is started). Eamonn> If the latter, are there other realistic examples where you Eamonn> cannot immediately know at suspension time whether the Eamonn> suspension will work? If so, your solution does seem to be Eamonn> the only reasonable one. But such a system would be a very Eamonn> strange one: is it really useful to have a suspend operation Eamonn> that only works sometimes? We can design the script MIB so that it works regardless what the answer to this question is. Or we can answer this question and hope that the answer we have given proves to be correct in all cases. Anyway, I believe the current behaviour described in RFC 2592 is really ugly. Both, the initial strawman proposal as well as the proposal to send an inconsistentValue error in response to the suspend set operation are IMHO better than what we have now. What do the other folks on this list 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 Wed Jul 5 07:10:45 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 HAA19913 for ; Wed, 5 Jul 2000 07:10:45 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e65B96W05113; Wed, 5 Jul 2000 06:09:06 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA05572 for disman-list; Wed, 5 Jul 2000 04:07:38 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA05567 for ; Wed, 5 Jul 2000 04:07:34 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e65B8BW04698 for ; Wed, 5 Jul 2000 06:08:11 -0500 (CDT) Received: from sunfra.France.Sun.COM ([129.157.188.1]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA19228; Wed, 5 Jul 2000 03:21:02 -0700 (PDT) Received: from sutur.France.Sun.COM (sutur [129.157.203.2]) by sunfra.France.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with ESMTP id MAA18626; Wed, 5 Jul 2000 12:21:00 +0200 (MET DST) Received: from oneman.France.Sun.COM by sutur.France.Sun.COM (8.9.3+Sun/SMI-SVR4) id MAA29186; Wed, 5 Jul 2000 12:20:58 +0200 (MET DST) Received: from france.sun.com (localhost [127.0.0.1]) by oneman.France.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11721; Wed, 5 Jul 2000 12:21:03 +0200 (MEST) Message-ID: <39630C0F.88BDE106@france.sun.com> Date: Wed, 05 Jul 2000 12:21:03 +0200 From: Eamonn McManus Organization: Sun Microsystems, France X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) MIME-Version: 1.0 To: Juergen Schoenwaelder CC: disman@dorothy.peer.com Subject: Re: script mib suspend/resume issue References: <200007041550.RAA23718@henkell.ibr.cs.tu-bs.de> <396214A3.7C0EBFAB@france.sun.com> <200007050801.KAA10518@henkell.ibr.cs.tu-bs.de> 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 EAA05568 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Juergen Schoenwaelder wrote: > >> Strawman: Change the compliance definition such that > >> implementations which are unable to suspend a script keep the > >> script in the executing state. This allows to set smRunControl to > >> `suspend' and to poll smRunState until it either contains `running' > >> or `suspended'. > > Eamonn> I do not understand your last sentence. It seems to me that > Eamonn> if the semantics are changed to what you suggest, the way to > Eamonn> know whether suspension is supported is to set smRunControl to > Eamonn> "suspend" and then immediately read smRunState. If it is > Eamonn> either "suspending" or "suspended", then suspension is > Eamonn> supported. If it is "running", then suspension is not > Eamonn> supported (or, someone else resumed the script behind your > Eamonn> back). There is no need to poll. > > What I propose is to make suspending a truly temporary state which > either leads to suspended or executing (if the operation failed for a > give script/runtime. From what you describe later in your message, you were actually talking about a somewhat different problem from what you said. If an implementation is always unable to suspend scripts, it will know that, and can immediately say so. What you are saying, though, is that an implementation might not know whether it can actually suspend a given script at a given moment until it actually tries it. I knew that suspending a script was not an instantaneous action, but what you are saying is that even knowing whether suspending will work is not necessarily instantaneous. This is only a problem if a script's suspendability can change during its execution. Is this the case for your SMX-based implementation, or would it be possible to know at the moment a script is launched whether future suspend requests for that script will work? If the latter, are there other realistic examples where you cannot immediately know at suspension time whether the suspension will work? If so, your solution does seem to be the only reasonable one. But such a system would be a very strange one: is it really useful to have a suspend operation that only works sometimes? Éamonn From owner-disman@dorothy.peer.com Wed Jul 5 14:48:00 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 OAA14105 for ; Wed, 5 Jul 2000 14:47:59 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e65IcpW13354; Wed, 5 Jul 2000 13:38:51 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA10682 for disman-list; Wed, 5 Jul 2000 11:37:17 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA10470; Wed, 5 Jul 2000 11:33:35 -0700 (PDT) Date: Wed, 5 Jul 2000 11:33:35 -0700 (PDT) From: Randy Presuhn Message-Id: <200007051833.LAA10470@dorothy.bmc.com> To: agentx@dorothy.peer.com, disman@dorothy.peer.com Subject: test of agentx and disman lists 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 - this is a test of the agentx and disman WG mailing lists. please ignore. ------------------------------------------------------- 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 Jul 6 02:56:25 2000 Received: from tattler.bmc.com ([198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08721 for ; Thu, 6 Jul 2000 02:56:24 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e666smo18252; Thu, 6 Jul 2000 01:54:48 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id XAA16669 for disman-list; Wed, 5 Jul 2000 23:52:58 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id XAA16663; Wed, 5 Jul 2000 23:52:54 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e666rXo18024; Thu, 6 Jul 2000 01:53:33 -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 IAA07713; Thu, 6 Jul 2000 08:42:38 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id IAA08822; Thu, 6 Jul 2000 08:42:38 +0200 Date: Thu, 6 Jul 2000 08:42:38 +0200 Message-Id: <200007060642.IAA08822@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.peer.com CC: disman@dorothy.peer.com Subject: pittsburgh meeting Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Randy, I like to allocate some meeting time for the RFC 2591 and RFC 2592 revisions. I post updated IDs before the cutoff which include all the changes where I see concensus in the WG. There are still some issues where I am not 100 % sure what the concensus position is and Pittsburgh might be a good place to resolve these issues. I guess we need 20-30 minutes (depending on how prepared people are). /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 Jul 6 06:50:24 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11311 for ; Thu, 6 Jul 2000 06:50:23 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e66Amko18425; Thu, 6 Jul 2000 05:48:46 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id DAA17107 for disman-list; Thu, 6 Jul 2000 03:44:41 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA17102 for ; Thu, 6 Jul 2000 03:44:37 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e66AjHo18151 for ; Thu, 6 Jul 2000 05:45:17 -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 GAA11091; Thu, 6 Jul 2000 06:45:10 -0400 (EDT) Message-Id: <200007061045.GAA11091@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@dorothy.peer.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-event-mib-10.txt Date: Thu, 06 Jul 2000 06:45:10 -0400 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Event MIB Author(s) : R. Kavasseri, B. Stewart Filename : draft-ietf-disman-event-mib-10.txt Pages : 58 Date : 05-Jul-00 This memo defines an experimental 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-event-mib-10.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-event-mib-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-event-mib-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000705121649.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-event-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-event-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000705121649.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-disman@dorothy.peer.com Thu Jul 6 06:50:24 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11316 for ; Thu, 6 Jul 2000 06:50:24 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e66Amko18424; Thu, 6 Jul 2000 05:48:46 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id DAA17117 for disman-list; Thu, 6 Jul 2000 03:46:01 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA17110 for ; Thu, 6 Jul 2000 03:45:57 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e66Akbo18210 for ; Thu, 6 Jul 2000 05:46:37 -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 GAA11139; Thu, 6 Jul 2000 06:46:39 -0400 (EDT) Message-Id: <200007061046.GAA11139@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@dorothy.peer.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-express-mib-12.txt Date: Thu, 06 Jul 2000 06:46:39 -0400 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Distributed Management Expression MIB Author(s) : R. Kavasseri, B. Stewart Filename : draft-ietf-disman-express-mib-12.txt Pages : 48 Date : 05-Jul-00 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-express-mib-12.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-express-mib-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-express-mib-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000705121846.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-express-mib-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-express-mib-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000705121846.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-disman@dorothy.peer.com Thu Jul 6 12:56: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 MAA20933 for ; Thu, 6 Jul 2000 12:56:56 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e66GqxZ28043; Thu, 6 Jul 2000 11:53:00 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA17943 for disman-list; Thu, 6 Jul 2000 09:51:28 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA17937 for disman@dorothy.bmc.com; Thu, 6 Jul 2000 09:51:25 -0700 (PDT) Date: Thu, 6 Jul 2000 09:51:25 -0700 (PDT) From: Randy Presuhn Message-Id: <200007061651.JAA17937@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Re: pittsburgh meeting 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 - > Date: Thu, 6 Jul 2000 08:42:38 +0200 > Message-Id: <200007060642.IAA08822@henkell.ibr.cs.tu-bs.de> > From: Juergen Schoenwaelder > To: rpresuhn@dorothy.bmc.com > CC: disman@dorothy.bmc.com > Subject: pittsburgh meeting > List-Id: IETF disman Working Group mailing list ... > I like to allocate some meeting time for the RFC 2591 and RFC 2592 > revisions. I post updated IDs before the cutoff which include all the > changes where I see concensus in the WG. There are still some issues > where I am not 100 % sure what the concensus position is and > Pittsburgh might be a good place to resolve these issues. > > I guess we need 20-30 minutes (depending on how prepared people are). ... I'll put it on the agenda. I'd appreciate it if you could (re-) post those issues to the WG mailing list. I'd also like to see some discussion of whether we can advance them to Draft Standard or will need to cycle at Proposed Standard. (I think the answer will be obvious, but we need to have the discussion anyway.) In any case, the resolution of the issues should be driven by what is technically the right thing to do, NOT considerations of advancement. ------------------------------------------------------- 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 Jul 7 12:25:23 2000 Received: from tattler.bmc.com ([198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02107 for ; Fri, 7 Jul 2000 12:25:21 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e67GICZ21648; Fri, 7 Jul 2000 11:18:12 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA22481 for disman-list; Fri, 7 Jul 2000 09:14:43 -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 JAA22472 for ; Fri, 7 Jul 2000 09:14:18 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e67GEsZ20931 for ; Fri, 7 Jul 2000 11:14:56 -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 SAA06963; Fri, 7 Jul 2000 18:14:46 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id SAA18296; Fri, 7 Jul 2000 18:14:46 +0200 Date: Fri, 7 Jul 2000 18:14:46 +0200 Message-Id: <200007071614.SAA18296@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: internet-drafts@ietf.org CC: disman@dorothy.peer.com Subject: draft-ietf-disman-script-mib-v2-01.txt Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Please post the attached document as Internet Draft . This document is work towards a revision of RFC 2592. Network Working Group D. Levi Internet-Draft Nortel Networks Expires December 2000 J. Schoenwaelder TU Braunschweig 7. July 2000 Definitions of Managed Objects for the Delegation of Management Scripts Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 Distribution of this document is unlimited. Please send comments to the Distributed Management Working Group . Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 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 a set of managed objects that allow the delegation of management scripts to distributed managers. Levi & Schoenwaelder Standards Track [Page 1] Internet-Draft Script MIB July 2000 Table of Contents 1 Introduction ................................................. 3 2 The SNMP Management Framework ................................ 3 3 Overview ..................................................... 4 3.1 Terms ...................................................... 4 4 Requirements and Design Issues ............................... 5 4.1 Script Languages ........................................... 6 4.2 Script Transfer ............................................ 7 4.3 Script Execution ........................................... 8 5 The Structure of the MIB ..................................... 9 5.1 The smLanguageGroup ........................................ 9 5.2 The smScriptGroup .......................................... 9 5.3 The smCodeGroup ............................................ 10 5.4 The smLaunchGroup .......................................... 11 5.5 The smRunGroup ............................................. 11 6 Definitions .................................................. 12 7 Usage Examples ............................................... 42 7.1 Pushing a Script via SNMP .................................. 42 7.2 Pulling a Script from a URL ................................ 43 7.3 Modifying an Existing Script ............................... 43 7.4 Removing an Existing Script ................................ 44 7.5 Creating a Launch Button ................................... 44 7.6 Launching a Script ......................................... 45 7.7 Suspending a Running Script ................................ 45 7.8 Resuming a Suspended Script ................................ 45 7.9 Terminating a Running Script ............................... 46 7.10 Removing a Launch Button .................................. 46 8 VACM Configuration Examples .................................. 47 8.1 Sandbox for Guests ......................................... 47 8.2 Sharing Scripts ............................................ 47 8.3 Emergency Scripts .......................................... 48 9 IANA Considerations .......................................... 49 10 Security Considerations ..................................... 50 11 Intellectual Property ....................................... 50 12 Changes from RFC 2592 ....................................... 51 13 Open Issues ................................................. 52 14 Acknowledgments ............................................. 52 15 References .................................................. 53 16 Editors' Addresses .......................................... 55 17 Full Copyright Statement .................................... 55 Levi & Schoenwaelder Standards Track [Page 2] Internet-Draft Script MIB July 2000 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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 Levi & Schoenwaelder Standards Track [Page 3] Internet-Draft Script MIB July 2000 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. Overview The Script MIB module defined in this memo can be used to delegate management functions to distributed managers. Management functions are defined as management scripts written in a management scripting language. This MIB makes no assumptions about the language itself and even allows distribution of compiled native code, if an implementation is able to execute native code under the control of this MIB. The Script MIB defines a standard interface for the delegation of management functions based on the Internet management framework. In particular, it provides the following capabilities: 1. Capabilities to transfer management scripts to a distributed manager. 2. Capabilities for initiating, suspending, resuming and terminating management scripts. 3. Capabilities to transfer arguments for management scripts. 4. Capabilities to monitor and control running management scripts. 5. Capabilities to transfer the results produced by running management scripts. This memo does not address any additional topics like the generation of notifications or how to address remote agents from a Script MIB implementation. 3.1. Terms This section defines the terms used throughout this memo. Levi & Schoenwaelder Standards Track [Page 4] Internet-Draft Script MIB July 2000 o A `distributed manager' is a processing entity which is capable of performing network management functions. For the scope of this memo, a distributed manager is assumed to implement the Script MIB. o A `higher-level manager', or just `manager', is a processing entity or human who initiates and controls the operations performed by one or more distributed managers. o A `management script' is a set of instructions written in an executable language which implements a management function. o A `management scripting language' is a language used to write management scripts. The term scripting language does not imply that the language must have the characteristics of scripting languages (e.g. string orientation, interpretation, weak typing). The MIB defined in this memo also allows to control management scripts written in arbitrary compiled system programming languages. o A `distributed manager' can be decomposed into an `SNMP entity' which implements the Script MIB defined in this memo and the `runtime system' that executes scripts. The Script MIB sees the runtime system as the managed resource which is controlled by the MIB. The runtime system can act as an SNMP application, according to the SNMP architecture defined in RFC 2571 [RFC2571]. For example, a runtime system which sends SNMP requests to other SNMP entities will act as a command generator application. The SNMP applications in the runtime system may use the same SNMP engine which also serves the command responder application used to implement the Script MIB, but they are not required to do so. o A `launch button' is the conceptual button used to start the execution of a management script. It assignes control parameters to a management script. In particular, it defines the ownership of the scripts started from a launch button. The ownership can be used by the language runtime system to enforce security profiles on a running management script. 4. Requirements and Design Issues This section discusses some general requirements that have influenced the design of the Script MIB. o The Script MIB must not make any assumptions about specific languages or runtime systems. Levi & Schoenwaelder Standards Track [Page 5] Internet-Draft Script MIB July 2000 o The Script MIB must provide mechanisms that help to avoid new management problems (e.g. script version problems). o The Script MIB must provide SNMP interfaces to all functions required to delegate management scripts. However, other protocols might be used in addition if they provide a significant improvement in terms of convenience for implementation or performance. o The Script MIB must be organized so that access can be controlled effectively by using view-based access control [RFC2575]. The following sections discuss some design issues in more detail. 4.1. Script Languages The Script MIB defined in this memo makes no assumption about the script language. This MIB can therefore be used in combination with different languages (such as Tcl or Java) and/or different versions of the same language. No assumptions are made about the format in which management scripts are transferred. The Script MIB provides access to information about the language versions supported by a Script MIB implementation so that a manager can learn about the capabilities provided by an implementation. Languages and language versions are identified as follows: 1. The language is identified by an object identifier. Object identifier for well-known languages will be registered by the Internet Assigned Numbers Authority (IANA). Enterprise specific languages can also be registered in the enterprise specific OID subtree. 2. A particular version of a language is identified by a language version number. The combination of a language object identifier and a language version is in most cases sufficient to decide whether a script can be executed or not. 3. Different implementations of the same language version might have differences due to ambiguities in the language definition or additional language features provided by an implementor. An additional object identifier value is provided which identifies the organization which provides the implementation of a language. This might be used by scripts that require a particular implementation of a language. 4. Finally, there might be different versions of a language implementation. A version number for the language implementation Levi & Schoenwaelder Standards Track [Page 6] Internet-Draft Script MIB July 2000 is provided so that the manager can also distinguish between different implementations from the same organization of a particular language version. The version numbers can either be used by a manager to select the language version required to execute a particular script or to select a script that fits the language versions supported by a particular Script MIB implementation. An additional table lists language extensions that provide features not provided by the core language. Language extensions are usually required to turn a general purpose language into a management language. In many cases, language extensions will come in the form of libraries that provide capabilities like sending SNMP requests to remote SNMP agents or accessing the local MIB instrumentation. Every extension is associated with a language and carries its own version numbers. 4.2. Script Transfer There are two different ways to transfer management scripts to a distributed manager. The first approach requires that the manager pushes the script to the distributed manager. This is therefore called the `push model'. The second approach is the `pull model' where the manager tells the distributed manager the location of the script and the distributed manager retrieves the script itself. The MIB defined in this memo supports both models. The `push model' is realized by a table which allows a manager to write scripts by sending a sequence of SNMP set requests. The script can be split into several fragments in order to deal with SNMP message size limitations. The `pull model' is realized by the use of Uniform Resource Locators (URLs) [RFC2396] that point to the script source. The manager writes the URL which points to the script source to the distributed manager by sending an SNMP set request. The distributed manager is then responsible for retrieving the document using the protocol specified in the URL. This allows the use of protocols like FTP [RFC959] or HTTP [RFC2068] to transfer large management scripts efficiently. The Script MIB also allows management scripts that are hard-wired into the Script MIB implementation. Built-in scripts can either be implemented in a language runtime system, or they can be built natively into the Script MIB implementation. The implementation of the `push model' or the `pull model' is not required. Scripts can be stored in non-volatile storage. This allows a distributed manager to restart scripts if it is restarted (off-line Levi & Schoenwaelder Standards Track [Page 7] Internet-Draft Script MIB July 2000 restart). A manager is not required to push scripts back into the distributed manager after a restart if the script is backed up in non-volatile storage. Every script is identified by an administratively assigned name. This name may be used to derive the name which is used to access the script in non-volatile storage. This mapping is implementation specific. However, the mapping must ensure that the Script MIB implementation can handle scripts with the same administrative name owned by different managers. One way to achieve this is to use the script owner in addition to the script name in order to derive the internal name used to refer to a particular script in non-volatile storage. 4.3. Script Execution The Script MIB permits execution of several instances of the same or different management scripts. Script arguments are passed as OCTET STRING values. Scripts return a single result value which is also an OCTET STRING value. The semantic interpretation of result values is left to the invoking manager or other management scripts. A script invoker must understand the format and semantics of both the arguments and the results of the scripts that it invokes. Scripts can also export complex results through a MIB interface. This allows a management application to access and use script results in the same manner as it processes any other MIB data. However, the Script MIB does not provide any special support for the implementation of MIBs through scripts. Runtime errors terminate active scripts. An exit code and a human readable error message is left in the MIB. A notification containing the exit code, the error message and a timestamp is generated when a script terminates with an error exit code. Script arguments and results do not have any size limitations other than the limits imposed by the SMI and the SNMP protocol. However, implementations of this MIB might have further restrictions. A script designer might therefore choose to return the results via other mechanisms if the script results can be very large. One possibility is to return a URL as a script result which points to the file containing the script output. Executing scripts have a status object attached which allows script execution to be suspended, resumed, or aborted. The precise semantics of the suspend and resume operations are language and runtime system dependent. Some runtime systems may choose to not implement the suspend/resume operations. Levi & Schoenwaelder Standards Track [Page 8] Internet-Draft Script MIB July 2000 A history of finished scripts is kept in the MIB. A script invoker can collect results at a later point in time (offline operation). Control objects can be used to control how entries in the history are aged out if the table fills up. 5. The Structure of the MIB This section presents the structure of the MIB. The objects are arranged into the following groups: o language group (smLanguageGroup) o script group (smScriptGroup) o script code group (smCodeGroup) o script launch group (smLaunchGroup) o running script group (smRunGroup) 5.1. The smLanguageGroup The smLanguageGroup is used to provide information about the languages and the language extensions supported by a Script MIB implementation. This group includes two tables. The smLangTable lists all languages supported by a Script MIB implementation and the smExtsnTable lists the extensions that are available for a given language. 5.2. The smScriptGroup The smScriptGroup consists of a single table, called the smScriptTable. The smScriptTable lists all scripts known to a Script MIB implementation. The smScriptTable contains objects that allow the following operations: o download scripts from a URL (pull model) o read scripts from local non-volatile storage o store scripts in local non-volatile storage o delete scripts from local non-volatile storage o list permanent scripts (that can not be changed or removed) Levi & Schoenwaelder Standards Track [Page 9] Internet-Draft Script MIB July 2000 o read and modify the script status (enabled, disabled, editing) A status object called smScriptOperStatus allows a manager to obtain the current status of a script. It is also used to provide an error indication if an attempt to invoke one of the operations listed above fails. The status change of a script can be requested by modifying the associated smScriptAdminStatus object. The source of a script is defined by the smScriptSource object. This object may contain a URL pointing to a remote location which provides access to the management script. The script source is read from the smCodeTable (described below) or from non-volatile storage if the smScriptSource object contains an empty URL. The smScriptStorageType object is used to distinguish between scripts read from non-volatile storage and scripts read from the smCodeTable. Scripts are automatically loaded once the smScriptAdminStatus object is set to `enabled'. Loading a script includes retrieving the script (probably from a remote location), compiling the script for languages that require a compilation step, and making the code available to the runtime system. The smScriptOperStatus object is used to indicate the status of the loading process. This object will start in the state `retrieving', switch to the state `compiling' and finally reach the state `enabled'. Errors during the retrieval or compilation phase will result in an error state such as `compilationFailed'. 5.3. The smCodeGroup The smCodeGroup consists of a single table, called the smCodeTable, which provides the ability to transfer and modify scripts via SNMP set requests. In particular, the smCodeTable allows the following operations: o download scripts via SNMP (push model) o modify scripts via SNMP (editing) The smCodeTable lists the code of a script. A script can be fragmented over multiple rows of the smCodeTable in order to handle SNMP message size limitations. Modifications of the smCodeTable are only possible if the associated smScriptOperStatus object has the value `editing'. The Script MIB implementation reloads the modified script code once the smScriptOperStatus changes to `enabled' again. The implementation of the smCodeGroup is optional. Levi & Schoenwaelder Standards Track [Page 10] Internet-Draft Script MIB July 2000 5.4. The smLaunchGroup The smLaunchGroup contains a single table, the smLaunchTable. An entry in the smLaunchTable represents a launch button which can be used to start a script. The smLaunchTable allows the following operations: o associate a script with an owner used during script execution o provide arguments and parameters for script invocation o invoke scripts with a single set operation The smLaunchTable describes scripts and their parameters that are ready to be launched. An entry in the smLaunchTable attaches an argument to a script and control values which, for example, define the maximum number of times that a script invoked from a particular row in the smLaunchTable may be running concurrently. An entry in the smLaunchTable also defines the owner which will be used to associate permissions with the script execution. 5.5. The smRunGroup The smRunGroup contains a single table, called the smRunTable, which lists all scripts that are currently running or have terminated recently. The smRunTable contains objects that allow the following operations: o retrieve status information from running scripts o control running scripts (suspend, resume, abort) o retrieve results from recently terminated scripts o control the remaining maximum lifetime of a running script o control how long script results are accessible Every row in the smRunTable contains the argument passed during script invocation, the result produced by the script and the script exit code. The smRunTable also provides information about the current run state as well as start and end time-stamps. There are three writable objects in the smRunTable. The smRunLifeTime object defines the maximum time a running script may run before it is terminated by the Script MIB implementation. The smRunExpireTime object defines the time that a completed script can stay in the smRunTable before it is aged out. The smRunControl object allows running scripts to be suspended, resumed, or aborted. Levi & Schoenwaelder Standards Track [Page 11] Internet-Draft Script MIB July 2000 6. Definitions DISMAN-SCRIPT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Unsigned32, mib-2 FROM SNMPv2-SMI RowStatus, TimeInterval, DateAndTime, StorageType, DisplayString FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; scriptMIB MODULE-IDENTITY LAST-UPDATED "200007070000Z" ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "David B. Levi Nortel Networks 4401 Great America Parkway Santa Clara, CA 95052-8185 U.S.A. Tel: +1 423 686 0432 E-mail: dlevi@nortelnetworks.com Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Tel: +49 531 391-3283 E-mail: schoenw@ibr.cs.tu-bs.de" DESCRIPTION "This MIB module defines a set of objects that allow to delegate management scripts to distributed managers." REVISION "200007070000Z" DESCRIPTION "Revised version, published as RFC XXXX." REVISION "199902221800Z" DESCRIPTION "Initial version, published as RFC 2592." ::= { mib-2 64 } -- -- The groups defined within this MIB module: Levi & Schoenwaelder Standards Track [Page 12] Internet-Draft Script MIB July 2000 -- smObjects OBJECT IDENTIFIER ::= { scriptMIB 1 } smNotifications OBJECT IDENTIFIER ::= { scriptMIB 2 } smConformance OBJECT IDENTIFIER ::= { scriptMIB 3 } -- -- Script language and language extensions. -- -- This group defines tables which list the languages and the -- language extensions supported by a script MIB implementation. -- Languages are uniquely identified by object identifier values. -- smLangTable OBJECT-TYPE SYNTAX SEQUENCE OF SmLangEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists supported script languages." ::= { smObjects 1 } smLangEntry OBJECT-TYPE SYNTAX SmLangEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular language." INDEX { smLangIndex } ::= { smLangTable 1 } SmLangEntry ::= SEQUENCE { smLangIndex Integer32, smLangLanguage OBJECT IDENTIFIER, smLangVersion SnmpAdminString, smLangVendor OBJECT IDENTIFIER, smLangRevision SnmpAdminString, smLangDescr SnmpAdminString } smLangIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally arbitrary, but unique identifier associated with this language entry. The value is expected to remain constant at least from one re-initialization of the entity's network management system Levi & Schoenwaelder Standards Track [Page 13] Internet-Draft Script MIB July 2000 to the next re-initialization. Note that the data type and the range of this object must be consistent with the definition of smScriptLanguage." ::= { smLangEntry 1 } smLangLanguage OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The globally unique identification of the language." ::= { smLangEntry 2 } smLangVersion OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of the language. The zero-length string shall be used if the language does not have a version number. It is suggested that the version number consist of one or more decimal numbers separated by dots, where the first number is called the major version number." ::= { smLangEntry 3 } smLangVendor OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An object identifer which identifies the vendor who provides the implementation of the language. This object identifer SHALL point to the object identifier directly below the enterprise object identifier {1 3 6 1 4 1} allocated for the vendor. The value must be the object identifier {0 0} if the vendor is not known." ::= { smLangEntry 4 } smLangRevision OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of the language implementation. The value of this object must be an empty string if version number of the implementation is unknown. Levi & Schoenwaelder Standards Track [Page 14] Internet-Draft Script MIB July 2000 It is suggested that the value consist of one or more decimal numbers separated by dots, where the first number is called the major version number." ::= { smLangEntry 5 } smLangDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the language." ::= { smLangEntry 6 } smExtsnTable OBJECT-TYPE SYNTAX SEQUENCE OF SmExtsnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists supported language extensions." ::= { smObjects 2 } smExtsnEntry OBJECT-TYPE SYNTAX SmExtsnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular language extension." INDEX { smLangIndex, smExtsnIndex } ::= { smExtsnTable 1 } SmExtsnEntry ::= SEQUENCE { smExtsnIndex Integer32, smExtsnExtension OBJECT IDENTIFIER, smExtsnVersion SnmpAdminString, smExtsnVendor OBJECT IDENTIFIER, smExtsnRevision SnmpAdminString, smExtsnDescr SnmpAdminString } smExtsnIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally arbitrary, but unique identifier associated with this language extension entry. The value is expected to remain constant at least from one re-initialization of the entity's network management system Levi & Schoenwaelder Standards Track [Page 15] Internet-Draft Script MIB July 2000 to the next re-initialization." ::= { smExtsnEntry 1} smExtsnExtension OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The globally unique identification of the language extension." ::= { smExtsnEntry 2 } smExtsnVersion OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of the language extension. It is suggested that the version number consist of one or more decimal numbers separated by dots, where the first number is called the major version number." ::= { smExtsnEntry 3 } smExtsnVendor OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An object identifer which identifies the vendor who provides the implementation of the extension. The object identifer value should point to the OID node directly below the enterprise OID {1 3 6 1 4 1} allocated for the vendor. The value must by the object identifier {0 0} if the vendor is not known." ::= { smExtsnEntry 4 } smExtsnRevision OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of the extension implementation. The value of this object must be an empty string if version number of the implementation is unknown. It is suggested that the value consist of one or more decimal numbers separated by dots, where the first number is called the major version number." ::= { smExtsnEntry 5 } Levi & Schoenwaelder Standards Track [Page 16] Internet-Draft Script MIB July 2000 smExtsnDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the language extension." ::= { smExtsnEntry 6 } -- -- Scripts known by the Script MIB implementation. -- -- This group defines a table which lists all known scripts. -- Scripts can be added and removed through manipulation of the -- smScriptTable. -- smScriptObjects OBJECT IDENTIFIER ::= { smObjects 3 } smScriptTable OBJECT-TYPE SYNTAX SEQUENCE OF SmScriptEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists and describes locally known scripts." ::= { smScriptObjects 1 } smScriptEntry OBJECT-TYPE SYNTAX SmScriptEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular script. Every script that is stored in non-volatile memory is required to appear in this script table." INDEX { smScriptOwner, smScriptName } ::= { smScriptTable 1 } SmScriptEntry ::= SEQUENCE { smScriptOwner SnmpAdminString, smScriptName SnmpAdminString, smScriptDescr SnmpAdminString, smScriptLanguage Integer32, smScriptSource DisplayString, smScriptAdminStatus INTEGER, smScriptOperStatus INTEGER, smScriptStorageType StorageType, smScriptRowStatus RowStatus, smScriptError SnmpAdminString } Levi & Schoenwaelder Standards Track [Page 17] Internet-Draft Script MIB July 2000 smScriptOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The manager who owns this row in the smScriptTable." ::= { smScriptEntry 1 } smScriptName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally-unique, administratively assigned name for this script. This object allows an smScriptOwner to have multiple entries in the smScriptTable. This value of this object may be used to derive the name (e.g. a file name) which is used by the Script MIB implementation to access the script in non-volatile storage. The details of this mapping are implementation specific. However, the mapping needs to ensure that scripts created by different owners with the same script name do not map to the same name in non-volatile storage." ::= { smScriptEntry 2 } smScriptDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A description of the purpose of the script." ::= { smScriptEntry 3 } smScriptLanguage OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object type identifies an entry in the smLangTable which is used to execute this script. The special value 0 may be used by hard-wired scripts that can not be modified and that are executed by internal functions. Set requests to change this object are invalid if the value of smScriptOperStatus is `enabled' or `compiling' and will result in an inconsistentValue error. Note that the data type and the range of this object must Levi & Schoenwaelder Standards Track [Page 18] Internet-Draft Script MIB July 2000 be consistent with the definition of smLangIndex." ::= { smScriptEntry 4 } smScriptSource OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "This object either contains a reference to the script source or an empty string. A reference must be given in the form of a Uniform Resource Locator (URL) as defined in RFC 2396. The allowed character sets and the encoding rules defined in RFC 2396 section 2 apply. When the smScriptAdminStatus object is set to `enabled', the Script MIB implementation will `pull' the script source from the URL contained in this object if the URL is not empty. An empty URL indicates that the script source is loaded from local storage. The script is read from the smCodeTable if the value of smScriptStorageType is volatile. Otherwise, the script is read from non-volatile storage. Note: This document does not mandate implementation of any specific URL scheme. A attempt to load a script from a nonsupported URL scheme will cause the smScriptOperStatus to report an `unknownProtocol' error. Set requests to change this object are invalid if the value of smScriptOperStatus is `enabled', `editing', `retrieving' or `compiling' and will result in an inconsistentValue error." DEFVAL { ''H } ::= { smScriptEntry 5 } smScriptAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2), editing(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object indicates the desired status of the script. See the definition of smScriptOperStatus for a description of the values. When the smScriptAdminStatus object is set to `enabled' and Levi & Schoenwaelder Standards Track [Page 19] Internet-Draft Script MIB July 2000 the smScriptOperStatus is `disabled' or one of the error states, the Script MIB implementation will `pull' the script source from the URL contained in the smScriptSource object if the URL is not empty." DEFVAL { disabled } ::= { smScriptEntry 6 } smScriptOperStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2), editing(3), retrieving(4), compiling(5), noSuchScript(6), accessDenied(7), wrongLanguage(8), wrongVersion(9), compilationFailed(10), noResourcesLeft(11), unknownProtocol(12), protocolFailure(13), genericError(14) } MAX-ACCESS read-only STATUS current DESCRIPTION "The actual status of the script in the runtime system. The value of this object is only meaningful when the value of the smScriptRowStatus object is `active'. The smScriptOperStatus object may have the following values: - `enabled' indicates that the script is available and can be started by a launch table entry. - `disabled' indicates that the script can not be used. - `editing' indicates that the script can be modified in the smCodeTable. - `retrieving' indicates that the script is currently being loaded from non-volatile storage or a remote system. - `compiling' indicates that the script is currently being compiled by the runtime system. - `noSuchScript' indicates that the script does not exist at the smScriptSource. Levi & Schoenwaelder Standards Track [Page 20] Internet-Draft Script MIB July 2000 - `accessDenied' indicates that the script can not be loaded from the smScriptSource due to a lack of permissions. - `wrongLanguage' indicates that the script can not be loaded from the smScriptSource because of a language mismatch. - `wrongVersion' indicates that the script can not be loaded from the smScriptSource because of a language version mismatch. - `compilationFailed' indicates that the compilation failed. - `noResourcesLeft' indicates that the runtime system does not have enough resources to load the script. - `unknownProtocol' indicates that the script could not be loaded from the smScriptSource because the requested protocol is not supported. - `protocolFailure' indicates that the script could not be loaded from the smScriptSource because of a protocol failure. - `genericError' indicates that the script could not be loaded due to an error condition not listed above. The `retrieving' and `compiling' states are transient states which will either lead to one of the error states or the `enabled' state. The `disabled' and `editing' states are administrative states which are only reached by explicit management operations. All launch table entries that refer to this script table entry shall have an smLaunchOperStatus value of `disabled' when the value of this object is not `enabled'." DEFVAL { disabled } ::= { smScriptEntry 7 } smScriptStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether this row and the script controlled by this row are kept in volatile storage and lost upon reboot or if this row is backed up by non-volatile or permanent storage. The script controlled by this row is written into local non-volatile storage if the following condition becomes Levi & Schoenwaelder Standards Track [Page 21] Internet-Draft Script MIB July 2000 true: (a) the URL contained in the smScriptSource object is empty and (b) the smScriptStorageType is `nonVolatile' and (c) the smScriptOperStatus is `enabled' Setting this object to `volatile' removes a script from non-volatile storage if the script controlled by this row has been in non-volatile storage before. Attempts to set this object to permanent will always fail with an inconsistentValue error. The value of smScriptStorageType is only meaningful if the value of the corresponding RowStatus object is `active'. If smScriptStorageType has the value permanent(4), then all objects whose MAX-ACCESS value is read-create must be writable, with the exception of the smScriptStorageType and smScriptRowStatus objects, which shall be read-only." DEFVAL { volatile } ::= { smScriptEntry 8 } smScriptRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "A control that allows entries to be added and removed from this table. Changing the smScriptRowStatus from `active' to `notInService' will remove the associated script from the runtime system. The value of smScriptOperStatus will be reset to `disabled'. Deleting conceptual rows from this table includes the deletion of all resources associated with this row. This implies that a script stored in non-volatile storage is removed from non-volatile storage. An entry may not exist in the `active' state unless all required objects in the entry have appropriate values. Rows that are not complete or not in service are not known by the script runtime system. Attempts to `destroy' a row or to set a row `notInService' while the script is executing will result in an inconsistentValue error. Levi & Schoenwaelder Standards Track [Page 22] Internet-Draft Script MIB July 2000 Attempts to `destroy' a row or to set a row `notInService' where the value of the smScriptStorageType object is `permanent' or `readOnly' will result in an inconsistentValue error." ::= { smScriptEntry 9 } smScriptError OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a descriptive error message if the transition into the operational status `enabled' failed. Implementations must first clear the error message to a zero-length string when a new attempt to change the script status is started. The value of this object is the zero-length string as long as no error occured." DEFVAL { ''H } ::= { smScriptEntry 10 } -- -- Access to script code via SNMP -- -- The smCodeTable allows script code to be read and modified -- via SNMP. -- smCodeTable OBJECT-TYPE SYNTAX SEQUENCE OF SmCodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the script code for scripts that are written via SNMP write operations." ::= { smScriptObjects 2 } smCodeEntry OBJECT-TYPE SYNTAX SmCodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular fragment of a script." INDEX { smScriptOwner, smScriptName, smCodeIndex } ::= { smCodeTable 1 } SmCodeEntry ::= SEQUENCE { smCodeIndex Unsigned32, Levi & Schoenwaelder Standards Track [Page 23] Internet-Draft Script MIB July 2000 smCodeText OCTET STRING, smCodeRowStatus RowStatus } smCodeIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value identifying this code fragment." ::= { smCodeEntry 1 } smCodeText OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..1024)) MAX-ACCESS read-create STATUS current DESCRIPTION "The code that makes up a fragment of a script. The format of this code fragment depends on the script language which is identified by the associated smScriptLanguage object." ::= { smCodeEntry 2 } smCodeRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "A control that allows entries to be added and removed from this table." ::= { smCodeEntry 3 } -- -- Script execution. -- -- This group defines tables which allow script execution to be -- initiated, suspended, resumed, and terminated. It also provides -- a mechanism for keeping a history of recent script executions -- and their results. -- smRunObjects OBJECT IDENTIFIER ::= { smObjects 4 } smLaunchTable OBJECT-TYPE SYNTAX SEQUENCE OF SmLaunchEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists and describes scripts that are ready to be executed together with their parameters." ::= { smRunObjects 1 } Levi & Schoenwaelder Standards Track [Page 24] Internet-Draft Script MIB July 2000 smLaunchEntry OBJECT-TYPE SYNTAX SmLaunchEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular executable script." INDEX { smLaunchOwner, smLaunchName } ::= { smLaunchTable 1 } SmLaunchEntry ::= SEQUENCE { smLaunchOwner SnmpAdminString, smLaunchName SnmpAdminString, smLaunchScriptOwner SnmpAdminString, smLaunchScriptName SnmpAdminString, smLaunchArgument OCTET STRING, smLaunchMaxRunning Unsigned32, smLaunchMaxCompleted Unsigned32, smLaunchLifeTime TimeInterval, smLaunchExpireTime TimeInterval, smLaunchStart Integer32, smLaunchControl INTEGER, smLaunchAdminStatus INTEGER, smLaunchOperStatus INTEGER, smLaunchRunIndexNext Integer32, smLaunchStorageType StorageType, smLaunchRowStatus RowStatus, smLaunchError SnmpAdminString } smLaunchOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The manager who owns this row in the smLaunchTable. Every instance of a running script started from a particular entry in the smLaunchTable (i.e. entries in the smRunTable) will be owned by the same smLaunchOwner used to index the entry in the smLaunchTable. This owner is not necessarily the same as the owner of the script itself (smLaunchScriptOwner)." ::= { smLaunchEntry 1 } smLaunchName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally-unique, administratively assigned name for this launch table entry. This object allows an smLaunchOwner to have multiple entries in the smLaunchTable. The smLaunchName Levi & Schoenwaelder Standards Track [Page 25] Internet-Draft Script MIB July 2000 is an arbitrary name that must be different from any other smLaunchTable entries with the same smLaunchOwner but can be the same as other entries in the smLaunchTable with different smLaunchOwner values. Note that the value of smLaunchName is not related in any way to the name of the script being launched." ::= { smLaunchEntry 2 } smLaunchScriptOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object in combination with the value of smLaunchScriptName identifies the script that can be launched from this smLaunchTable entry. Attempts to write this object will fail with an inconsistentValue error if the value of smLaunchOperStatus is `enabled'." ::= { smLaunchEntry 3 } smLaunchScriptName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object in combination with the value of the smLaunchScriptOwner identifies the script that can be launched from this smLaunchTable entry. The zero-length string may be used to point to a non-existing script. Attempts to write this objects will fail with an inconsistentValue error if the value of smLaunchOperStatus is `enabled'." DEFVAL { ''H } ::= { smLaunchEntry 4 } smLaunchArgument OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "The argument supplied to the script. When a script is invoked, the value of this object is used to initialize the smRunArgument object." DEFVAL { ''H } ::= { smLaunchEntry 5 } smLaunchMaxRunning OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-create Levi & Schoenwaelder Standards Track [Page 26] Internet-Draft Script MIB July 2000 STATUS current DESCRIPTION "The maximum number of concurrently running scripts that may be invoked from this entry in the smLaunchTable. Lowering the current value of this object does not affect any scripts that are already executing." DEFVAL { 1 } ::= { smLaunchEntry 6 } smLaunchMaxCompleted OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of finished scripts invoked from this entry in the smLaunchTable allowed to be retained in the smRunTable. Whenever the value of this object is changed and whenever a script terminates, entries in the smRunTable are deleted if necessary until the number of completed scripts is smaller than the value of this object. Scripts whose smRunEndTime value indicates the oldest completion time are deleted first." DEFVAL { 1 } ::= { smLaunchEntry 7 } smLaunchLifeTime OBJECT-TYPE SYNTAX TimeInterval UNITS "centi-seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The default maximum amount of time a script launched from this entry may run. The value of this object is used to initialize the smRunLifeTime object when a script is launched. Changing the value of an smLaunchLifeTime instance does not affect scripts previously launched from this entry." DEFVAL { 360000 } ::= { smLaunchEntry 8 } smLaunchExpireTime OBJECT-TYPE SYNTAX TimeInterval UNITS "centi-seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The default maximum amount of time information about a script launched from this entry is kept in the smRunTable after the script has completed execution. The value of this object is used to initialize the smRunExpireTime Levi & Schoenwaelder Standards Track [Page 27] Internet-Draft Script MIB July 2000 object when a script is launched. Changing the value of an smLaunchExpireTime instance does not affect scripts previously launched from this entry." DEFVAL { 360000 } ::= { smLaunchEntry 9 } smLaunchStart OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to start the execution of scripts. When retrieved, the value will be the value of smRunIndex for the last script that started execution by manipulating this object. The value will be zero if no script started execution yet. A script is started by setting this object to an unused smRunIndex value. A new row in the smRunTable will be created which is indexed by the value supplied by the set-request in addition to the value of smLaunchOwner and smLaunchName. An unused value can be obtained by reading the smLaunchRunIndexNext object. Setting this object to the special value 0 will start the script with a self-generated smRunIndex value. The consequence is that the script invoker has no reliable way to determine the smRunIndex value for this script invocation and that the invoker has therefore no way to obtain the results from this script invocation. The special value 0 is however useful for scheduled script invocations. If this object is set, the following checks must be performed: 1) The value of the smLaunchOperStatus object in this entry of the smLaunchTable must be `enabled'. 2) The values of smLaunchScriptOwner and smLaunchScriptName of this row must identify an existing entry in the smScriptTable. 3) The value of smScriptOperStatus of this entry must be `enabled'. 4) The principal performing the set operation must have read access to the script. This must be checked by calling the isAccessAllowed abstract service interface defined in RFC 2271 on the row in the smScriptTable identified by smLaunchScriptOwner and smLaunchScriptName. The isAccessAllowed abstract service interface must be called on all columnar objects in the smScriptTable with Levi & Schoenwaelder Standards Track [Page 28] Internet-Draft Script MIB July 2000 a MAX-ACCESS value different than `not-accessible'. The test fails as soon as a call indicates that access is not allowed. 5) If the value provided by the set operation is not 0, a check must be made that the value is currently not in use. Otherwise, if the value provided by the set operation is 0, a suitable unused value must be generated. 6) The number of currently executing scripts invoked from this smLaunchTable entry must be less than smLaunchMaxRunning. Attempts to start a script will fail with an inconsistentValue error if one of the checks described above fails. Otherwise, if all checks have been passed, a new entry in the smRunTable will be created indexed by smLaunchOwner, smLaunchName and the new value for smRunIndex. The value of smLaunchArgument will be copied into smRunArgument, the value of smLaunchLifeTime will be copied to smRunLifeTime, and the value of smLaunchExpireTime will be copied to smRunExpireTime. The smRunStartTime will be set to the current time and the smRunState will be set to `initializing' before the script execution is initiated in the appropriate runtime system. Note that the data type and the range of this object must be consistent with the smRunIndex object. Since this object might be written from the scheduling MIB, the data type Integer32 rather than Unsigned32 is used." DEFVAL { 0 } ::= { smLaunchEntry 10 } smLaunchControl OBJECT-TYPE SYNTAX INTEGER { abort(1), suspend(2), resume(3), nop(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to request a state change for all running scripts in the smRunTable that were started from this row in the smLaunchTable. Levi & Schoenwaelder Standards Track [Page 29] Internet-Draft Script MIB July 2000 Setting this object to abort(1), suspend(2) or resume(3) will set the smRunControl object of all applicable rows in the smRunTable to abort(1), suspend(2) or resume(3) respectively. The phrase `applicable rows' means the set of rows which were created from this entry in the smLaunchTable and whose value of smRunState allows the corresponding state change as described in the definition of the smRunControl object. Setting this object to nop(4) has no effect." DEFVAL { nop } ::= { smLaunchEntry 11 } smLaunchAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2), autostart(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object indicates the desired status of this launch table entry. The values enabled(1) and autostart(3) both indicate that the launch table entry should transition into the operational enabled(1) state as soon as the associated script table entry is enabled(1). The value autostart(3) further indicates that a script is being started automatically by conceptually writing the value 0 into the associated smLaunchStart object during the transition from the `disabled' into the `enabled' operational state." DEFVAL { disabled } ::= { smLaunchEntry 12 } smLaunchOperStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the actual status of this launch table entry. An `enabled' launch table entry can be used to start scripts while a `disabled' launch table entry will refuse any attempts to start scripts. The value `enabled' requires that the smLaunchRowStatus object is active. The value `disabled' requires that there are no entries in the Levi & Schoenwaelder Standards Track [Page 30] Internet-Draft Script MIB July 2000 smRunTable associated with this smLaunchTable entry." DEFVAL { disabled } ::= { smLaunchEntry 13 } smLaunchRunIndexNext OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This variable is used for creating rows in the smRunTable. The value of this variable is a currently unused value for smRunIndex, which can be written into the smLaunchStart object associated with this row to launch a script. The value returned when reading this variable must be unique for the smLaunchOwner and smLaunchName associated with this row. Subsequent attempts to read this variable must return different values. This variable will return the special value 0 if no new rows can be created. Note that the data type and the range of this object must be consistent with the definition of smRunIndex." ::= { smLaunchEntry 14 } smLaunchStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines if this row is kept in volatile storage and lost upon reboot or if this row is backed up by stable storage. The value of smLaunchStorageType is only meaningful if the value of the corresponding RowStatus object is active. If smLaunchStorageType has the value permanent(4), then all objects whose MAX-ACCESS value is read-create must be writable, with the exception of the smLaunchStorageType and smLaunchRowStatus objects, which shall be read-only." DEFVAL { volatile } ::= { smLaunchEntry 15 } smLaunchRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION Levi & Schoenwaelder Standards Track [Page 31] Internet-Draft Script MIB July 2000 "A control that allows entries to be added and removed from this table. Attempts to `destroy' a row or to set a row `notInService' while scripts started from this launch table entry are running will result in an inconsistentValue error. Attempts to `destroy' a row or to set a row `notInService' where the value of the smLaunchStorageType object is `permanent' or `readOnly' will result in an inconsistentValue error." ::= { smLaunchEntry 16 } smLaunchError OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a descriptive error message if an attempt to launch a script fails. Implementations must first clear the error message to a launch a script is started. The value of this object is the zero-length string as long as no error occured." DEFVAL { ''H } ::= { smLaunchEntry 17 } smRunTable OBJECT-TYPE SYNTAX SEQUENCE OF SmRunEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists and describes scripts that are currently running or have been running in the past." ::= { smRunObjects 2 } smRunEntry OBJECT-TYPE SYNTAX SmRunEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular running or finished script." INDEX { smLaunchOwner, smLaunchName, smRunIndex } ::= { smRunTable 1 } SmRunEntry ::= SEQUENCE { smRunIndex Integer32, smRunArgument OCTET STRING, Levi & Schoenwaelder Standards Track [Page 32] Internet-Draft Script MIB July 2000 smRunStartTime DateAndTime, smRunEndTime DateAndTime, smRunLifeTime TimeInterval, smRunExpireTime TimeInterval, smRunExitCode INTEGER, smRunResult OCTET STRING, smRunControl INTEGER, smRunState INTEGER, smRunError SnmpAdminString } smRunIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally arbitrary, but unique identifier associated with this running or finished script. This value must be unique for all rows in the smRunTable with the same smLaunchOwner and smLaunchName. Note that the data type and the range of this object must be consistent with the definition of smLaunchRunIndexNext and smLaunchStart." ::= { smRunEntry 1 } smRunArgument OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The argument supplied to the script when it started." DEFVAL { ''H } ::= { smRunEntry 2 } smRunStartTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when the execution started. The value '0000000000000000'H is returned if the script has not started yet." DEFVAL { '0000000000000000'H } ::= { smRunEntry 3 } smRunEndTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current Levi & Schoenwaelder Standards Track [Page 33] Internet-Draft Script MIB July 2000 DESCRIPTION "The date and time when the execution terminated. The value '0000000000000000'H is returned if the script has not terminated yet." DEFVAL { '0000000000000000'H } ::= { smRunEntry 4 } smRunLifeTime OBJECT-TYPE SYNTAX TimeInterval UNITS "centi-seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies how long the script can execute. This object returns the remaining time that the script may run. The object is initialized with the value of the associated smLaunchLifeTime object and ticks backwards. The script is aborted immediately when the value reaches 0. The value of this object may be set in order to increase or reduce the remaining time that the script may run. Setting this value to 0 will abort script execution immediately, and, if the value of smRunExpireTime is also 0, will remove this entry from the smRunTable once it has terminated. If smRunLifeTime is set to its maximum value (2147483647), either by a set operation or by its initialization from the smLaunchLifeTime object, then it will not tick backwards. A running script with a maximum smRunLifeTime value will thus never be terminated with a `lifeTimeExceeded' exit code. The value of smRunLifeTime reflects the real-time execution time as seen by the outside world. The value of this object will always be 0 for a script that finished execution, that is smRunState has the value `terminated'. The value of smRunLifeTime does not change while a script is suspended, that is smRunState has the value `suspended'. Note that this does not affect set operations. It is legal to modify smRunLifeTime via set operations while a script is suspended." ::= { smRunEntry 5 } smRunExpireTime OBJECT-TYPE SYNTAX TimeInterval UNITS "centi-seconds" MAX-ACCESS read-write STATUS current DESCRIPTION Levi & Schoenwaelder Standards Track [Page 34] Internet-Draft Script MIB July 2000 "The value of this object specifies how long this row can exist in the smRunTable after the script has terminated. This object returns the remaining time that the row may exist before it is aged out. The object is initialized with the value of the associated smLaunchExpireTime object and ticks backwards. The entry in the smRunTable is destroyed when the value reaches 0 and the smRunState has the value `terminated'. The value of this object may be set in order to increase or reduce the remaining time that the row may exist. Setting the value to 0 will destroy this entry as soon as the smRunState has the value `terminated'." ::= { smRunEntry 6 } smRunExitCode OBJECT-TYPE SYNTAX INTEGER { noError(1), halted(2), lifeTimeExceeded(3), noResourcesLeft(4), languageError(5), runtimeError(6), invalidArgument(7), securityViolation(8), genericError(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the reason why a script finished execution. The smRunExitCode code may have one of the following values: - `noError', which indicates that the script completed successfully without errors; - `halted', which indicates that the script was halted by a request from an authorized manager; - `lifeTimeExceeded', which indicates that the script exited because a time limit was exceeded; - `noResourcesLeft', which indicates that the script exited because it ran out of resources (e.g. memory); - `languageError', which indicates that the script exited because of a language error (e.g. a syntax error in an interpreted language); - `runtimeError', which indicates that the script exited Levi & Schoenwaelder Standards Track [Page 35] Internet-Draft Script MIB July 2000 due to a runtime error (e.g. a division by zero); - `invalidArgument', which indicates that the script could not be run because of invalid script arguments; - `securityViolation', which indicates that the script exited due to a security violation; - `genericError', which indicates that the script exited for an unspecified reason. If the script has not yet begun running, or is currently running, the value will be `noError'." DEFVAL { noError } ::= { smRunEntry 7 } smRunResult OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The result value produced by the running script. Note that the result may change while the script is executing." DEFVAL { ''H } ::= { smRunEntry 8 } smRunControl OBJECT-TYPE SYNTAX INTEGER { abort(1), suspend(2), resume(3), nop(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object indicates the desired status of the script execution defined by this row. Setting this object to `abort' will abort execution if the value of smRunState is `initializing', `executing', `suspending', `suspended' or `resuming'. Setting this object to `abort' when the value of smRunState is `aborting' or `terminated' will result in an inconsistentValue error. Setting this object to `suspend' will suspend execution if the value of smRunState is `executing'. Setting this object to `suspend' will cause an inconsistentValue error if the value of smRunState is not `executing'. Levi & Schoenwaelder Standards Track [Page 36] Internet-Draft Script MIB July 2000 Setting this object to `resume' will resume execution if the value of smRunState is `suspending' or `suspended'. Setting this object to `resume' will cause an inconsistentValue error if the value of smRunState is not `suspending' or `suspended'. Setting this object to nop(4) has no effect." DEFVAL { nop } ::= { smRunEntry 9 } smRunState OBJECT-TYPE SYNTAX INTEGER { initializing(1), executing(2), suspending(3), suspended(4), resuming(5), aborting(6), terminated(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the script's execution status. If the script has been invoked but has not yet begun execution, the value will be `initializing'. If the script is running, the value will be `executing'. A script which received a request to suspend execution but which did not actually suspend execution will be `suspending'. A script which has suspended execution will be `suspended'. A script which received a request to resume execution but which is not yet running is `resuming'. The resuming state will finally lead to the `executing' state. A script which received a request to abort execution but which is still running is `aborting'. A script which stopped execution is `terminated'." ::= { smRunEntry 10 } smRunError OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a descriptive error message if the script terminates in an abnormally. An implementation must store a descriptive error message in this object if the script exits with the smRunExitCode `genericError'. The value of this object is the zero-length string as long as the smRunExitCode has the value `noError'" Levi & Schoenwaelder Standards Track [Page 37] Internet-Draft Script MIB July 2000 DEFVAL { ''H } ::= { smRunEntry 11 } -- -- Notifications. The definition of smTraps makes notification -- registrations reversible (see STD 58, RFC 2578). -- smTraps OBJECT IDENTIFIER ::= { smNotifications 0 } smScriptAbort NOTIFICATION-TYPE OBJECTS { smRunExitCode, smRunEndTime, smRunError } STATUS current DESCRIPTION "This notification is generated whenever a running script terminates with an smRunExitCode unequal to `noError'." ::= { smTraps 1 } smScriptResult NOTIFICATION-TYPE OBJECTS { smRunResult } STATUS current DESCRIPTION "This notification can be used by scripts to notify other management applications about script results. It can be used to notify managers about a script result. This notification is not automatically generated by the script MIB implementation. It is the responsibility of the executing script to emit this notification where it is appropriate to do so." ::= { smTraps 2 } -- conformance information smCompliances OBJECT IDENTIFIER ::= { smConformance 1 } smGroups OBJECT IDENTIFIER ::= { smConformance 2 } -- compliance statements smCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the script MIB." MODULE -- this module MANDATORY-GROUPS { smLanguageGroup, smScriptGroup, smLaunchGroup, smRunGroup } GROUP smCodeGroup DESCRIPTION Levi & Schoenwaelder Standards Track [Page 38] Internet-Draft Script MIB July 2000 "The smCodeGroup is mandatory only for those implementations that support the downloading of scripts via SNMP." OBJECT smScriptSource MIN-ACCESS read-only DESCRIPTION "The smScriptSource object is read-only for implementations that are not able to download script code from a URL." OBJECT smLaunchArgument DESCRIPTION "A compliant implementation has to support a minimum size for smLaunchArgument of 255 octets." OBJECT smRunArgument DESCRIPTION "A compliant implementation has to support a minimum size for smRunArgument of 255 octets." OBJECT smRunResult DESCRIPTION "A compliant implementation has to support a minimum size for smRunResult of 255 octets." OBJECT smRunState DESCRIPTION "A compliant implementation does not have to support script suspension and the smRunState `suspended'. Such an implementation will change into the `suspending' state when the smRunControl is set to `suspend' and remain in this state until smRunControl is set to `resume' or the script terminates." ::= { smCompliances 1 } smLanguageGroup OBJECT-GROUP OBJECTS { smLangLanguage, smLangVersion, smLangVendor, smLangRevision, smLangDescr, smExtsnExtension, smExtsnVersion, smExtsnVendor, smExtsnRevision, smExtsnDescr } STATUS current DESCRIPTION "A collection of objects providing information about the capabilities of the scripting engine." ::= { smGroups 1 } smScriptGroup OBJECT-GROUP OBJECTS { Levi & Schoenwaelder Standards Track [Page 39] Internet-Draft Script MIB July 2000 smScriptDescr, smScriptLanguage, smScriptSource, smScriptAdminStatus, smScriptOperStatus, smScriptStorageType, smScriptRowStatus } STATUS current DESCRIPTION "A collection of objects providing information about installed scripts." ::= { smGroups 2 } smCodeGroup OBJECT-GROUP OBJECTS { smCodeText, smCodeRowStatus } STATUS current DESCRIPTION "A collection of objects used to download or modify scripts by using SNMP set requests." ::= { smGroups 3 } smLaunchGroup OBJECT-GROUP OBJECTS { smLaunchScriptOwner, smLaunchScriptName, smLaunchArgument, smLaunchMaxRunning, smLaunchMaxCompleted, smLaunchLifeTime, smLaunchExpireTime, smLaunchStart, smLaunchControl, smLaunchAdminStatus, smLaunchOperStatus, smLaunchRunIndexNext, smLaunchStorageType, smLaunchRowStatus } STATUS current DESCRIPTION "A collection of objects providing information about scripts that can be launched." ::= { smGroups 4 } smRunGroup OBJECT-GROUP OBJECTS { Levi & Schoenwaelder Standards Track [Page 40] Internet-Draft Script MIB July 2000 smRunArgument, smRunStartTime, smRunEndTime, smRunLifeTime, smRunExpireTime, smRunExitCode, smRunResult, smRunState, smRunControl, smRunError } STATUS current DESCRIPTION "A collection of objects providing information about running scripts." ::= { smGroups 5 } smNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { smScriptAbort, smScriptResult } STATUS current DESCRIPTION "The notifications emitted by the script MIB." ::= { smGroups 6 } END Levi & Schoenwaelder Standards Track [Page 41] Internet-Draft Script MIB July 2000 7. Usage Examples This section presents some examples that explain how a manager can use the Script MIB defined in this memo. The purpose of these examples is to explain the steps that are normally used to delegate management scripts. 7.1. Pushing a Script via SNMP This example explains the steps performed by a manager to push a script into a distributed manager. 1. The manager first checks the smLangTable and the smExtsnTable in order to select the appropriate script or language. 2. The manager creates a row in the smScriptTable by issuing an SNMP set-request. The smScriptRowStatus object is set to `createAndWait' and the smScriptSource object is set to an empty string. The smScriptLanguage object is set to the language in which the script was written. The smScriptStorageType object is set to `volatile' to indicate that the script will be loaded via the smCodeTable. The smScriptOwner is set to a string which identifies the principal who owns the new row. The smScriptName defines the administratively assigned unique name for the script. 3. The manager sets the smScriptRowStatus object to `active' and the smScriptAdminStatus object to `editing'. 4. The manager pushes the script to the distributed manager by issuing a couple of SNMP set-requests to fill the smCodeTable. 5. Once the whole script has been transferred, the manager sends a set-request to set the smScriptAdminStatus object to `enabled'. The Script MIB implementation now makes the script accessible to the runtime system. This might include the compilation of the script if the language requires a compilation step. 6. The manager polls the smScriptOperStatus object until the value is either `enabled' or one of the error status codes. The script can only be used if the value of smScriptOperStatus is `enabled'. 7. If the manager wants to store the script in local non-volatile storage, it should send a set-request which changes the smScriptStorageType object to `nonVolatile'. Levi & Schoenwaelder Standards Track [Page 42] Internet-Draft Script MIB July 2000 7.2. Pulling a Script from a URL This example explains the steps performed by a manager to cause a distributed manager to pull a script from a URL. 1. The manager first checks the smLangTable and the smExtsnTable in order to select the appropriate script or language. 2. The manager creates a row in the smScriptTable by issuing an SNMP set-request. The smScriptRowStatus object is set to `createAndWait' and the smScriptSource object is set to the URL which points to the script source. The smScriptLanguage object is set to the language in which the script was written. The smScriptOwner is set to a string which identifies the principal who owns the new row. The smScriptName defines the administratively assigned unique name for the script. 3. The manager sets the smScriptRowStatus object to `active'. 4. The manager sends a set-request to set the smScriptAdminStatus object to `enabled'. The Script MIB implementation now makes the script accessible to the runtime system. This causes a retrieval operation to pull the script from the URL stored in smScriptSource. This retrieval operation might be followed by a compile operation if the language requires a compilation step. 5. The manager polls the smScriptOperStatus object until the value is either `enabled' or one of the error status codes. The script can only be used if the value of smScriptOperStatus is `enabled'. 6. If the manager wants to store the script in local non-volatile storage, it should send a set-request which changes the smScriptStorageType object to `nonVolatile'. 7.3. Modifying an Existing Script This section explains how a manager can modify a script by sending SNMP set-requests. 1. First, the script is de-activated by setting the smScriptAdminStatus to `disabled'. 2. The manager polls the smScriptOperStatus object until the value is `disabled'. 3. The manager sets smScriptSource to an empty string and smScriptAdminStatus to `editing'. This makes the script source available in the smCodeTable. Levi & Schoenwaelder Standards Track [Page 43] Internet-Draft Script MIB July 2000 4. The manager polls the smScriptOperStatus object until the value is `editing'. 5. The manager sends SNMP set-requests to modify the script in the smCodeTable. 6. The manager sends a set-request to set the smScriptAdminStatus object to `enabled'. The Script MIB implementation now makes the script accessible to the runtime system. This might include the compilation of the script if the language requires a compilation step. 7. The manager polls the smScriptOperStatus object until the value is either `enabled' or one of the error status codes. The script can only be used if the value of smScriptOperStatus is `enabled'. 7.4. Removing an Existing Script This section explains how a manager can remove a script from a distributed manager. 1. First, the manager sets the smScriptAdminStatus to `disabled'. This will ensure that no new scripts can be started while running scripts finish their execution. 2. The manager polls the smScriptOperStatus object until the value is `disabled'. 3. The manager sends an SNMP set-request to change the smScriptRowStatus object to `destroy'. This will remove the row and all associated resources from the Script MIB implementation. 7.5. Creating a Launch Button This section explains how a manager can create a launch button for starting a script. 1. The manager, who is identified by an smLaunchOwner value, first chooses a name for the new row in the smLaunchTable. The manager sends an SNMP set-request to set the smLaunchRowStatus object for this smLaunchOwner and smLaunchName to `createAndWait'. 2. The manager fills the new smLaunchTable row with all required parameters. The smLaunchScriptOwner and smLaunchScriptName values point to the script that should be started from this launch button. Levi & Schoenwaelder Standards Track [Page 44] Internet-Draft Script MIB July 2000 3. The manager sets the smLaunchRowStatus object to `active'. 4. The manager sends a set-request to change smLaunchAdminStatus to `enabled' once the new smLaunchTable row is complete. 5. The manager polls the smLaunchOperStatus object until the value is `enabled'. 7.6. Launching a Script This section explains the suggested way to launch a script from a given launch button. 1. The manager first retrieves the value of smLaunchRunIndexNext from the launch button selected to start the script. 2. The manager sends an SNMP set-request to set the smLaunchStart object to the value obtained in step 1. This will launch the script if all necessary pre-conditions are satisfied (see the definition of smLaunchStart for more details). The manager can also provide the smLaunchArgument in the same set-request that is used to start the script. Upon successful start, a new row will be created in the smRunTable indexed by smLaunchOwner, smLaunchName and the value written to smLaunchStart. 3. The manager polls the smRunState object until the value is either `executing' (the default case), `suspended' or `terminated'. The first step is not required. A manager can also try to guess an unused value for smRunIndex if he wants to start script in a single transaction. A manager can also use the special value 0 if he does not care about the results produced by the script. 7.7. Suspending a Running Script This section explains how a manager can suspend a running script. [ XXX This must be aligned with the resolution of issue 16.] 7.8. Resuming a Suspended Script This section explains how a manager can resume a suspended script. [ XXX This must be aligned with the resolution of issue 16.] Levi & Schoenwaelder Standards Track [Page 45] Internet-Draft Script MIB July 2000 7.9. Terminating a Running Script This section explains two ways to terminate a running script. The first approach is as follows: 1. The manager sets the smRunControl object of the running script or the smLaunchControl object of the launch button used to start the running script to `abort'. Setting smLaunchControl will abort all running scripts started from the launch button while smRunControl will only abort the running script associated with the smRunControl instance. 2. The manager polls the smRunState object until the value is `terminated'. The second way to terminate a script is to set the smRunLifeTime to zero which causes the runtime system to terminate the script with a `lifeTimeExceeded' exit code: 1. The manager changes the value of smRunLifeTime to 0. This causes the Script MIB implementation to abort the script because the remaining life time has expired. 2. The manager polls the smRunState object until the value is `terminated'. Note that changing the smRunLifeTime value can also be used to increase the permitted lifetime of a running script. For example, a manager can choose to set smRunLifeTime to a small fixed time interval and increase the value periodically. This strategy has the nice effect that scripts terminate automatically if the manager loses contact with the Script MIB engine. 7.10. Removing a Launch Button This section explains how a manager can remove a launch button from a distributed manager. 1. First, the manager sets the smLaunchAdminStatus to `disabled'. This will ensure that no new scripts can be started from this launch button while running script will finish their execution. 2. The manager polls the smLaunchOperStatus object until the value is `disabled'. 3. The manager sends an SNMP set-request to change the smLaunchRowStatus object to `destroy'. This will remove the row and all associated resources from the Script MIB implementation. Levi & Schoenwaelder Standards Track [Page 46] Internet-Draft Script MIB July 2000 8. VACM Configuration Examples This section shows how the view-based access control model defined in RFC 2575 [RFC2575] can be configured to control access to the script MIB. 8.1. Sandbox for Guests The first example demonstrates how to configure VACM to give the members of the VACM group "guest" limited access to the script MIB. The MIB views defined below give the members of the "guest" group a sandbox where they can install and start their own scripts, but not access any other scripts maintained by the Script MIB implementation. vacmAccessReadView."guest"."".usm.authNoPriv = "guestReadView" vacmAccessWriteView."guest"."".usm.authNoPriv = "guestWriteView" The guestReadView grants read access to the smLangTable, the smExtsnTable and to all the table entries owned by "guest": guestReadView: smLangTable (included) smExtsnTable (included) smScriptObjects.*.*.*."guest" (included) smRunObjects.*.*.*."guest" (included) The guestWriteView grants write access to all the table entries owned by "guest": guestWriteView: smScriptObjects.*.*.*."guest" (included) smRunObjects.*.*.*."guest" (included) 8.2. Sharing Scripts This example demonstrates how VACM can be used to share a repository of scripts between the members of the "senior" and the members of the "junior" VACM group: vacmAccessReadView."junior"."".usm.authNoPriv = "juniorReadView" vacmAccessWriteView."junior"."".usm.authNoPriv = "juniorWriteView" juniorReadView: smLangTable (included) smExtsnTable (included) Levi & Schoenwaelder Standards Track [Page 47] Internet-Draft Script MIB July 2000 smScriptObjects.*.*.*."junior" (included) smRunObjects.*.*.*."junior" (included) smScriptObjects.*.*.*."utils" (included) juniorWriteView: smScriptObjects.*.*.*."junior" (included) smRunObjects.*.*.*."junior" (included) The definitions above allow the members of the "junior" VACM group to start the scripts owned by "utils" in addition to the script the members of the "junior" VACM group installed themself. This is accomplished by giving the members of "junior" read access to scripts in "utils". This allows members of "junior" to create entries in the smLauchTable which refer to scripts in "utils", and to launch those scripts using these entries in the smLaunchTable. vacmAccessReadView."senior"."".usm.authNoPriv = "seniorReadView" vacmAccessWriteView."senior"."".usm.authNoPriv = "seniorWriteView" seniorReadView: smLangTable (included) smExtsnTable (included) smScriptObjects.*.*.*."senior" (included) smRunObjects.*.*.*."senior" (included) smScriptObjects.*.*.*."utils" (included) seniorWriteView: smScriptObjects.*.*.*."senior" (included) smRunObjects.*.*.*."senior" (included) smScriptObjects.*.*.*."utils" (included) The definitions for the members of the "senior" VACM group allow to start the scripts owned by "utils" in addition to the script the members of the "senior" VACM group installed themself. The third write access rule in the seniorWriteView also grants the permission to install scripts owned by "utils". The members of the "senior" VACM group therefore have the permissions to install and modify scripts that can be called by the members of the "junior" VACM group. 8.3. Emergency Scripts This example demonstrates how VACM can be used to allow the members of the "junior" VACM group to launch scripts that are executed with the permissions associated with the "emergency" owner. This works by adding the following rules to the juniorReadView and the juniorWriteView: Levi & Schoenwaelder Standards Track [Page 48] Internet-Draft Script MIB July 2000 juniorReadView: smScriptObjects.*.*.*."emergency" (included) smRunObjects.*.*.*."emergency" (included) juniorWriteView smLaunchStart."emergency" (included) smLaunchArgument."emergency" (included) The rules added to the juniorReadView grant read access to the scripts, the launch buttons and the results owned by "emergency". The rules added to the juniorWriteView grant write permissions to the smLaunchStart and smLaunchArgument variables ownded by "emergency". Members of the "junior" VACM group can therefore start scripts that will execute under the owner "emergency". seniorReadView: smScriptObjects.*.*.*."emergency" (included) smRunObjects.*.*.*."emergency" (included) seniorWriteView: smScriptObjects.*.*.*."emergency" (included) smRunObjects.*.*.*."emergency" (included) The rules added to the seniorReadView and the seniorWriteView will give the members of the "senior" VACM group the rights to install emergency scripts and to configure appropriate launch buttons. 9. IANA Considerations The Internet Assigned Numbers Authority (IANA) is responsible for maintaining a MIB module which provides OID registrations for well- known languages. The IANA language registry is intented to reduce interoperability problems by providing a single list of well-known languages. However, it is of course still possible to register languages in private OID spaces. Registering languages in private spaces is especially attractive if a language is used for experimentation or if a language is only used in environments where the distribution of MIB modules with the language registration does not cause any maintenance problems. Any additions or changes to the list of languages registered via IANA require Designated Expert Review as defined in the IANA guidelines [RFC2434]. The Designated Expert will be selected by the IESG Area Director for the IETF Operations and Management Area. Levi & Schoenwaelder Standards Track [Page 49] Internet-Draft Script MIB July 2000 10. Security Considerations This MIB provides the ability to distribute applications written in an arbitrary language to remote systems in a network. The security features of the languages available in a particular implementation should be taken into consideration when deploying an implementation of this MIB. To facilitate the provisioning of access control by a security administrator using the View-Based Access Control Model (VACM) defined in RFC 2575 [RFC2575] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index". Such an initial index has a syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. All entries in related tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the "column" subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. More elaborate configurations are possible. The VACM access control mechanism described above provides control over SNMP access to Script MIB objects. There are a number of other access control issues that are outside of the scope of this MIB. For example, access control on URLs, especially those that use the file scheme, must be realized by the underlying operating system. A mapping of the owner index value to a local operating system security user identity should be used by an implementation of this MIB to control access to operating system resources when resolving URLs or executing scripts. 11. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of Levi & Schoenwaelder Standards Track [Page 50] Internet-Draft Script MIB July 2000 licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 12. Changes from RFC 2592 The following list documents major changes from the previous version of this document, published as RFC 2592: - Updated the boilerplate and the references. - Added revision clauses to the module identity macro. - Various typos have been fixed. - Added SIZE restriction to smScriptName which is consistent with smLaunchScriptName. Added DEFVAL and some clarifying text on the usage of a zero-length string to smLaunchScriptName. - Clarified under which conditions changes to smScriptLanguage are invalid. - Added new smScriptError and smLaunchError objects. - Setting smRunLifeTime to its maximum value now disables the timer so that scripts can run forever. - Added the `autostart' enumeration to the smLaunchAdminStatus object which allows to launch scripts during the disable->enabled transition of smLaunchOperStatus. - Added an additional step to the "creating a launch button" procedure which sets the smLaunchRowStatus to active. - Added a final polling step in the procedure to launch a script. - Added a final polling step in the procedure to terminate a running script. Levi & Schoenwaelder Standards Track [Page 51] Internet-Draft Script MIB July 2000 13. Open Issues 01: closed 02: closed 03: closed 04: closed 05: Index smLangTable and smExtsnTable by name rather than Integer32. (Wes) 06: Dependencies between scripts and script versioning. (Eamonn) 07: Storage type of script code versus storage type of script meta information. (quittek, Schoenwaelder) 08: closed 09: Add procedures for suspend/resume/purge to section 7. (This requires to first solve issue 16.) (Strauss) 10: Any changes needed for editing in the SNMP code table? (Eamonn/Schoenwaelder) 11: Script resource consumption indication (in the run table). (Quittek) 12: closed 13: closed 14: closed 15: Align the security considerations with the boilerplate text? (Schoenwaelder) 16: Handling of suspend/resume on runtime engines that do not support suspend/resume? (Schoenwaelder) 14. Acknowledgments This document was produced by the IETF Distributed Management (DISMAN) working group. Levi & Schoenwaelder Standards Track [Page 52] Internet-Draft Script MIB July 2000 15. References [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999 Levi & Schoenwaelder Standards Track [Page 53] Internet-Draft Script MIB July 2000 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999 [RFC2028] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, " Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, MIT/LC, U.C. Irvine, Xerox Corporation, August 1998 [RFC959] Postel, J., and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, ISI, October 1985 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, UC Irvine, DEC, MIT/LCS, January 1997 [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, IBM, Maxware, October 1998 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, Harvard University, March 1997 Levi & Schoenwaelder Standards Track [Page 54] Internet-Draft Script MIB July 2000 16. Editors' Addresses David B. Levi Nortel Networks 4401 Great America Parkway Santa Clara, CA 95052-8185 U.S.A. Phone: +1 423 686 0432 EMail: dlevi@nortelnetworks.com Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3683 EMail: schoenw@ibr.cs.tu-bs.de 17. 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. Levi & Schoenwaelder Standards Track [Page 55] Internet-Draft Script MIB July 2000 From owner-disman@dorothy.peer.com Fri Jul 7 14:51:30 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 OAA09722 for ; Fri, 7 Jul 2000 14:51:13 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e67Ik4Z19529; Fri, 7 Jul 2000 13:46:05 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA23436 for disman-list; Fri, 7 Jul 2000 11:43:56 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA23404; Fri, 7 Jul 2000 11:43:25 -0700 (PDT) Date: Fri, 7 Jul 2000 11:43:25 -0700 (PDT) From: Randy Presuhn Message-Id: <200007071843.LAA23404@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Fwd: Re: draft-ietf-disman-event-mib-10.txt Cc: nsyracus@ietf.org 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 - I'm forwarding a posting from nsyracus@odin.ietf.org to the disman working group mailing list. I have added nsyracus@odin.ietf.org to the disman "posters" list so that any of her future postings will not need approval by the list owner. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- > Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA21948 > for ; Fri, 7 Jul 2000 05:05:50 -0700 (PDT) > Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) > by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e67C6SZ03518 > for ; Fri, 7 Jul 2000 07:06:28 -0500 (CDT) > Received: from NSYRACUS ([10.27.5.110]) > by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22516; > Fri, 7 Jul 2000 08:06:22 -0400 (EDT) > Date: Fri, 7 Jul 2000 08:09:13 -0400 (Eastern Daylight Time) > From: Natalia Syracuse > To: "Ramanathan R. Kavasseri" > cc: internet-drafts@ietf.org, disman@dorothy.bmc.com > Subject: Re: draft-ietf-disman-event-mib-10.txt > In-Reply-To: <4.1.20000704081307.00a60ec0@sigma.cisco.com> > Message-ID: > X-X-Sender: nsyracus@odin.ietf.org > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > > They are here - > http://www.ietf.org/internet-drafts/draft-ietf-disman-event-mib-10.txt, > http://www.ietf.org/internet-drafts/draft-ietf-disman-express-mib-12.txt. > > Natalia Syracuse > > On Tue, 4 Jul 2000, Ramanathan R. Kavasseri wrote: > > > Hi, > > > > I'd submittied draft-ietf-disman-event-mib-10.txt for posting as an I-D > > last Thursday. > > I can't find it posted yet. Is this due to some technical problems with the > > draft, or are > > they in the process of being posted? Please let us know when this draft > > will be posted, > > and whether anything further is to be done. > > > > Note: I posted draft-ietf-disman-expr-mib-12.txt last Thursday as well, and it > > hasn't been posted yet. Could you let me know the status of this MIB as well? > > > > Thanks, > > > > Ram > > > > At 09:24 AM 6/29/00 -0700, Ram Kavasseri wrote: > > > > > >Please accept drafte-ietf-disman-event-mib-10.txt for posting > > >sa an interent draft. This draft contains changes to fix typos, > > >formatting issues etc. > > > > > >Thank you, > > > > > >Ram Kavasseri > > > > > > > > > > > > > > > > > > > > > > > > > > >Network Working Group Editor of this version: > > >Internet-Draft Ramanathan R. Kavasseri > > >Expires December 2000 Cisco Systems, Inc. > > > Author of previous version: > > > Bob Stewart > > > 7 June 2000 > > > > > > > > > > > > Event MIB > > > > > > draft-ietf-disman-event-mib-10.txt > > > > > > > > > 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. > > > > > >Distribution of this document is unlimited. Please send comments to the > > >Distributed Management Working Group, . > > > > > > > > >Copyright Notice > > > > > >Copyright (C) The Internet Society (2000). All Rights Reserved. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > >1. Abstract > > > > > >This memo defines an experimental 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. > > > > > > > > >The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > >"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > >document are to be interpreted as described in RFC 2119. > > > > > > > > >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], RFC 2579 [RFC2579] and 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 > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 2] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > 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. It may not be possible to meaningfully monitor Counter64 objects > > > using an SMIv1 version of the MIB. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 3] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > >3. Overview > > > > > >With network sizes well beyond the ability of people to manage them > > >directly, automated, distributed management is vital. An important > > >aspect of such management is the ability of a system to monitor itself > > >or for some other system to monitor it. > > > > > >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. > > > > > >The MIB is intended to suit either a relatively powerful manager or mid- > > >level manager, as well as a somewhat more limited self-managing system. > > > > > > > > >4. Relationship to Other MIBs > > > > > >The Event MIB is based on extensive experience with the RMON MIB > > >[RFC1757] and provides a superset of the capabilities of the RMON alarm > > >and event groups. Conceptually, the key extension is the ability to > > >allow alarms to be generated for MIB objects that are on another network > > >element. The Event MIB calls "triggers" what the RMON MIB called > > >"alarms," but the concepts are the same. Event MIB triggers maintain > > >the RMON handling of thresholds and add the concept of booleans. Event > > >MIB events maintain the RMON concept of sending an SNMP notification in > > >response to a trigger and add the concept of setting a MIB object. > > > > > >The Event MIB is the successor and update to SNMPv2's Manager-to-Manager > > >MIB [RFC1451] which was declared Historic pending this work. > > > > > >The Event MIB depends on the services of the SNMPv3 Management Target > > >and Notification MIBs [RFC2573]. > > > > > >The Event MIB is nicely complemented by the Distributed Management > > >Expression MIB [RFCExpressionMIB], which is the expected source of > > >boolean objects to monitor. Note that there is considerable overlap > > >between the wildcard and delta sample capabilities of the Event and > > >Expression MIBs. A carefully-planned implementation might well use > > >common code to provide the overlapping functions. > > > > > > > > >5. MIB Sections > > > > > >The MIB has four sections: triggers, objects, events, and notifications. > > >Triggers define the conditions that lead to events. Events may cause > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 4] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > >notifications. > > > > > >The trigger table lists what objects are to be monitored and how and > > >relates each trigger to an event. It has supplementary, companion > > >tables for additional objects that depend on the type of test done for > > >the trigger. > > > > > >The objects table lists objects that can be added to notifications based > > >on the trigger, the trigger test type, or the event that resulted in the > > >notification. > > > > > >The event table defines what happens when an event is triggered: sending > > >a notification, setting a MIB object or both. It has supplementary, > > >companion tables for additional objects that depend on the action taken. > > > > > >The notification section defines a set of generic notifications to go > > >with the events and for Event MIB error handling, and it defines a set > > >of objects to put in those notifications. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 5] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > >The following diagram describes the relationships between the tables > > >in the Event MIB. > > > > > > > > >+-----------------------------+ > > >| mteTriggerEntry | subclassed by: > > >| { mteOwner, |---+ > > >| IMPLIED mteTriggerName } | +-- mteTriggerDeltaEntry > > >| | | > > >| | +-- mteTriggerExistenceEntry > > >| | | > > >| | +-- mteTriggerBooleanEntry > > >| | | > > >| | +-- mteTriggerThresholdEntry > > >| | > > >| mteTrigger*Event -------------------------------->+ > > >| | | > > >| mteTriggerObjects ------------------>+ | > > >+-----------------------------+ | | > > > | | > > >+-----------------------------+ V | > > >| mteObjectsEntry | | | > > >| { mteOwner, |<-------------+ | > > >| mteObjectsName, | | > > >| mteObjectsIndex } | | > > >+-----------------------------+ | > > > V > > >+---------------------------+ | > > >| mteEventEntry |<----------------------------+ > > >| { mteOwner, | > > >| IMPLIED mteEventName } | > > >| | > > >| mteEventAction---> + (condition) > > >+---------------------------+ | > > > V > > >+---------------------------+ | +---------------------------+ > > >| mteEventNotificationEntry | | | mteEventSetEntry | > > >| { mteOwner, |<--+-->| { mteOwner, | > > >| IMPLIED mteEventName } | | IMPLIED mteEventName } | > > >+---------------------------+ +---------------------------+ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 6] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > >6. Operation > > > > > >The Event MIB is instrumentation for a distributed management > > >application that monitors MIB objects. In its simplest form this > > >application monitors individual, local MIB objects, just as an RMON > > >probe fulfills the functions implied by RMON's alarm and event > > >operation. Additionally the application can monitor remote objects and > > >wildcarded groups of objects. > > > > > >Remote monitoring uses the tag service of the Management Target MIB > > >[RFC2573] to select and access remote systems as an ordinary SNMP-based > > >management application. Local monitoring may be via a more intimate, > > >local interface which may, for example, bypass SNMP encoding but > > >otherwise is functionally identical to remote SNMP operation, including > > >the application of access control. A self-management only system MAY > > >not implement remote monitoring. > > > > > >Wildcards indicate that the application SHOULD use a GetNext-type > > >operation to find the zero or more instances implied by a truncated > > >object identifier, just like an ordinary SNMP-based management > > >application. Each instance of a wildcard is treated as if it were a > > >separate entry, that is the instances of a wildcarded object are > > >independent of one another. For example, a wild-carded object may > > >trigger an event, and result in the setting of another wildcarded > > >object. The instance that satisfied the trigger function is used to > > >perform the set function. All of this takes place independently of any > > >additional instances that may fill the wildcard. > > > > > >Error handling is by notification. These error notifications SHOULD be > > >enabled only for the diagnosis of problems indicated by error counters. > > >If minimizing the probability of notification loss is a concern they > > >SHOULD be transmitted as Inform PDUs as described in the [SNMP-TARGET- > > >MIB] or directed to a log as described in the Notification Log MIB > > >[rfcNotificationLogMIB]. Note that this does not mean the Notification > > >Log MIB is REQUIRED, since in fact notifications usually are not lost, > > >but that the Notification Log MIB can be helpful with this as well as > > >other MIBs that include notifications. > > > > > >Although like most MIBs this one has no explicit controls for the > > >persistence of the values set in configuring events, a robust, polite > > >implementation would certainly not force its managing applications to > > >reconfigure it whenever it resets. > > > > > >Again, as with most MIBs, it is implementation-specific how a system > > >provides and manages such persistence. To speculate, one could imagine, > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 7] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > >for example, that persistence depended on the context in which the > > >expression was configured, or perhaps system-specific characteristics of > > >the expression's owner. Or perhaps everything in a MIB such as this > > >one, which is clearly aimed at persistent configuration, is > > >automatically part of a system's other persistent configuration. > > > > > > > > >7. Security > > > > > >Security of Event MIB entries depends on SNMPv3 access control for the > > >entire MIB or for subsets based on entry owner names. > > > > > >Security of monitored objects for remote access depends on the > > >Management Target MIB [RFC2573]. Security for local access can depend > > >on the Management Target MIB or on recording appropriate security > > >credentials of the creator of an entry and using those to access the > > >local objects. These security credentials are the parameters necessary > > >as inputs to isAccessAllowed from the Architecture for Describing SNMP > > >Management Frameworks. When accessing local objects without using a > > >local target tag, the system MUST (conceptually) use isAccessAllowed to > > >ensure that it does not violate security. > > > > > >To facilitate the provisioning of access control by a security > > >administrator for this MIB itself using the View-Based Access Control > > >Model (VACM) defined in RFC 2275 [RFC2575] for tables in which multiple > > >users may need to independently create or modify entries, the initial > > >index is used as an "owner index". Such an initial index has a syntax of > > >SnmpAdminString, and can thus be trivially mapped to a securityName or > > >groupName as defined in VACM, in accordance with a security policy. > > > > > >If a security administrator were to employ such an approach, all entries > > >in related tables belonging to a particular user will have the same > > >value for this initial index. For a given user's entries in a > > >particular table, the object identifiers for the information in these > > >entries will have the same sub-identifiers (except for the "column" sub- > > >identifier) up to the end of the encoded owner index. To configure VACM > > >to permit access to this portion of the table, one would create > > >vacmViewTreeFamilyTable entries with the value of > > >vacmViewTreeFamilySubtree including the owner index portion, and > > >vacmViewTreeFamilyMask "wildcarding" the column sub-identifier. More > > >elaborate configurations are possible. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 8] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > >8. Definitions > > > > > >DISMAN-EVENT-MIB DEFINITIONS ::= BEGIN > > > > > >IMPORTS > > > MODULE-IDENTITY, OBJECT-TYPE, > > > Integer32, Unsigned32, > > > NOTIFICATION-TYPE, Counter32, > > > Gauge32, mib-2, zeroDotZero FROM SNMPv2-SMI > > > TEXTUAL-CONVENTION, RowStatus, > > > TruthValue FROM SNMPv2-TC > > > MODULE-COMPLIANCE, OBJECT-GROUP, > > > NOTIFICATION-GROUP FROM SNMPv2-CONF > > > sysUpTime FROM SNMPv2-MIB > > > SnmpTagValue FROM SNMP-TARGET-MIB > > > SnmpAdminString FROM SNMP-FRAMEWORK-MIB; > > > > > >dismanEventMIB MODULE-IDENTITY > > > LAST-UPDATED "200006070000Z" -- 7 June 2000 > > > ORGANIZATION "IETF Distributed Management Working Group" > > > CONTACT-INFO "Ramanathan Kavasseri > > > Cisco Systems, Inc. > > > 170 West Tasman Drive, > > > San Jose CA 95134-1706. > > > Phone: +1 408 526 4527 > > > Email: ramk@cisco.com" > > > DESCRIPTION > > > "The MIB module for defining event triggers and actions > > > for network management purposes." > > >-- Revision History > > > > > > REVISION "200006070000Z" -- 7 June 2000 > > > DESCRIPTION "This is the initial version of this MIB. > > > Published as RFC xxxx" > > > ::= { mib-2 xx } -- final assignment by IANA at publication time > > > > > >dismanEventMIBObjects OBJECT IDENTIFIER ::= { dismanEventMIB 1 } > > > > > >-- Management Triggered Event (MTE) objects > > > > > >mteResource OBJECT IDENTIFIER ::= { dismanEventMIBObjects 1 } > > >mteTrigger OBJECT IDENTIFIER ::= { dismanEventMIBObjects 2 } > > >mteObjects OBJECT IDENTIFIER ::= { dismanEventMIBObjects 3 } > > >mteEvent OBJECT IDENTIFIER ::= { dismanEventMIBObjects 4 } > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 9] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > >-- > > >-- Textual Conventions > > >-- > > > > > >FailureReason ::= TEXTUAL-CONVENTION > > > STATUS current > > > DESCRIPTION > > > "Reasons for failures in an attempt to perform a management > > > request. > > > > > > The first group of errors, numbered less than 0, are related > > > to problems in sending the request. The existence of a > > > particular error code here does not imply that all > > > implementations are capable of sensing that error and > > > returning that code. > > > > > > The second group, numbered greater than 0, are copied > > > directly from SNMP protocol operations and are intended to > > > carry exactly the meanings defined for the protocol as returned > > > in an SNMP response. > > > > > > localResourceLack some local resource such as memory lacking > > > or mteResourceSampleInstanceMaximum > > > exceeded > > > badDestination unrecognized domain name or otherwise > > > invalid destination address > > > destinationUnreachable can't get to destination address > > > noResponse no response to SNMP request > > > badType the data syntax of a retrieved object > > > as not as expected > > > sampleOverrun another sample attempt occurred before > > > the previous one completed" > > > > > > SYNTAX INTEGER { localResourceLack(-1), > > > badDestination(-2), > > > destinationUnreachable(-3), > > > noResponse(-4), > > > badType(-5), > > > sampleOverrun(-6), > > > > > > noError(0), > > > > > > tooBig(1), > > > noSuchName(2), > > > badValue(3), > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 10] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > readOnly(4), > > > genErr(5), > > > noAccess(6), > > > wrongType(7), > > > wrongLength(8), > > > wrongEncoding(9), > > > wrongValue(10), > > > noCreation(11), > > > inconsistentValue(12), > > > resourceUnavailable(13), > > > commitFailed(14), > > > undoFailed(15), > > > authorizationError(16), > > > notWritable(17), > > > inconsistentName(18) } > > >-- > > >-- Resource Control Section > > >-- > > > > > >mteResourceSampleMinimum OBJECT-TYPE > > > SYNTAX Integer32 (1..2147483647) > > > UNITS "seconds" > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The minimum mteTriggerFrequency this system will > > > accept. A system may use the larger values of this minimum to > > > lessen the impact of constant sampling. For larger > > > sampling intervals the system samples less often and > > > suffers less overhead. This object provides a way to enforce > > > such lower overhead for all triggers created after it is > > > set. > > > > > > Unless explicitly resource limited, a system's value for > > > this object SHOULD be 1, allowing as small as a 1 second > > > interval for ongoing trigger sampling. > > > > > > Changing this value will not invalidate an existing setting > > > of mteTriggerFrequency." > > > ::= { mteResource 1 } > > > > > >mteResourceSampleInstanceMaximum OBJECT-TYPE > > > SYNTAX Unsigned32 > > > UNITS "instances" > > > MAX-ACCESS read-write > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 11] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > STATUS current > > > DESCRIPTION > > > "The maximum number of instance entries this system will > > > support for sampling. > > > > > > These are the entries that maintain state, one for each > > > instance of each sampled object as selected by > > > mteTriggerValueID. Note that wildcarded objects result > > > in multiple instances of this state. > > > > > > A value of 0 indicates no preset limit, that is, the limit > > > is dynamic based on system operation and resources. > > > > > > Unless explicitly resource limited, a system's value for > > > this object SHOULD be 0. > > > > > > Changing this value will not eliminate or inhibit existing > > > sample state but could prevent allocation of additional state > > > information." > > > ::= { mteResource 2 } > > > > > >mteResourceSampleInstances OBJECT-TYPE > > > SYNTAX Gauge32 > > > UNITS "instances" > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION > > > "The number of currently active instance entries as > > > defined for mteResourceSampleInstanceMaximum." > > > ::= { mteResource 3 } > > > > > >mteResourceSampleInstancesHigh OBJECT-TYPE > > > SYNTAX Gauge32 > > > UNITS "instances" > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION > > > "The highest value of mteResourceSampleInstances that has > > > occurred since initialization of the management system." > > > ::= { mteResource 4 } > > > > > >mteResourceSampleInstanceLacks OBJECT-TYPE > > > SYNTAX Counter32 > > > UNITS "instances" > > > MAX-ACCESS read-only > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 12] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > STATUS current > > > DESCRIPTION > > > "The number of times this system could not take a new sample > > > because that allocation would have exceeded the limit set by > > > mteResourceSampleInstanceMaximum." > > > ::= { mteResource 5 } > > > > > > > > >-- > > >-- Trigger Section > > >-- > > > > > >-- Counters > > > > > >mteTriggerFailures OBJECT-TYPE > > > SYNTAX Counter32 > > > UNITS "failures" > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION > > > "The number of times an attempt to check for a trigger > > > condition has failed. This counts individually for each > > > attempt in a group of targets or each attempt for a > > > wildcarded object." > > > ::= { mteTrigger 1 } > > > > > > > > >-- > > >-- Trigger Table > > >-- > > > > > >mteTriggerTable OBJECT-TYPE > > > SYNTAX SEQUENCE OF MteTriggerEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "A table of management event trigger information." > > > ::= { mteTrigger 2 } > > > > > >mteTriggerEntry OBJECT-TYPE > > > SYNTAX MteTriggerEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "Information about a single trigger. Applications create and > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 13] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > delete entries using mteTriggerEntryStatus." > > > INDEX { mteOwner, IMPLIED mteTriggerName } > > > ::= { mteTriggerTable 1 } > > > > > >MteTriggerEntry ::= SEQUENCE { > > > mteOwner SnmpAdminString, > > > mteTriggerName SnmpAdminString, > > > mteTriggerComment SnmpAdminString, > > > mteTriggerTest BITS, > > > mteTriggerSampleType INTEGER, > > > mteTriggerValueID OBJECT IDENTIFIER, > > > mteTriggerValueIDWildcard TruthValue, > > > mteTriggerTargetTag SnmpTagValue, > > > mteTriggerContextName SnmpAdminString, > > > mteTriggerContextNameWildcard TruthValue, > > > mteTriggerFrequency Unsigned32, > > > mteTriggerObjectsOwner SnmpAdminString, > > > mteTriggerObjects SnmpAdminString, > > > mteTriggerEnabled TruthValue, > > > mteTriggerEntryStatus RowStatus > > >} > > > > > >mteOwner OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE(0..32)) > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "The owner of this entry. The exact semantics of this > > > string are subject to the security policy defined by the > > > security administrator." > > > ::= { mteTriggerEntry 1 } > > > > > >mteTriggerName OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (1..32)) > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "A locally-unique, administratively assigned name for the > > > trigger within the scope of mteOwner." > > > ::= { mteTriggerEntry 2 } > > > > > >mteTriggerComment OBJECT-TYPE > > > SYNTAX SnmpAdminString > > > MAX-ACCESS read-create > > > STATUS current > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 14] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > DESCRIPTION > > > "A description of the trigger's function and use." > > > DEFVAL { ''H } > > > ::= { mteTriggerEntry 3 } > > > > > >mteTriggerTest OBJECT-TYPE > > > SYNTAX BITS { existence(0), boolean(1), threshold(2) } > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "The type of trigger test to perform. For 'boolean' and > > > 'threshold' tests, the object at mteTriggerValueID MUST > > > evaluate to an integer, that is, anything that ends up encoded > > > for transmission (that is, in BER, not ASN.1) as an integer. > > > > > > For 'existence', the specific test is as selected by > > > mteTriggerExistenceTest. When an object appears, vanishes > > > or changes value, the trigger fires. If the object's > > > appearance caused the trigger firing, the object MUST > > > vanish before the trigger can be fired again for it, and > > > vice versa. If the trigger fired due to a change in the > > > object's value, it will be fired again on every successive > > > value change for that object. > > > > > > For 'boolean', the specific test is as selected by > > > mteTriggerBooleanTest. If the test result is true the trigger > > > fires. The trigger will not fire again until the value has > > > become false and come back to true. > > > > > > For 'threshold' the test works as described below for > > > mteTriggerThresholdStartup, mteTriggerThresholdRising, and > > > mteTriggerThresholdFalling. > > > > > > Note that combining 'boolean' and 'threshold' tests on the > > > same object may be somewhat redundant." > > > DEFVAL { { boolean } } > > > ::= { mteTriggerEntry 4 } > > > > > >mteTriggerSampleType OBJECT-TYPE > > > SYNTAX INTEGER { absoluteValue(1), deltaValue(2) } > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "The type of sampling to perform. > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 15] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > An 'absoluteValue' sample requires only a single sample to be > > > meaningful, and is exactly the value of the object at > > > mteTriggerValueID at the sample time. > > > > > > A 'deltaValue' requires two samples to be meaningful and is > > > thus not available for testing until the second and subsequent > > > samples after the object at mteTriggerValueID is first found > > > to exist. It is the difference between the two samples. For > > > unsigned values it is always positive, based on unsigned > > > arithmetic. For signed values it can be positive or negative. > > > > > > For SNMP counters to be meaningful they should be sampled as a > > > 'deltaValue'. > > > > > > For 'deltaValue' mteTriggerDeltaTable contains further > > > parameters. > > > > > > If only 'existence' is set in mteTriggerTest this object has > > > no meaning." > > > DEFVAL { absoluteValue } > > > ::= { mteTriggerEntry 5 } > > > > > >mteTriggerValueID OBJECT-TYPE > > > SYNTAX OBJECT IDENTIFIER > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "The object identifier of the MIB object to sample to see > > > if the trigger should fire. > > > > > > This may be wildcarded by truncating all or part of the > > > instance portion, in which case the value is obtained > > > as if with a GetNext function, checking multiple values > > > if they exist. If such wildcarding is applied, > > > mteTriggerValueIDWildcard must be 'true' and if not it must > > > be 'false'. > > > > > > Bad object identifiers or a mismatch between truncating the > > > identifier and the value of mteTriggerValueIDWildcard result > > > in operation as one would expect when providing the wrong > > > identifier to a Get or GetNext operation. The Get will fail > > > or get the wrong object. The GetNext will indeed get whatever > > > is next, proceeding until it runs past the initial part of the > > > identifier and perhaps many unintended objects for confusing > > > results. If the value syntax of those objects is not usable, > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 16] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > that results in a 'badType' error that terminates the scan. > > > > > > Each instance that fills the wildcard is independent of any > > > additional instances, that is, wildcarded objects operate > > > as if there were a separate table entry for each instance > > > that fills the wildcard without having to actually predict > > > all possible instances ahead of time." > > > DEFVAL { zeroDotZero } > > > ::= { mteTriggerEntry 6 } > > > > > >mteTriggerValueIDWildcard OBJECT-TYPE > > > SYNTAX TruthValue > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "Control for whether mteTriggerValueID is to be treated as > > > fully-specified or wildcarded, with 'true' indicating wildcard." > > > DEFVAL { false } > > > ::= { mteTriggerEntry 7 } > > > > > >mteTriggerTargetTag OBJECT-TYPE > > > SYNTAX SnmpTagValue > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "The tag for the target(s) from which to obtain the condition > > > for a trigger check. > > > > > > A length of 0 indicates the local system. In this case, > > > access to the objects indicated by mteTriggerValueID is under > > > the security credentials of the requester that set > > > mteTriggerEntryStatus to 'active'. Those credentials are the > > > input parameters for isAccessAllowed from the Architecture for > > > Describing SNMP Management Frameworks. > > > > > > Otherwise access rights are checked according to the security > > > parameters resulting from the tag." > > > DEFVAL { ''H } > > > ::= { mteTriggerEntry 8 } > > > > > >mteTriggerContextName OBJECT-TYPE > > > SYNTAX SnmpAdminString > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 17] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > "The management context from which to obtain mteTriggerValueID. > > > > > > This may be wildcarded by leaving characters off the end. For > > > example use 'Repeater' to wildcard to 'Repeater1', > > > 'Repeater2', 'Repeater-999.87b', and so on. To indicate such > > > wildcarding is intended, mteTriggerContextNameWildcard must > > > be 'true'. > > > > > > Each instance that fills the wildcard is independent of any > > > additional instances, that is, wildcarded objects operate > > > as if there were a separate table entry for each instance > > > that fills the wildcard without having to actually predict > > > all possible instances ahead of time. > > > > > > Operation of this feature assumes that the local system has a > > > list of available contexts against which to apply the > > > wildcard. If the objects are being read from the local > > > system, this is clearly the system's own list of contexts. > > > For a remote system a local version of such a list is not > > > defined by any current standard and may not be available, so > > > this function MAY not be supported." > > > DEFVAL { ''H } > > > ::= { mteTriggerEntry 9 } > > > > > >mteTriggerContextNameWildcard OBJECT-TYPE > > > SYNTAX TruthValue > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "Control for whether mteTriggerContextName is to be treated as > > > fully-specified or wildcarded, with 'true' indicating wildcard." > > > DEFVAL { false } > > > ::= { mteTriggerEntry 10 } > > > > > >mteTriggerFrequency OBJECT-TYPE > > > SYNTAX Unsigned32 > > > UNITS "seconds" > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "The number of seconds to wait between trigger samples. To > > > encourage consistency in sampling, the interval is measured > > > from the beginning of one check to the beginning of the next > > > and the timer is restarted immediately when it expires, not > > > when the check completes. > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 18] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > If the next sample begins before the previous one completed the > > > system may either attempt to make the check or treat this as an > > > error condition with the error 'sampleOverrun'. > > > > > > A frequency of 0 indicates instantaneous recognition of the > > > condition. This is not possible in many cases, but may > > > be supported in cases where it makes sense and the system is > > > able to do so. This feature allows the MIB to be used in > > > implementations where such interrupt-driven behavior is > > > possible and is not likely to be supported for all MIB objects > > > even then since such sampling generally has to be tightly > > > integrated into low-level code. > > > > > > Systems that can support this SHOULD document those cases > > > where it can be used. In cases where it can not, setting this > > > object to 0 should be disallowed." > > > DEFVAL { 600 } > > > ::= { mteTriggerEntry 11 } > > > > > >mteTriggerObjectsOwner OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "To go with mteTriggerObjects, the mteOwner of a group of > > > objects from mteObjectsTable." > > > DEFVAL { ''H } > > > ::= { mteTriggerEntry 12 } > > > > > >mteTriggerObjects OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "The mteObjectsName of a group of objects from > > > mteObjectsTable. These objects are to be added to any > > > Notification resulting from the firing of this trigger. > > > > > > A list of objects may also be added based on the event or on > > > the value of mteTriggerTest. > > > > > > A length of 0 indicates no additional objects." > > > DEFVAL { ''H } > > > ::= { mteTriggerEntry 13 } > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 19] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > >mteTriggerEnabled OBJECT-TYPE > > > SYNTAX TruthValue > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "A control to allow a trigger to be configured but not used. > > > When the value is 'false' the trigger is not sampled." > > > DEFVAL { false } > > > ::= { mteTriggerEntry 14 } > > > > > >mteTriggerEntryStatus OBJECT-TYPE > > > SYNTAX RowStatus > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "The control that allows creation and deletion of entries. > > > Once made active an entry may not be modified except to > > > delete it." > > > ::= { mteTriggerEntry 15 } > > > > > > > > >-- > > >-- Trigger Delta Table > > >-- > > > > > >mteTriggerDeltaTable OBJECT-TYPE > > > SYNTAX SEQUENCE OF MteTriggerDeltaEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "A table of management event trigger information for delta > > > sampling." > > > ::= { mteTrigger 3 } > > > > > >mteTriggerDeltaEntry OBJECT-TYPE > > > SYNTAX MteTriggerDeltaEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "Information about a single trigger's delta sampling. Entries > > > automatically exist in this this table for each mteTriggerEntry > > > that has mteTriggerSampleType set to 'deltaValue'." > > > INDEX { mteOwner, IMPLIED mteTriggerName } > > > ::= { mteTriggerDeltaTable 1 } > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 20] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > >MteTriggerDeltaEntry ::= SEQUENCE { > > > mteTriggerDeltaDiscontinuityID OBJECT IDENTIFIER, > > > mteTriggerDeltaDiscontinuityIDWildcard TruthValue, > > > mteTriggerDeltaDiscontinuityIDType INTEGER > > >} > > > > > > > > >sysUpTimeInstance OBJECT IDENTIFIER ::= { sysUpTime 0 } > > > > > >mteTriggerDeltaDiscontinuityID OBJECT-TYPE > > > SYNTAX OBJECT IDENTIFIER > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The OBJECT IDENTIFIER (OID) of a TimeTicks, TimeStamp, or > > > DateAndTime object that indicates a discontinuity in the value > > > at mteTriggerValueID. > > > > > > The OID may be for a leaf object (e.g. sysUpTime.0) or may > > > be wildcarded to match mteTriggerValueID. > > > > > > This object supports normal checking for a discontinuity in a > > > counter. Note that if this object does not point to sysUpTime > > > discontinuity checking MUST still check sysUpTime for an overall > > > discontinuity. > > > > > > If the object identified is not accessible the sample attempt > > > is in error, with the error code as from an SNMP request. > > > > > > Bad object identifiers or a mismatch between truncating the > > > identifier and the value of mteDeltaDiscontinuityIDWildcard > > > result in operation as one would expect when providing the > > > wrong identifier to a Get operation. The Get will fail or get > > > the wrong object. If the value syntax of those objects is not > > > usable, that results in an error that terminates the sample > > > with a 'badType' error code." > > > DEFVAL { sysUpTimeInstance } > > > ::= { mteTriggerDeltaEntry 1 } > > > > > >mteTriggerDeltaDiscontinuityIDWildcard OBJECT-TYPE > > > SYNTAX TruthValue > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "Control for whether mteTriggerDeltaDiscontinuityID is to be > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 21] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > treated as fully-specified or wildcarded, with 'true' > > > indicating wildcard. Note that the value of this object will > > > be the same as that of the corresponding instance of > > > mteTriggerValueIDWildcard when the corresponding > > > mteTriggerSampleType is 'deltaValue'." > > > DEFVAL { false } > > > ::= { mteTriggerDeltaEntry 2 } > > > > > >mteTriggerDeltaDiscontinuityIDType OBJECT-TYPE > > > SYNTAX INTEGER { timeTicks(1), timeStamp(2), dateAndTime(3) } > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The value 'timeTicks' indicates the > > > mteTriggerDeltaDiscontinuityID of this row is of syntax > > > TimeTicks. The value 'timeStamp' indicates syntax TimeStamp. > > > The value 'dateAndTime' indicates syntax DateAndTime." > > > DEFVAL { timeTicks } > > > ::= { mteTriggerDeltaEntry 3 } > > > > > > > > >-- > > >-- Trigger Existence Table > > >-- > > > > > >mteTriggerExistenceTable OBJECT-TYPE > > > SYNTAX SEQUENCE OF MteTriggerExistenceEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "A table of management event trigger information for existence > > > triggers." > > > ::= { mteTrigger 4 } > > > > > >mteTriggerExistenceEntry OBJECT-TYPE > > > SYNTAX MteTriggerExistenceEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "Information about a single existence trigger. Entries > > > automatically exist in this this table for each mteTriggerEntry > > > that has 'existence' set in mteTriggerTest." > > > INDEX { mteOwner, IMPLIED mteTriggerName } > > > ::= { mteTriggerExistenceTable 1 } > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 22] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > >MteTriggerExistenceEntry ::= SEQUENCE { > > > mteTriggerExistenceTest BITS, > > > mteTriggerExistenceStartup BITS, > > > mteTriggerExistenceObjectsOwner SnmpAdminString, > > > mteTriggerExistenceObjects SnmpAdminString, > > > mteTriggerExistenceEventOwner SnmpAdminString, > > > mteTriggerExistenceEvent SnmpAdminString > > >} > > > > > >mteTriggerExistenceTest OBJECT-TYPE > > > SYNTAX BITS { present(0), absent(1), changed(2) } > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The type of existence test to perform. The trigger fires > > > when the object at mteTriggerValueID is seen to go from > > > present to absent, from absent to present, or to have it's > > > value changed, depending on which tests are selected: > > > > > > present(0) - when this test is selected, the trigger fires > > > when the mteTriggerValueID object goes from absent to present. > > > > > > absent(1) - when this test is selected, the trigger fires > > > when the mteTriggerValueID object goes from present to absent. > > > changed(2) - when this test is selected, the trigger fires > > > the mteTriggerValueID object value changes. > > > > > > Once the trigger has fired for either presence or absence it > > > will not fire again for that state until the object has been > > > to the other state. " > > > DEFVAL { { present, absent } } > > > ::= { mteTriggerExistenceEntry 1 } > > > > > >mteTriggerExistenceStartup OBJECT-TYPE > > > SYNTAX BITS { present(0), absent(1) } > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "Control for whether an event may be triggered when this entry > > > is first set to 'active' and the test specified by > > > mteTriggerExistenceTest is true. Setting an option causes > > > that trigger to fire when its test is true." > > > DEFVAL { { present, absent } } > > > ::= { mteTriggerExistenceEntry 2 } > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 23] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > >mteTriggerExistenceObjectsOwner OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "To go with mteTriggerExistenceObjects, the mteOwner of a > > > group of objects from mteObjectsTable." > > > DEFVAL { ''H } > > > ::= { mteTriggerExistenceEntry 3 } > > > > > >mteTriggerExistenceObjects OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The mteObjectsName of a group of objects from > > > mteObjectsTable. These objects are to be added to any > > > Notification resulting from the firing of this trigger for > > > this test. > > > > > > A list of objects may also be added based on the overall > > > trigger, the event or other settings in mteTriggerTest. > > > > > > A length of 0 indicates no additional objects." > > > DEFVAL { ''H } > > > ::= { mteTriggerExistenceEntry 4 } > > > > > >mteTriggerExistenceEventOwner OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "To go with mteTriggerExistenceEvent, the mteOwner of an event > > > entry from the mteEventTable." > > > DEFVAL { ''H } > > > ::= { mteTriggerExistenceEntry 5 } > > > > > >mteTriggerExistenceEvent OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The mteEventName of the event to invoke when mteTriggerType is > > > 'existence' and this trigger fires. A length of 0 indicates no > > > event." > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 24] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > DEFVAL { ''H } > > > ::= { mteTriggerExistenceEntry 6 } > > > > > > > > >-- > > >-- Trigger Boolean Table > > >-- > > > > > >mteTriggerBooleanTable OBJECT-TYPE > > > SYNTAX SEQUENCE OF MteTriggerBooleanEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "A table of management event trigger information for boolean > > > triggers." > > > ::= { mteTrigger 5 } > > > > > >mteTriggerBooleanEntry OBJECT-TYPE > > > SYNTAX MteTriggerBooleanEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "Information about a single boolean trigger. Entries > > > automatically exist in this this table for each mteTriggerEntry > > > that has 'boolean' set in mteTriggerTest." > > > INDEX { mteOwner, IMPLIED mteTriggerName } > > > ::= { mteTriggerBooleanTable 1 } > > > > > >MteTriggerBooleanEntry ::= SEQUENCE { > > > mteTriggerBooleanComparison INTEGER, > > > mteTriggerBooleanValue Integer32, > > > mteTriggerBooleanStartup TruthValue, > > > mteTriggerBooleanObjectsOwner SnmpAdminString, > > > mteTriggerBooleanObjects SnmpAdminString, > > > mteTriggerBooleanEventOwner SnmpAdminString, > > > mteTriggerBooleanEvent SnmpAdminString > > >} > > > > > >mteTriggerBooleanComparison OBJECT-TYPE > > > SYNTAX INTEGER { unequal(1), equal(2), > > > less(3), lessOrEqual(4), > > > greater(5), greaterOrEqual(6) } > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 25] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > "The type of boolean comparison to perform. > > > > > > The value at mteTriggerValueID is compared to > > > mteTriggerBooleanValue, so for example if > > > mteTriggerBooleanComparison is 'less' the result would be true > > > if the value at mteTriggerValueID is less than the value of > > > mteTriggerBooleanValue." > > > DEFVAL { unequal } > > > ::= { mteTriggerBooleanEntry 1 } > > > > > >mteTriggerBooleanValue OBJECT-TYPE > > > SYNTAX Integer32 > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The value to use for the test specified by > > > mteTriggerBooleanTest." > > > DEFVAL { 0 } > > > ::= { mteTriggerBooleanEntry 2 } > > > > > >mteTriggerBooleanStartup OBJECT-TYPE > > > SYNTAX TruthValue > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "Control for whether an event may be triggered when this entry > > > is first set to 'active' or a new instance of the object at > > > mteTriggerValueID is found and the test specified by > > > mteTriggerBooleanComparison is true. In that case an event is > > > triggered if mteTriggerBooleanStartup is 'true'." > > > DEFVAL { true } > > > ::= { mteTriggerBooleanEntry 3 } > > > > > >mteTriggerBooleanObjectsOwner OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "To go with mteTriggerBooleanObjects, the mteOwner of a group > > > of objects from mteObjectsTable." > > > DEFVAL { ''H } > > > ::= { mteTriggerBooleanEntry 4 } > > > > > >mteTriggerBooleanObjects OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 26] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The mteObjectsName of a group of objects from > > > mteObjectsTable. These objects are to be added to any > > > Notification resulting from the firing of this trigger for > > > this test. > > > > > > A list of objects may also be added based on the overall > > > trigger, the event or other settings in mteTriggerTest. > > > > > > A length of 0 indicates no additional objects." > > > DEFVAL { ''H } > > > ::= { mteTriggerBooleanEntry 5 } > > > > > >mteTriggerBooleanEventOwner OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "To go with mteTriggerBooleanEvent, the mteOwner of an event > > > entry from mteEventTable." > > > DEFVAL { ''H } > > > ::= { mteTriggerBooleanEntry 6 } > > > > > >mteTriggerBooleanEvent OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The mteEventName of the event to invoke when mteTriggerType is > > > 'boolean' and this trigger fires. A length of 0 indicates no > > > event." > > > DEFVAL { ''H } > > > ::= { mteTriggerBooleanEntry 7 } > > > > > > > > >-- > > >-- Trigger Threshold Table > > >-- > > > > > >mteTriggerThresholdTable OBJECT-TYPE > > > SYNTAX SEQUENCE OF MteTriggerThresholdEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 27] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > DESCRIPTION > > > "A table of management event trigger information for threshold > > > triggers." > > > ::= { mteTrigger 6 } > > > > > >mteTriggerThresholdEntry OBJECT-TYPE > > > SYNTAX MteTriggerThresholdEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "Information about a single threshold trigger. Entries > > > automatically exist in this table for each mteTriggerEntry > > > that has 'threshold' set in mteTriggerTest." > > > INDEX { mteOwner, IMPLIED mteTriggerName } > > > ::= { mteTriggerThresholdTable 1 } > > > > > >MteTriggerThresholdEntry ::= SEQUENCE { > > > mteTriggerThresholdStartup INTEGER, > > > mteTriggerThresholdRising Integer32, > > > mteTriggerThresholdFalling Integer32, > > > mteTriggerThresholdDeltaRising Integer32, > > > mteTriggerThresholdDeltaFalling Integer32, > > > mteTriggerThresholdObjectsOwner SnmpAdminString, > > > mteTriggerThresholdObjects SnmpAdminString, > > > mteTriggerThresholdRisingEventOwner SnmpAdminString, > > > mteTriggerThresholdRisingEvent SnmpAdminString, > > > mteTriggerThresholdFallingEventOwner SnmpAdminString, > > > mteTriggerThresholdFallingEvent SnmpAdminString, > > > mteTriggerThresholdDeltaRisingEventOwner SnmpAdminString, > > > mteTriggerThresholdDeltaRisingEvent SnmpAdminString, > > > mteTriggerThresholdDeltaFallingEventOwner SnmpAdminString, > > > mteTriggerThresholdDeltaFallingEvent SnmpAdminString > > >} > > > > > >mteTriggerThresholdStartup OBJECT-TYPE > > > SYNTAX INTEGER { rising(1), falling(2), risingOrFalling(3) } > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The event that may be triggered when this entry is first > > > set to 'active' and a new instance of the object at > > > mteTriggerValueID is found. If the first sample after this > > > instance becomes active is greater than or equal to > > > mteTriggerThresholdRising and mteTriggerThresholdStartup is > > > equal to 'rising' or 'risingOrFalling', then one > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 28] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > mteTriggerThresholdRisingEvent is triggered for that instance. > > > If the first sample after this entry becomes active is less > > > than or equal to mteTriggerThresholdFalling and > > > mteTriggerThresholdStartup is equal to 'falling' or > > > 'risingOrFalling', then one mteTriggerThresholdRisingEvent is > > > triggered for that instance." > > > DEFVAL { risingOrFalling } > > > ::= { mteTriggerThresholdEntry 1 } > > > > > >mteTriggerThresholdRising OBJECT-TYPE > > > SYNTAX Integer32 > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "A threshold value to check against if mteTriggerType is > > > 'threshold'. > > > > > > When the current sampled value is greater than or equal to > > > this threshold, and the value at the last sampling interval > > > was less than this threshold, one > > > mteTriggerThresholdRisingEvent is triggered. That event is > > > also triggered if the first sample after this entry becomes > > > active is greater than or equal to this threshold and > > > mteTriggerThresholdStartup is equal to 'rising' or > > > 'risingOrFalling'. > > > > > > After a rising event is generated, another such event is not > > > triggered until the sampled value falls below this threshold > > > and reaches mteTriggerThresholdFalling." > > > DEFVAL { 0 } > > > ::= { mteTriggerThresholdEntry 2 } > > > > > >mteTriggerThresholdFalling OBJECT-TYPE > > > SYNTAX Integer32 > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "A threshold value to check against if mteTriggerType is > > > 'threshold'. > > > > > > When the current sampled value is less than or equal to this > > > threshold, and the value at the last sampling interval was > > > greater than this threshold, one > > > mteTriggerThresholdFallingEvent is triggered. That event is > > > also triggered if the first sample afer this entry becomes > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 29] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > active is less than or equal to this threshold and > > > mteTriggerThresholdStartup is equal to 'falling' or > > > 'risingOrFalling'. > > > > > > After a falling event is generated, another such event is not > > > triggered until the sampled value rises above this threshold > > > and reaches mteTriggerThresholdRising." > > > DEFVAL { 0 } > > > ::= { mteTriggerThresholdEntry 3 } > > > > > >mteTriggerThresholdDeltaRising OBJECT-TYPE > > > SYNTAX Integer32 > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "A threshold value to check against if mteTriggerType is > > > 'threshold'. > > > > > > When the delta value (difference) between the current sampled > > > value (value(n)) and the previous sampled value (value(n-1)) > > > is greater than or equal to this threshold, > > > and the delta value calculated at the last sampling interval > > > (i.e. value(n-1) - value(n-2)) was less than this threshold, > > > one mteTriggerThresholdDeltaRisingEvent is triggered. That event is > > > also triggered if the first delta value calculated after this > > > entry becomes active, i.e. value(2) - value(1), where value(1) > > > is the first sample taken of that instance, is greater than or > > > equal to this threshold. > > > > > > After a rising event is generated, another such event is not > > > triggered until the delta value falls below this threshold and > > > reaches mteTriggerThresholdDeltaFalling." > > > DEFVAL { 0 } > > > ::= { mteTriggerThresholdEntry 4 } > > > > > >mteTriggerThresholdDeltaFalling OBJECT-TYPE > > > SYNTAX Integer32 > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "A threshold value to check against if mteTriggerType is > > > 'threshold'. > > > > > > When the delta value (difference) between the current sampled > > > value (value(n)) and the previous sampled value (value(n-1)) > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 30] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > is less than or equal to this threshold, > > > and the delta value calculated at the last sampling interval > > > (i.e. value(n-1) - value(n-2)) was greater than this threshold, > > > one mteTriggerThresholdDeltaFallingEvent is triggered. That event is > > > also triggered if the first delta value calculated after this > > > entry becomes active, i.e. value(2) - value(1), where value(1) > > > is the first sample taken of that instance, is less than or > > > equal to this threshold. > > > > > > After a falling event is generated, another such event is not > > > triggered until the delta value falls below this threshold and > > > reaches mteTriggerThresholdDeltaRising." > > > DEFVAL { 0 } > > > ::= { mteTriggerThresholdEntry 5 } > > > > > >mteTriggerThresholdObjectsOwner OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "To go with mteTriggerThresholdObjects, the mteOwner of a group > > > of objects from mteObjectsTable." > > > DEFVAL { ''H } > > > ::= { mteTriggerThresholdEntry 6 } > > > > > >mteTriggerThresholdObjects OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The mteObjectsName of a group of objects from > > > mteObjectsTable. These objects are to be added to any > > > Notification resulting from the firing of this trigger for > > > this test. > > > > > > A list of objects may also be added based on the overall > > > trigger, the event or other settings in mteTriggerTest. > > > > > > A length of 0 indicates no additional objects." > > > DEFVAL { ''H } > > > ::= { mteTriggerThresholdEntry 7 } > > > > > >mteTriggerThresholdRisingEventOwner OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-write > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 31] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > STATUS current > > > DESCRIPTION > > > "To go with mteTriggerThresholdRisingEvent, the mteOwner of an > > > event entry from mteEventTable." > > > DEFVAL { ''H } > > > ::= { mteTriggerThresholdEntry 8 } > > > > > >mteTriggerThresholdRisingEvent OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The mteEventName of the event to invoke when mteTriggerType is > > > 'threshold' and this trigger fires based on > > > mteTriggerThresholdRising. A length of 0 indicates no event." > > > DEFVAL { ''H } > > > ::= { mteTriggerThresholdEntry 9 } > > > > > >mteTriggerThresholdFallingEventOwner OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "To go with mteTriggerThresholdFallingEvent, the mteOwner of an > > > event entry from mteEventTable." > > > DEFVAL { ''H } > > > ::= { mteTriggerThresholdEntry 10 } > > > > > >mteTriggerThresholdFallingEvent OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The mteEventName of the event to invoke when mteTriggerType is > > > 'threshold' and this trigger fires based on > > > mteTriggerThresholdFalling. A length of 0 indicates no event." > > > DEFVAL { ''H } > > > ::= { mteTriggerThresholdEntry 11 } > > > > > >mteTriggerThresholdDeltaRisingEventOwner OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "To go with mteTriggerThresholdDeltaRisingEvent, the mteOwner > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 32] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > of an event entry from mteEventTable." > > > DEFVAL { ''H } > > > ::= { mteTriggerThresholdEntry 12 } > > > > > >mteTriggerThresholdDeltaRisingEvent OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The mteEventName of the event to invoke when mteTriggerType is > > > 'threshold' and this trigger fires based on > > > mteTriggerThresholdDeltaRising. A length of 0 indicates > > > no event." > > > DEFVAL { ''H } > > > ::= { mteTriggerThresholdEntry 13 } > > > > > >mteTriggerThresholdDeltaFallingEventOwner OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "To go with mteTriggerThresholdDeltaFallingEvent, the mteOwner > > > of an event entry from mteEventTable." > > > DEFVAL { ''H } > > > ::= { mteTriggerThresholdEntry 14 } > > > > > >mteTriggerThresholdDeltaFallingEvent OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The mteEventName of the event to invoke when mteTriggerType is > > > 'threshold' and this trigger fires based on > > > mteTriggerThresholdDeltaFalling. A length of 0 indicates > > > no event." > > > DEFVAL { ''H } > > > ::= { mteTriggerThresholdEntry 15 } > > > > > > > > >-- > > >-- Objects Table > > >-- > > > > > >mteObjectsTable OBJECT-TYPE > > > SYNTAX SEQUENCE OF MteObjectsEntry > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 33] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "A table of objects that can be added to notifications based > > > on the trigger, trigger test, or event, as pointed to by > > > entries in those tables." > > > ::= { mteObjects 1 } > > > > > >mteObjectsEntry OBJECT-TYPE > > > SYNTAX MteObjectsEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "A group of objects. Applications create and delete entries > > > using mteObjectsEntryStatus. > > > > > > When adding objects to a notification they are added in the > > > lexical order of their index in this table. Those associated > > > with a trigger come first, then trigger test, then event." > > > INDEX { mteOwner, mteObjectsName, mteObjectsIndex } > > > ::= { mteObjectsTable 1 } > > > > > >MteObjectsEntry ::= SEQUENCE { > > > mteObjectsName SnmpAdminString, > > > mteObjectsIndex Unsigned32, > > > mteObjectsID OBJECT IDENTIFIER, > > > mteObjectsIDWildcard TruthValue, > > > mteObjectsEntryStatus RowStatus > > > } > > > > > >mteObjectsName OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (1..32)) > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "A locally-unique, administratively assigned name for a group > > > of objects." > > > ::= { mteObjectsEntry 1 } > > > > > >mteObjectsIndex OBJECT-TYPE > > > SYNTAX Unsigned32 (1..4294967295) > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "An arbitrary integer for the purpose of identifying > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 34] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > individual objects within a mteObjectsName group. > > > > > > Objects within a group are placed in the notification in the > > > numerical order of this index. > > > > > > Groups are placed in the notification in the order of the > > > selections for overall trigger, trigger test, and event. > > > Within trigger test they are in the same order as the > > > numerical values of the bits defined for mteTriggerTest. > > > > > > Bad object identifiers or a mismatch between truncating the > > > identifier and the value of mteDeltaDiscontinuityIDWildcard > > > result in operation as one would expect when providing the > > > wrong identifier to a Get operation. The Get will fail or get > > > the wrong object. If the object is not available it is omitted > > > from the notification." > > > ::= { mteObjectsEntry 2 } > > > > > >mteObjectsID OBJECT-TYPE > > > SYNTAX OBJECT IDENTIFIER > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "The object identifier of a MIB object to add to a > > > Notification that results from the firing of a trigger. > > > > > > This may be wildcarded by truncating all or part of the > > > instance portion, in which case the instance portion of the > > > OID for obtaining this object will be the same as that used > > > in obtaining the mteTriggerValueID that fired. If such > > > wildcarding is applied, mteObjectsIDWildcard must be > > > 'true' and if not it must be 'false'. > > > > > > Each instance that fills the wildcard is independent of any > > > additional instances, that is, wildcarded objects operate > > > as if there were a separate table entry for each instance > > > that fills the wildcard without having to actually predict > > > all possible instances ahead of time." > > > DEFVAL { zeroDotZero } > > > ::= { mteObjectsEntry 3 } > > > > > >mteObjectsIDWildcard OBJECT-TYPE > > > SYNTAX TruthValue > > > MAX-ACCESS read-create > > > STATUS current > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 35] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > DESCRIPTION > > > "Control for whether mteObjectsID is to be treated as > > > fully-specified or wildcarded, with 'true' indicating wildcard." > > > DEFVAL { false } > > > ::= { mteObjectsEntry 4 } > > > > > >mteObjectsEntryStatus OBJECT-TYPE > > > SYNTAX RowStatus > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "The control that allows creation and deletion of entries. > > > Once made active an entry MAY not be modified except to > > > delete it." > > > ::= { mteObjectsEntry 5 } > > > > > > > > >-- > > >-- Event Section > > >-- > > > > > >-- Counters > > > > > >mteEventFailures OBJECT-TYPE > > > SYNTAX Counter32 > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION > > > "The number of times an attempt to invoke an event > > > has failed. This counts individually for each > > > attempt in a group of targets or each attempt for a > > > wildcarded trigger object." > > > ::= { mteEvent 1 } > > > > > > > > >-- > > >-- Event Table > > >-- > > > > > >mteEventTable OBJECT-TYPE > > > SYNTAX SEQUENCE OF MteEventEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "A table of management event action information." > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 36] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > ::= { mteEvent 2 } > > > > > >mteEventEntry OBJECT-TYPE > > > SYNTAX MteEventEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "Information about a single event. Applications create and > > > delete entries using mteEventEntryStatus." > > > INDEX { mteOwner, IMPLIED mteEventName } > > > ::= { mteEventTable 1 } > > > > > >MteEventEntry ::= SEQUENCE { > > > mteEventName SnmpAdminString, > > > mteEventComment SnmpAdminString, > > > mteEventActions BITS, > > > mteEventEnabled TruthValue, > > > mteEventEntryStatus RowStatus > > > } > > > > > >mteEventName OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (1..32)) > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "A locally-unique, administratively assigned name for the > > > event." > > > ::= { mteEventEntry 1 } > > > > > >mteEventComment OBJECT-TYPE > > > SYNTAX SnmpAdminString > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "A description of the event's function and use." > > > DEFVAL { ''H } > > > ::= { mteEventEntry 2 } > > > > > >mteEventActions OBJECT-TYPE > > > SYNTAX BITS { notification(0), set(1) } > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "The actions to perform when this event occurs. > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 37] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > For 'notification', Traps and/or Informs are sent according > > > to the configuration in the SNMP Notification MIB. > > > > > > For 'set', an SNMP Set operation is performed according to > > > control values in this entry." > > > DEFVAL { {} } -- No bits set. > > > ::= { mteEventEntry 3 } > > > > > >mteEventEnabled OBJECT-TYPE > > > SYNTAX TruthValue > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "A control to allow an event to be configured but not used. > > > When the value is 'false' the event does not execute even if > > > triggered." > > > DEFVAL { false } > > > ::= { mteEventEntry 4 } > > > > > >mteEventEntryStatus OBJECT-TYPE > > > SYNTAX RowStatus > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "The control that allows creation and deletion of entries. > > > Once made active an entry MAY not be modified except to > > > delete it." > > > ::= { mteEventEntry 5 } > > > > > > > > >-- > > >-- Event Notification Table > > >-- > > > > > >mteEventNotificationTable OBJECT-TYPE > > > SYNTAX SEQUENCE OF MteEventNotificationEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "A table of information about notifications to be sent as a > > > consequence of management events." > > > ::= { mteEvent 3 } > > > > > >mteEventNotificationEntry OBJECT-TYPE > > > SYNTAX MteEventNotificationEntry > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 38] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "Information about a single event's notification. Entries > > > automatically exist in this this table for each mteEventEntry > > > that has 'notification' set in mteEventActions." > > > INDEX { mteOwner, IMPLIED mteEventName } > > > ::= { mteEventNotificationTable 1 } > > > > > >MteEventNotificationEntry ::= SEQUENCE { > > > mteEventNotification OBJECT IDENTIFIER, > > > mteEventNotificationObjectsOwner SnmpAdminString, > > > mteEventNotificationObjects SnmpAdminString > > > } > > > > > >mteEventNotification OBJECT-TYPE > > > SYNTAX OBJECT IDENTIFIER > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The object identifier from the NOTIFICATION-TYPE for the > > > notification to use if metEventActions has 'notification' set." > > > DEFVAL { zeroDotZero } > > > ::= { mteEventNotificationEntry 1 } > > > > > >mteEventNotificationObjectsOwner OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "To go with mteEventNotificationObjects, the mteOwner of a > > > group of objects from mteObjectsTable." > > > DEFVAL { ''H } > > > ::= { mteEventNotificationEntry 2 } > > > > > >mteEventNotificationObjects OBJECT-TYPE > > > SYNTAX SnmpAdminString (SIZE (0..32)) > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The mteObjectsName of a group of objects from > > > mteObjectsTable if mteEventActions has 'notification' set. > > > These objects are to be added to any Notification generated by > > > this event. > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 39] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > Objects may also be added based on the trigger that stimulated > > > the event. > > > > > > A length of 0 indicates no additional objects." > > > DEFVAL { ''H } > > > ::= { mteEventNotificationEntry 3 } > > > > > > > > >-- > > >-- Event Set Table > > >-- > > > > > >mteEventSetTable OBJECT-TYPE > > > SYNTAX SEQUENCE OF MteEventSetEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "A table of management event action information." > > > ::= { mteEvent 4 } > > > > > >mteEventSetEntry OBJECT-TYPE > > > SYNTAX MteEventSetEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "Information about a single event's set option. Entries > > > automatically exist in this this table for each mteEventEntry > > > that has 'set' set in mteEventActions." > > > INDEX { mteOwner, IMPLIED mteEventName } > > > ::= { mteEventSetTable 1 } > > > > > >MteEventSetEntry ::= SEQUENCE { > > > mteEventSetObject OBJECT IDENTIFIER, > > > mteEventSetObjectWildcard TruthValue, > > > mteEventSetValue Integer32, > > > mteEventSetTargetTag SnmpTagValue, > > > mteEventSetContextName SnmpAdminString, > > > mteEventSetContextNameWildcard TruthValue > > > } > > > > > >mteEventSetObject OBJECT-TYPE > > > SYNTAX OBJECT IDENTIFIER > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 40] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > "The object identifier from the MIB object to set if > > > mteEventActions has 'set' set. > > > > > > This object identifier may be wildcarded by leaving > > > sub-identifiers off the end, in which case > > > nteEventSetObjectWildCard must be 'true'. > > > > > > If mteEventSetObject is wildcarded the instance used to set the > > > object to which it points is the same as the instance from the > > > value of mteTriggerValueID that triggered the event. > > > > > > Each instance that fills the wildcard is independent of any > > > additional instances, that is, wildcarded objects operate > > > as if there were a separate table entry for each instance > > > that fills the wildcard without having to actually predict > > > all possible instances ahead of time. > > > > > > Bad object identifiers or a mismatch between truncating the > > > identifier and the value of mteSetObjectWildcard > > > result in operation as one would expect when providing the > > > wrong identifier to a Set operation. The Set will fail or set > > > the wrong object. If the value syntax of the destination > > > object is not correct, the Set fails with the normal SNMP > > > error code." > > > DEFVAL { zeroDotZero } > > > ::= { mteEventSetEntry 1 } > > > > > >mteEventSetObjectWildcard OBJECT-TYPE > > > SYNTAX TruthValue > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "Control over whether mteEventSetObject is to be treated as > > > fully-specified or wildcarded, with 'true' indicating wildcard > > > if mteEventActions has 'set' set." > > > DEFVAL { false } > > > ::= { mteEventSetEntry 2 } > > > > > >mteEventSetValue OBJECT-TYPE > > > SYNTAX Integer32 > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The value to which to set the object at mteEventSetObject > > > if mteEventActions has 'set' set." > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 41] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > DEFVAL { 0 } > > > ::= { mteEventSetEntry 3 } > > > > > >mteEventSetTargetTag OBJECT-TYPE > > > SYNTAX SnmpTagValue > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The tag for the target(s) at which to set the object at > > > mteEventSetObject to mteEventSetValue if mteEventActions > > > has 'set' set. > > > > > > Systems limited to self management MAY reject a non-zero > > > length for the value of this object. > > > > > > A length of 0 indicates the local system. In this case, > > > access to the objects indicated by mteEventSetObject is under > > > the security credentials of the requester that set > > > mteTriggerEntryStatus to 'active'. Those credentials are the > > > input parameters for isAccessAllowed from the Architecture for > > > Describing SNMP Management Frameworks. > > > > > > Otherwise access rights are checked according to the security > > > parameters resulting from the tag." > > > DEFVAL { ''H } > > > ::= { mteEventSetEntry 4 } > > > > > >mteEventSetContextName OBJECT-TYPE > > > SYNTAX SnmpAdminString > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The management context in which to set mteEventObjectID. > > > if mteEventActions has 'set' set. > > > > > > This may be wildcarded by leaving characters off the end. To > > > indicate such wildcarding mteEventSetContextNameWildcard must > > > be 'true'. > > > > > > If this context name is wildcarded the value used to complete > > > the wildcarding of mteTriggerContextName will be appended." > > > DEFVAL { ''H } > > > ::= { mteEventSetEntry 5 } > > > > > >mteEventSetContextNameWildcard OBJECT-TYPE > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 42] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > SYNTAX TruthValue > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "Control for whether mteEventSetContextName is to be treated as > > > fully-specified or wildcarded, with 'true' indicating wildcard > > > if mteEventActions has 'set' set." > > > DEFVAL { false } > > > ::= { mteEventSetEntry 6 } > > > > > > > > >-- > > >-- Notifications > > >-- > > > > > >dismanEventMIBNotificationPrefix OBJECT IDENTIFIER ::= > > > { dismanEventMIB 2 } > > >dismanEventMIBNotifications OBJECT IDENTIFIER ::= > > > { dismanEventMIBNotificationPrefix 0 } > > >dismanEventMIBNotificationObjects OBJECT IDENTIFIER > > > ::= { dismanEventMIBNotificationPrefix 1 } > > > > > >-- > > >-- Notification Objects > > >-- > > > > > >mteHotTrigger OBJECT-TYPE > > > SYNTAX SnmpAdminString > > > MAX-ACCESS accessible-for-notify > > > STATUS current > > > DESCRIPTION > > > "The name of the trigger causing the notification." > > > ::= { dismanEventMIBNotificationObjects 1 } > > > > > >mteHotTargetName OBJECT-TYPE > > > SYNTAX SnmpAdminString > > > MAX-ACCESS accessible-for-notify > > > STATUS current > > > DESCRIPTION > > > "The SNMP Target MIB's snmpTargetAddrName related to the > > > notification." > > > ::= { dismanEventMIBNotificationObjects 2 } > > > > > >mteHotContextName OBJECT-TYPE > > > SYNTAX SnmpAdminString > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 43] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > MAX-ACCESS accessible-for-notify > > > STATUS current > > > DESCRIPTION > > > "The context name related to the notification. This MUST be as > > > fully-qualified as possible, including filling in wildcard > > > information determined in processing." > > > ::= { dismanEventMIBNotificationObjects 3 } > > > > > >mteHotOID OBJECT-TYPE > > > SYNTAX OBJECT IDENTIFIER > > > MAX-ACCESS accessible-for-notify > > > STATUS current > > > DESCRIPTION > > > "The object identifier of the destination object related to the > > > notification. This MUST be as fully-qualified as possible, > > > inluding filling in wildcard information determined in > > > processing. > > > > > > For a trigger-related notification this is from > > > mteTriggerValueID. > > > > > > For a set failure this is from mteEventSetObject." > > > ::= { dismanEventMIBNotificationObjects 4 } > > > > > >mteHotValue OBJECT-TYPE > > > SYNTAX Integer32 > > > MAX-ACCESS accessible-for-notify > > > STATUS current > > > DESCRIPTION > > > "The value of the object at mteTriggerValueID when a > > > trigger fired." > > > ::= { dismanEventMIBNotificationObjects 5 } > > > > > >mteFailedReason OBJECT-TYPE > > > SYNTAX FailureReason > > > MAX-ACCESS accessible-for-notify > > > STATUS current > > > DESCRIPTION > > > "The reason for the failure of an attempt to check for a > > > trigger condition or set an object in response to an event." > > > ::= { dismanEventMIBNotificationObjects 6 } > > > > > >-- > > >-- Notifications > > >-- > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 44] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > >mteTriggerFired NOTIFICATION-TYPE > > > OBJECTS { mteHotTrigger, > > > mteHotTargetName, > > > mteHotContextName, > > > mteHotOID, > > > mteHotValue } > > > STATUS current > > > DESCRIPTION > > > "Notification that the trigger indicated by the object > > > instances has fired, for triggers with mteTriggerType > > > 'boolean' or 'existence'." > > > ::= { dismanEventMIBNotifications 1 } > > > > > >mteTriggerRising NOTIFICATION-TYPE > > > OBJECTS { mteHotTrigger, > > > mteHotTargetName, > > > mteHotContextName, > > > mteHotOID, > > > mteHotValue } > > > STATUS current > > > DESCRIPTION > > > "Notification that the rising threshold was met for triggers > > > with mteTriggerType 'threshold'." > > > ::= { dismanEventMIBNotifications 2 } > > > > > >mteTriggerFalling NOTIFICATION-TYPE > > > OBJECTS { mteHotTrigger, > > > mteHotTargetName, > > > mteHotContextName, > > > mteHotOID, > > > mteHotValue } > > > STATUS current > > > DESCRIPTION > > > "Notification that the falling threshold was met for triggers > > > with mteTriggerType 'threshold'." > > > ::= { dismanEventMIBNotifications 3 } > > > > > >mteTriggerFailure NOTIFICATION-TYPE > > > OBJECTS { mteHotTrigger, > > > mteHotTargetName, > > > mteHotContextName, > > > mteHotOID, > > > mteFailedReason } > > > STATUS current > > > DESCRIPTION > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 45] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > "Notification that an attempt to check a trigger has failed. > > > > > > The network manager must enable this notification only with > > > a certain fear and trembling, as it can easily crowd out more > > > important information. It should be used only to help diagnose > > > a problem that has appeared in the error counters and can not > > > be found otherwise." > > > ::= { dismanEventMIBNotifications 4 } > > > > > >mteEventSetFailure NOTIFICATION-TYPE > > > OBJECTS { mteHotTrigger, > > > mteHotTargetName, > > > mteHotContextName, > > > mteHotOID, > > > mteFailedReason } > > > STATUS current > > > DESCRIPTION > > > "Notification that an attempt to do a set in response to an > > > event has failed. > > > > > > The network manager must enable this notification only with > > > a certain fear and trembling, as it can easily crowd out more > > > important information. It should be used only to help diagnose > > > a problem that has appeared in the error counters and can not > > > be found otherwise." > > > ::= { dismanEventMIBNotifications 5 } > > > > > > > > >-- > > >-- Conformance > > >-- > > > > > >dismanEventMIBConformance OBJECT IDENTIFIER ::= { dismanEventMIB 3 } > > >dismanEventMIBCompliances OBJECT IDENTIFIER ::= > > > { dismanEventMIBConformance 1 } > > >dismanEventMIBGroups OBJECT IDENTIFIER ::= > > > { dismanEventMIBConformance 2 } > > > > > >-- Compliance > > > > > >dismanEventMIBCompliance MODULE-COMPLIANCE > > > STATUS current > > > DESCRIPTION > > > "The compliance statement for entities which implement > > > the Event MIB." > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 46] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > MODULE -- this module > > > MANDATORY-GROUPS { > > > dismanEventResourceGroup, > > > dismanEventTriggerGroup, > > > dismanEventObjectsGroup, > > > dismanEventEventGroup, > > > dismanEventNotificationObjectGroup, > > > dismanEventNotificationGroup > > > } > > > > > > OBJECT mteTriggerTargetTag > > > MIN-ACCESS read-only > > > DESCRIPTION > > > "Write access is not required, thus limiting > > > monitoring to the local system or pre-configured > > > remote systems." > > > > > > OBJECT mteEventSetTargetTag > > > MIN-ACCESS read-only > > > DESCRIPTION > > > "Write access is not required, thus limiting > > > setting to the local system or pre-configured > > > remote systems." > > > > > > OBJECT mteTriggerValueIDWildcard > > > MIN-ACCESS read-only > > > DESCRIPTION > > > "Write access is not required, thus allowing > > > the system not to implement wildcarding." > > > > > > OBJECT mteTriggerContextNameWildcard > > > MIN-ACCESS read-only > > > DESCRIPTION > > > "Write access is not required, thus allowing > > > the system not to implement wildcarding." > > > > > > > > > OBJECT mteObjectsIDWildcard > > > MIN-ACCESS read-only > > > DESCRIPTION > > > "Write access is not required, thus allowing > > > the system not to implement wildcarding." > > > > > > OBJECT mteEventSetContextNameWildcard > > > MIN-ACCESS read-only > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 47] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > DESCRIPTION > > > "Write access is not required, thus allowing > > > the system not to implement wildcarding." > > > > > > ::= { dismanEventMIBCompliances 1 } > > > > > >-- Units of Conformance > > > > > > > > > > > >dismanEventResourceGroup OBJECT-GROUP > > > OBJECTS { > > > mteResourceSampleMinimum, > > > mteResourceSampleInstanceMaximum, > > > mteResourceSampleInstances, > > > mteResourceSampleInstancesHigh, > > > mteResourceSampleInstanceLacks > > > } > > > STATUS current > > > DESCRIPTION > > > "Event resource status and control objects." > > > ::= { dismanEventMIBGroups 1 } > > > > > >dismanEventTriggerGroup OBJECT-GROUP > > > OBJECTS { > > > mteTriggerFailures, > > > > > > mteTriggerComment, > > > mteTriggerTest, > > > mteTriggerSampleType, > > > mteTriggerValueID, > > > mteTriggerValueIDWildcard, > > > mteTriggerTargetTag, > > > mteTriggerContextName, > > > mteTriggerContextNameWildcard, > > > mteTriggerFrequency, > > > mteTriggerObjectsOwner, > > > mteTriggerObjects, > > > mteTriggerEnabled, > > > mteTriggerEntryStatus, > > > > > > mteTriggerDeltaDiscontinuityID, > > > mteTriggerDeltaDiscontinuityIDWildcard, > > > mteTriggerDeltaDiscontinuityIDType, > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 48] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > mteTriggerExistenceTest, > > > mteTriggerExistenceStartup, > > > mteTriggerExistenceObjectsOwner, > > > mteTriggerExistenceObjects, > > > mteTriggerExistenceEventOwner, > > > mteTriggerExistenceEvent, > > > > > > mteTriggerBooleanComparison, > > > mteTriggerBooleanValue, > > > mteTriggerBooleanStartup, > > > mteTriggerBooleanObjectsOwner, > > > mteTriggerBooleanObjects, > > > mteTriggerBooleanEventOwner, > > > mteTriggerBooleanEvent, > > > > > > mteTriggerThresholdStartup, > > > mteTriggerThresholdObjectsOwner, > > > mteTriggerThresholdObjects, > > > mteTriggerThresholdRising, > > > mteTriggerThresholdFalling, > > > mteTriggerThresholdDeltaRising, > > > mteTriggerThresholdDeltaFalling, > > > mteTriggerThresholdRisingEventOwner, > > > mteTriggerThresholdRisingEvent, > > > mteTriggerThresholdFallingEventOwner, > > > mteTriggerThresholdFallingEvent, > > > mteTriggerThresholdDeltaRisingEventOwner, > > > mteTriggerThresholdDeltaRisingEvent, > > > mteTriggerThresholdDeltaFallingEventOwner, > > > mteTriggerThresholdDeltaFallingEvent > > > } > > > STATUS current > > > DESCRIPTION > > > "Event triggers." > > > ::= { dismanEventMIBGroups 2 } > > > > > >dismanEventObjectsGroup OBJECT-GROUP > > > OBJECTS { > > > mteObjectsID, > > > mteObjectsIDWildcard, > > > mteObjectsEntryStatus > > > } > > > STATUS current > > > DESCRIPTION > > > "Supplemental objects." > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 49] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > ::= { dismanEventMIBGroups 3 } > > > > > >dismanEventEventGroup OBJECT-GROUP > > > OBJECTS { > > > mteEventFailures, > > > > > > mteEventComment, > > > mteEventActions, > > > mteEventEnabled, > > > mteEventEntryStatus, > > > > > > mteEventNotification, > > > mteEventNotificationObjectsOwner, > > > mteEventNotificationObjects, > > > > > > mteEventSetObject, > > > mteEventSetObjectWildcard, > > > mteEventSetValue, > > > mteEventSetTargetTag, > > > mteEventSetContextName, > > > mteEventSetContextNameWildcard > > > } > > > STATUS current > > > DESCRIPTION > > > "Events." > > > ::= { dismanEventMIBGroups 4 } > > > > > >dismanEventNotificationObjectGroup OBJECT-GROUP > > > OBJECTS { > > > mteHotTrigger, > > > mteHotTargetName, > > > mteHotContextName, > > > mteHotOID, > > > mteHotValue, > > > mteFailedReason > > > } > > > STATUS current > > > DESCRIPTION > > > "Notification objects." > > > ::= { dismanEventMIBGroups 5 } > > > > > >dismanEventNotificationGroup NOTIFICATION-GROUP > > > NOTIFICATIONS { > > > mteTriggerFired, > > > mteTriggerRising, > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 50] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > mteTriggerFalling, > > > mteTriggerFailure, > > > mteEventSetFailure > > > } > > > STATUS current > > > DESCRIPTION > > > "Notifications." > > > ::= { dismanEventMIBGroups 6 } > > > > > >END > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 51] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > >9. Intellectual Property > > > > > >The IETF takes no position regarding the validity or scope of any > > >intellectual property or other rights that might be claimed to pertain > > >to the implementation or use of the technology described in this > > >document or the extent to which any license under such rights might or > > >might not be available; neither does it represent that it has made any > > >effort to identify any such rights. Information on the IETF's > > >procedures with respect to rights in standards-track and standards- > > >related documentation can be found in BCP-11. Copies of claims of > > >rights made available for publication and any assurances of licenses to > > >be made available, or the result of an attempt made to obtain a general > > >license or permission for the use of such proprietary rights by > > >implementors or users of this specification can be obtained from the > > >IETF Secretariat. > > > > > >The IETF invites any interested party to bring to its attention any > > >copyrights, patents or patent applications, or other proprietary rights > > >which may cover technology that may be required to practice this > > >standard. Please address the information to the IETF Executive > > >Director. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 52] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > >10. Acknowledgements > > > > > >This MIB contains considerable contributions from the RMON MIB, the > > >Distributed Management Design Team (Andy Bierman, Maria Greene, Bob > > >Stewart, and Steve Waldbusser), the Distributed Management Working > > >Group, and colleagues at Cisco. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 53] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > >11. References > > > > > >[RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture > > > for Describing SNMP Management Frameworks", RFC 2571, April > > > 1999 > > > > > >[RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification > > > of Management Information for TCP/IP-based Internets", STD > > > 16, RFC 1155, May 1990 > > > > > >[RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD > > > 16, RFC 1212, March 1991 > > > > > >[RFC1215] M. Rose, "A Convention for Defining Traps for use with the > > > SNMP", RFC 1215, March 1991 > > > > > >[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., > > > Rose, M., and S. Waldbusser, "Structure of Management > > > Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999 > > > > > >[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., > > > Rose, M., and S. Waldbusser, "Textual Conventions for > > > SMIv2", STD 58, RFC 2579, April 1999 > > > > > >[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., > > > Rose, M., and S. Waldbusser, "Conformance Statements for > > > SMIv2", STD 58, RFC 2580, April 1999 > > > > > >[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple > > > Network Management Protocol", STD 15, RFC 1157, May 1990. > > > > > >[RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, > > > "Introduction to Community-based SNMPv2", RFC 1901, January > > > 1996. > > > > > >[RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, > > > "Transport Mappings for Version 2 of the Simple Network > > > Management Protocol (SNMPv2)", RFC 1906, January 1996. > > > > > >[RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message > > > Processing and Dispatching for the Simple Network Management > > > Protocol (SNMP)", RFC 2572, April 1999 > > > > > >[RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model > > > (USM) for version 3 of the Simple Network Management > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 54] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > > Protocol (SNMPv3)", RFC 2574, April 1999 > > > > > >[RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, > > > "Protocol Operations for Version 2 of the Simple Network > > > Management Protocol (SNMPv2)", RFC 1905, January 1996. > > > > > >[RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", > > > RFC 2573, April 1999 > > > > > >[RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based > > > Access Control Model (VACM) for the Simple Network > > > Management Protocol (SNMP)", RFC 2575, April 1999 > > > > > >[RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, > > > "Introduction to Version 3 of the Internet-standard Network > > > Management Framework", RFC 2570, April 1999 > > > > > >[RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, > > > "Coexistence between Version 1 and version 2 of the > > > Internet-standard Network Management Framework", RFC 1903, > > > January 1996. > > > > > >[RFCEventMIB] > > > Stewart, B., "Event MIB", RFC ????, ?Month? 1999. > > > > > >[RFC1757] > > > Waldbusser, S., "Remote Network Monitoring Management Information > > > Base", RFC 1757, February 1995. > > > > > >[RFC1451] > > > Case, J., McCloghrie, K., Rose, M., Waldbusser, S., "Manager-to- > > > Manager Management Information Base", RFC 1451, April 1993. > > > > > >[RFCExpressionMIB] > > > Stewart, B., "Expression MIB", RFC ????, ?Month? 1999. > > > > > >[RFCNotificationLogMIB] > > > Stewart, B., "Notification Log MIB", RFC ????, ?Month? 1999. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 55] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > >12. Security Considerations > > > > > >Security issues are discussed in the Security section and in the > > >DESCRIPTION clauses of relevant objects. > > > > > > > > >13. Author's Address > > > > > > Bob Stewart > > > Cisco Systems, Inc. > > > 170 West Tasman Drive > > > San Jose, CA 95134-1706 > > > U.S.A. > > > > > > > > >14. Editor's Address > > > > > > Ramanathan Kavasseri > > > Cisco Systems, Inc. > > > 170 West Tasman Drive > > > San Jose, CA 95134-1706 > > > U.S.A. > > > > > > Phone: +1 408 527 2446 > > > Email: ramk@cisco.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 56] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > >15. 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 57] > > > > > > > > > > > > > > > > > >Internet Draft Distributed Management Event MIB 7 June 2000 > > > > > > > > >Table of Contents > > > > > > > > >1 Abstract ........................................................ 2 > > >2 The SNMP Management Framework ................................... 2 > > >3 Overview ........................................................ 4 > > >4 Relationship to Other MIBs ...................................... 4 > > >5 MIB Sections .................................................... 4 > > >6 Operation ....................................................... 7 > > >7 Security ........................................................ 8 > > >8 Definitions ..................................................... 9 > > >9 Intellectual Property ........................................... 52 > > >10 Acknowledgements ............................................... 53 > > >11 References ..................................................... 54 > > >12 Security Considerations ........................................ 56 > > >13 Author's Address ............................................... 56 > > >14 Editor's Address ............................................... 56 > > >15 Full Copyright Statement ....................................... 57 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires 7 December 2000 [Page 58] > > > > > > > > > > > > From owner-disman@dorothy.peer.com Fri Jul 7 18:40:16 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14897 for ; Fri, 7 Jul 2000 18:40:15 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e67MckZ00533; Fri, 7 Jul 2000 17:38:46 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA06564 for disman-list; Fri, 7 Jul 2000 15:36:52 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA06558 for disman@dorothy.bmc.com; Fri, 7 Jul 2000 15:36:48 -0700 (PDT) Date: Fri, 7 Jul 2000 15:36:48 -0700 (PDT) From: Randy Presuhn Message-Id: <200007072236.PAA06558@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Re:Discrepancy in the Event MIB draft (draft-ietf-disman-event-mib-09.txt) 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 - I only object to the HTML. The correction of a obvious typos is routinely handled during the RFC publication process. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- > From owner-disman@dorothy.bmc.com Thu Jun 15 08:29:36 PDT 2000 > Message-Id: <4.1.20000615082218.00a66ca0@sigma.cisco.com> > Date: Thu, 15 Jun 2000 08:25:08 -0700 > To: jaya@cisco.com > From: Ramanathan Kavasseri > Subject: Re:Discrepancy in the Event MIB draft > (draft-ietf-disman-event-mib-09.txt) > Cc: disman@dorothy.peer.com, net-man@cisco.com, asethi@cisco.com > In-Reply-To: <3948C2D4.F62F69B4@cisco.com> > List-Id: IETF disman Working Group mailing list > > > --=====================_507605848==_.ALT > Content-Type: text/plain; charset="us-ascii" > > At 05:19 PM 6/15/00 +0530, Jayashree wrote: > > > > Hi Ram > > Well there was a misalignment in the previous mail regarding the change . > > Please note that the change is now been indicated by a bold Font. > > > > Jaya, > > it certainly is a discrepancy. Since it is a typo, and the intended meaning is > fairly obvious, > I'd like to include this change when releasing the updated event mib draft > (draft-ietf-disman-event-mib-10.txt) > later today, along with other typo-fixes that Randy had brought to my > attention. > > Randy, Bert, any objection to fixing this at this stage? > > Thanks, > > Ram > > > > > > According to the Disman Event MIB draft (draft-ietf-disman-event-mib-09.txt) > > -: > > > > > > > > mteTriggerThresholdStartup OBJECT-TYPE > > > > Description -: > > "The event that may be triggered when this entry is first set to 'active' and > > a new instance of the object at mteTriggerValueID is found. > > > > If the first sample after this instance becomes active is greater than or > > equal to mteTriggerThresholdRising and > > mteTriggerThresholdStartup is equal to 'rising' or 'risingOrFalling', then > > one mteTriggerThresholdRisingEvent is triggered for that > > instance. > > > > If the first sample after this entry becomes active is less than or equal to > > mteTriggerThresholdFalling and mteTriggerThresholdStartup > > is equal to 'falling' or 'risingOrFalling', then one > > mteTriggerThresholdRisingEvent is triggered for that instance." > > > > > > > > In my opinion this should be changed to the description given below > > > > Description -: > > "The event that may be triggered when this entry is first set to 'active' and > > a new instance of the object at mteTriggerValueID is found. > > > > If the first sample after this instance becomes active is greater than or > > equal to > > mteTriggerThresholdRising and mteTriggerThresholdStartup is equal to 'rising' > > or 'risingOrFalling', then one > > mteTriggerThresholdRisingEvent is triggered for that instance. > > > > If the first sample after this entry becomes active is less than or equal to > > mteTriggerThresholdFalling and mteTriggerThresholdStartup > > is equal to 'Falling' or 'risingOrFalling', then one > > mteTriggerThresholdFallingEvent is triggered for that instance." > > > > Thanx > > Jaya > > > > > > --=====================_507605848==_.ALT > Content-Type: text/html; charset="us-ascii" > > > At 05:19 PM 6/15/00 +0530, Jayashree wrote:
>
Hi Ram
>    Well there was a misalignment in the previous mail regarding > the change . Please note that the change is now been indicated by a > bold Font.

>
> Jaya,
>
> it certainly is a discrepancy. Since it is a typo, and the intended > meaning is fairly obvious,
> I'd like to include this change when releasing the updated event mib > draft (draft-ietf-disman-event-mib-10.txt)
> later today, along with other typo-fixes that Randy had brought to my > attention.
>
> Randy, Bert, any objection to fixing this at this stage?
>
> Thanks,
>
> Ram
>
>
>
According to the Disman Event MIB draft > (draft-ietf-disman-event-mib-09.txt) -:
>
> <Snip>
>
> mteTriggerThresholdStartup OBJECT-TYPE
>
> Description -:
> "The event that may be triggered when this entry is first set to > 'active' and a new instance of the object at mteTriggerValueID is found. >
>
> If the first sample after this instance becomes active is greater than or > equal to mteTriggerThresholdRising and
> mteTriggerThresholdStartup is equal to 'rising' or 'risingOrFalling', > then one mteTriggerThresholdRisingEvent is triggered for that
> instance.
>
> If the first sample after this entry becomes active is less than or equal > to mteTriggerThresholdFalling and mteTriggerThresholdStartup
> is equal to 'falling' or 'risingOrFalling', then one > mteTriggerThresholdRisingEvent is triggered for that instance." >
>
> <Snip>
>
> In my opinion this should be changed to the description given below >
>
> Description -:
> "The event that may be triggered when this entry is first set to > 'active' and a new instance of the object at mteTriggerValueID is found. >
>
> If the first sample after this  instance becomes active is greater > than or equal to
> mteTriggerThresholdRising and mteTriggerThresholdStartup is equal to > 'rising' or 'risingOrFalling', then one
> mteTriggerThresholdRisingEvent is triggered for that instance.
>
> If the first sample after this entry becomes active is less than or equal > to mteTriggerThresholdFalling and  mteTriggerThresholdStartup
> is equal to 'Falling' or 'risingOrFalling', then one > mteTriggerThresholdFallingEvent is triggered for that > instance."
>  
> Thanx
> Jaya
>  

> > > --=====================_507605848==_.ALT-- > > From owner-disman@dorothy.peer.com Fri Jul 7 18:58:52 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 SAA15045 for ; Fri, 7 Jul 2000 18:58:52 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e67Mw9Z02442; Fri, 7 Jul 2000 17:58:09 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA09741 for disman-list; Fri, 7 Jul 2000 15:56:47 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA09735 for disman@dorothy.bmc.com; Fri, 7 Jul 2000 15:56:43 -0700 (PDT) Date: Fri, 7 Jul 2000 15:56:43 -0700 (PDT) From: Randy Presuhn Message-Id: <200007072256.PAA09735@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: RE: reminder: disman docs for "proposed" 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: <4.1.20000703114438.00a10d20@sigma.cisco.com> > Date: Mon, 03 Jul 2000 12:07:12 -0700 > To: Randy Presuhn , bwijnen@lucent.com, > rpresuhn@dorothy.bmc.com > From: "Ramanathan R. Kavasseri" > Subject: RE: reminder: disman docs for "proposed" > Cc: Disman@dorothy.bmc.com > In-Reply-To: <200006081909.MAA19062@Dorothy.Bmc.Com> > List-Id: IETF disman Working Group mailing list > > > At 12:09 PM 6/8/00 -0700, Randy Presuhn wrote: > > > >Hi - > > > >> Message-ID: > ><2413FED0DFE6D111B3F90008C7FA61FB07992DF8@nl0006exch002u.nl.lucent.com> > >> From: "Wijnen, Bert (Bert)" > >> To: ramk@cisco.com, Randy Presuhn > >> Cc: Disman@dorothy.peer.com > >> Subject: RE: reminder: disman docs for "proposed" > >> Date: Thu, 8 Jun 2000 13:46:07 +0200 > >> List-Id: IETF disman Working Group mailing list > >... > >> Before I do the IETF Last Call, I would indeed want to see > >> the SMIv2 errors fixed. Other typo fixes can go along with > >> them, but they can also be done at a later time. > >> I would also prefer to fix SMI compile warnings if possible. > >... > > > >This is fine with me. In addition to the fixes Frank has > >identified (which are fine with me), here are the other typos > >and potential IETF last-call issues that I've become aware of: > > > > [...snipped out other items which I've done already...] > > >technical issue, discussed at WG meetings but not reflected > >in document: > >18) draft-ietf-disman-notif-log-mib-16.txt> pages 4/5 > > Heirarchically structured log names have been repeatedly > > shown to have subtle pitfalls. The approach the draft > > recommends can produce surprises when the first subid of > > the second index looks like punctuation, etc. For example, > > with { nlmLogName, nlmLogIndex, nlmLogVariableIndex > > }, nlmLogIndex could have the same value as "-", and > > nlmLogVariableIndex could match a particular subgroup > > name, thus (inappropriately) granting access > > Alas, Pittsburgh will be the first time I attend a disman WG meeting :-( > So I'm unaware of what was the agreed upon change. Can someone > send the proposed change to me? I suggest the following change: old: The Notification Log MIB has the notion of a "named log." By using old: hierarchically structured log names and view-based access control old: [RFC2575] a network administrator can provide different access for old: different users. When an application creates a named log the security old: credentials of the creator stay associated with that log. old: old: Hierarchically structured names encode groupings of names within the old: name string, starting from the left so that they work well with old: instance-level, view-based access control [RFC2575], for example: old: old: ops ops-admin ops-oper ops-oper-senior ops-oper-junior old: old: Network security managers designing such a naming policy SHOULD use old: punctuation (as in the example) to avoid the problem of a lower level old: name inadvertently running together with the next higher level name. new: The Notification Log MIB has the notion of a "named log." new: By using log names and view-based access control [RFC2575] new: a network administrator can provide different access for new: different users. When an application creates a named log new: the security credentials of the creator stay associated with new: that log. > >editorial omission: > >21) draft-ietf-disman-notif-log-mib-16.txt> page 24: what > > is the condition for notificationLogDateGroup? > > [*] Couldn't follow what was wrong here? ... The current DESCRIPTION is vacuous. It doesn't say what the condition is. The current text says "Conditionally mandatory notification log data." Lacking a statement of what the condition is, this definition is worthless. ------------------------------------------------------- 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 Mon Jul 10 05:51:00 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 FAA01311 for ; Mon, 10 Jul 2000 05:51:00 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e6A9n1Z22722; Mon, 10 Jul 2000 04:49:01 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id CAA04330 for disman-list; Mon, 10 Jul 2000 02:43: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 CAA04325 for ; Mon, 10 Jul 2000 02:43:32 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e6A9i8Z22184 for ; Mon, 10 Jul 2000 04:44:09 -0500 (CDT) Received: from sunfra.France.Sun.COM ([129.157.188.1]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA22923; Mon, 10 Jul 2000 02:44:08 -0700 (PDT) Received: from sutur.France.Sun.COM (sutur [129.157.203.2]) by sunfra.France.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with ESMTP id LAA04472; Mon, 10 Jul 2000 11:44:06 +0200 (MET DST) Received: from oneman.France.Sun.COM by sutur.France.Sun.COM (8.9.3+Sun/SMI-SVR4) id LAA08993; Mon, 10 Jul 2000 11:44:05 +0200 (MET DST) Received: from france.sun.com (localhost [127.0.0.1]) by oneman.France.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17875; Mon, 10 Jul 2000 11:44:09 +0200 (MEST) Message-ID: <39699AE9.8D6E62C5@france.sun.com> Date: Mon, 10 Jul 2000 11:44:09 +0200 From: Eamonn McManus Organization: Sun Microsystems, France X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) MIME-Version: 1.0 To: Juergen Schoenwaelder CC: disman@dorothy.peer.com Subject: Re: draft-ietf-disman-script-mib-v2-01.txt References: <200007071614.SAA18296@henkell.ibr.cs.tu-bs.de> 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 CAA04326 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Some small things in the Script MIB draft just posted: * Description of smLaunchScriptName: "this objects" should be "this object" (this typo was already in RFC2592). * Description of smLaunchAdminStatus (autostart): "indicates that a script is being started automatically" sounds a bit strange. "indicates that the associated script should be started automatically", perhaps? Also, it might be useful to mention explicitly that this is useful for scripts that are to be launched on system start-up. * Description of smLaunchError: "must first clear the error message to a launch a script is started" -- garbled sentence. * Description of smRunError: "if the script terminates in an abnormally". Should be "...terminates abnormally" (this typo was already in RFC2592). * Section 7.6, "Launching a script": "A manager can also try to guess an unused value for smRunIndex if he wants to start script in a single transaction". Should be "it", not "he" (also in following sentence), and should be "a script". (This was already in RFC2592.) * Section 7.10, "Removing a Launch Button": "running script" should be "running scripts". Éamonn From owner-disman@dorothy.peer.com Mon Jul 10 13:07:42 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 NAA17472 for ; Mon, 10 Jul 2000 13:07:41 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e6AH4DZ00088; Mon, 10 Jul 2000 12:04:14 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA08331 for disman-list; Mon, 10 Jul 2000 10:02:00 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA08325; Mon, 10 Jul 2000 10:01:56 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e6AH2XZ29798; Mon, 10 Jul 2000 12:02:33 -0500 (CDT) Received: from ramk-pc.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 SMTP id KAA13716; Mon, 10 Jul 2000 10:02:33 -0700 (PDT) Message-Id: <4.1.20000710095958.00a2ae70@sigma.cisco.com> X-Sender: ramk@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 10 Jul 2000 10:02:29 -0700 To: Randy Presuhn , disman@dorothy.peer.com From: Ramanathan Kavasseri Subject: RE: reminder: disman docs for "proposed" In-Reply-To: <200007072256.PAA09735@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id KAA08326 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit At 03:56 PM 7/7/00 -0700, Randy Presuhn wrote: >> >editorial omission: >> >21) draft-ietf-disman-notif-log-mib-16.txt> page 24: what >> > is the condition for notificationLogDateGroup? >> >> [*] Couldn't follow what was wrong here? >... > >The current DESCRIPTION is vacuous. It doesn't say what the >condition is. The current text says "Conditionally mandatory >notification log data." Lacking a statement of what the >condition is, this definition is worthless. I've changed the DESCRIPTION as shown below, to include the condition... notificationLogDateGroup OBJECT-GROUP OBJECTS { nlmLogDateAndTime } STATUS current DESCRIPTION "Conditionally mandatory notification log data. This group is mandatory on systems that keep wall clock date and time and should not be implemented on systems that do not have a wall clock date." ::= { notificationLogMIBGroups 4 } Thanks for the speedy response, 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 Mon Jul 10 14:19: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 OAA21172 for ; Mon, 10 Jul 2000 14:19:51 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e6AIIJZ13384; Mon, 10 Jul 2000 13:18:20 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA08872 for disman-list; Mon, 10 Jul 2000 11:16:21 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA08867 for ; Mon, 10 Jul 2000 11:16:16 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e6AIGrZ13203 for ; Mon, 10 Jul 2000 13:16:54 -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 OAA21050; Mon, 10 Jul 2000 14:16:58 -0400 (EDT) Message-Id: <200007101816.OAA21050@ietf.org> To: IETF-Announce: ; Cc: disman@dorothy.peer.com From: The IESG SUBJECT: Last Call: Notification Log MIB to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 10 Jul 2000 14:16:57 -0400 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list The IESG has received a request from the Distributed Management Working Group to consider Notification Log MIB as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by July 24, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-disman-notif-log-mib-16.txt From owner-disman@dorothy.peer.com Mon Jul 10 14:32: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 OAA22027 for ; Mon, 10 Jul 2000 14:32:20 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e6AIUCZ15915; Mon, 10 Jul 2000 13:30:12 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA09030 for disman-list; Mon, 10 Jul 2000 11:28:51 -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 LAA09022 for ; Mon, 10 Jul 2000 11:28:47 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e6AITJZ15575 for ; Mon, 10 Jul 2000 13:29:22 -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 OAA21775; Mon, 10 Jul 2000 14:29:24 -0400 (EDT) Message-Id: <200007101829.OAA21775@ietf.org> To: IETF-Announce: ; Cc: disman@dorothy.peer.com From: The IESG SUBJECT: Last Call: Event MIB to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 10 Jul 2000 14:29:24 -0400 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list The IESG has received a request from the Distributed Management Working Group to consider Event MIB as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by July 24, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-disman-event-mib-10.txt From owner-disman@dorothy.peer.com Mon Jul 10 14:46:21 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 OAA22713 for ; Mon, 10 Jul 2000 14:46:18 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e6AIhtZ18968; Mon, 10 Jul 2000 13:43:56 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA09305 for disman-list; Mon, 10 Jul 2000 11:42: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 LAA09300 for ; Mon, 10 Jul 2000 11:42:50 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e6AIhRZ18817 for ; Mon, 10 Jul 2000 13:43:27 -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 OAA22582; Mon, 10 Jul 2000 14:43:28 -0400 (EDT) Message-Id: <200007101843.OAA22582@ietf.org> To: IETF-Announce: ; Cc: disman@dorothy.peer.com From: The IESG SUBJECT: Last Call: Distributed Management Expression MIB to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 10 Jul 2000 14:43:28 -0400 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list The IESG has received a request from the Distributed Management Working Group to consider Distributed Management Expression MIB as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by July 24, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-disman-express-mib-12.txt From owner-disman@dorothy.peer.com Mon Jul 10 18:10: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 SAA29905 for ; Mon, 10 Jul 2000 18:10:18 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e6AM8lZ29724; Mon, 10 Jul 2000 17:08:48 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA13728 for disman-list; Mon, 10 Jul 2000 15:07:30 -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 PAA13722 for ; Mon, 10 Jul 2000 15:07:23 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e6AM80Z29579 for ; Mon, 10 Jul 2000 17:08:00 -0500 (CDT) Received: from ramk-pc.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 SMTP id PAA07960 for ; Mon, 10 Jul 2000 15:08:04 -0700 (PDT) Message-Id: <4.1.20000710150446.00ab07a0@sigma.cisco.com> X-Sender: ramk@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 10 Jul 2000 15:07:53 -0700 To: disman@dorothy.peer.com From: Ramanathan Kavasseri Subject: Does anyone have the dates for the disman wg meeting at Pittsburgh? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Can someone tell me which day the disman wg meeting will be held at the Pittsburgh IETF? Couldn't find it on the ietf website (www.ietf.org/meetings/IETF-48.html). Thanks, Ram From owner-disman@dorothy.peer.com Mon Jul 10 18:40:46 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 SAA00911 for ; Mon, 10 Jul 2000 18:40:46 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e6AMdOZ04396; Mon, 10 Jul 2000 17:39:24 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA14572 for disman-list; Mon, 10 Jul 2000 15:38:27 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA14566 for disman@dorothy.bmc.com; Mon, 10 Jul 2000 15:38:24 -0700 (PDT) Date: Mon, 10 Jul 2000 15:38:24 -0700 (PDT) From: Randy Presuhn Message-Id: <200007102238.PAA14566@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Re: Does anyone have the dates for the disman wg meeting at Pittsburgh? 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: <4.1.20000710150446.00ab07a0@sigma.cisco.com> > Date: Mon, 10 Jul 2000 15:07:53 -0700 > To: disman@dorothy.bmc.com > From: Ramanathan Kavasseri > Subject: Does anyone have the dates for the disman wg meeting at > Pittsburgh? > List-Id: IETF disman Working Group mailing list > > Can someone tell me which day the disman wg meeting will be held at the > Pittsburgh IETF? ... Our request for a meeting slot has been approved by the A-D, but I have not yet seen a specific time slot assignment from the secretariat. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-disman@dorothy.peer.com Tue Jul 11 06:36:05 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 GAA24075 for ; Tue, 11 Jul 2000 06:36:04 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e6BAXiZ21904; Tue, 11 Jul 2000 05:33:44 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id DAA18901 for disman-list; Tue, 11 Jul 2000 03:29:17 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA18892 for ; Tue, 11 Jul 2000 03:29:05 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e6BATZZ21442 for ; Tue, 11 Jul 2000 05:29:41 -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 GAA23215; Tue, 11 Jul 2000 06:29:39 -0400 (EDT) Message-Id: <200007111029.GAA23215@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@dorothy.peer.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-script-mib-v2-01.txt Date: Tue, 11 Jul 2000 06:29:39 -0400 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Definitions of Managed Objects for the Delegation of Management Scripts Author(s) : D. Levi, J. Schoenwaelder Filename : draft-ietf-disman-script-mib-v2-01.txt Pages : 55 Date : 10-Jul-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-script-mib-v2-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-script-mib-v2-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-script-mib-v2-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000710151047.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-script-mib-v2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-script-mib-v2-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000710151047.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-disman@dorothy.peer.com Tue Jul 11 06:39:19 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 GAA24074 for ; Tue, 11 Jul 2000 06:36:04 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e6BAXfZ21901; Tue, 11 Jul 2000 05:33:42 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id DAA18900 for disman-list; Tue, 11 Jul 2000 03:29: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 DAA18889 for ; Tue, 11 Jul 2000 03:29:05 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e6BATZZ21440 for ; Tue, 11 Jul 2000 05:29:41 -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 GAA23201; Tue, 11 Jul 2000 06:29:34 -0400 (EDT) Message-Id: <200007111029.GAA23201@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@dorothy.peer.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-schedule-mib-v2-01.txt Date: Tue, 11 Jul 2000 06:29:34 -0400 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Definitions of Managed Objects for Scheduling Management Operations Author(s) : D. Levi, J. Schoenwaelder Filename : draft-ietf-disman-schedule-mib-v2-01.txt Pages : 27 Date : 10-Jul-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to schedule management operations periodically or at specified dates and times. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-schedule-mib-v2-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-schedule-mib-v2-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-schedule-mib-v2-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000710151029.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-schedule-mib-v2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-schedule-mib-v2-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000710151029.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-disman@dorothy.peer.com Wed Jul 12 04:50:06 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 EAA13915 for ; Wed, 12 Jul 2000 04:50:06 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e6C8hXZ11894; Wed, 12 Jul 2000 03:43:33 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id BAA27098 for disman-list; Wed, 12 Jul 2000 01:40: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 BAA27093 for ; Wed, 12 Jul 2000 01:40:47 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e6C8fKZ11683 for ; Wed, 12 Jul 2000 03:41:20 -0500 (CDT) Received: from ramk-95.cisco.com (ramk-dsl4.cisco.com [10.19.11.157]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id BAA04277; Wed, 12 Jul 2000 01:41:24 -0700 (PDT) Message-Id: <4.1.20000712014308.00a9fe10@sigma.cisco.com> X-Sender: ramk@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 12 Jul 2000 01:43:21 -0700 To: "Yosief Sium (ETO)" From: "Ramanathan R. Kavasseri" Subject: Re: Question regarding Notification Log MIB Cc: disman@dorothy.peer.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list At 09:24 AM 7/12/00 +0200, Yosief Sium (ETO) wrote: >Hi Ramanathan Kavasseri, > >I have a little question regarding Notification Log MIB (Draft from march >2000) of which you are the contact person. My questions are in example 3.3 >on page 7. > >In the example, you have nlmConfigLogFilterName.5."links" = "link status" > >According to the mib definition, nlmConfigLogTable is indexed only by log >name, i.e. "links" in the above. Where does then the number 5 in the above >OID come from? "5" is the length of the string "links". The index is a variable-length string. The following lines from rfc2578, Section 7.7, indicate how the instance identifier is formed: The syntax of the objects in the INDEX clause indicate how to form the instance-identifier: (1) integer-valued: a single sub-identifier taking the integer value (this works only for non-negative integers); (2) string-valued, fixed-length strings (or variable-length preceded by the IMPLIED keyword): `n' sub-identifiers, where `n' is the length of the string (each octet of the string is encoded in a separate sub-identifier); (3) string-valued, variable-length strings (not preceded by the IMPLIED keyword): `n+1' sub-identifiers, where `n' is the length of the string (the first sub-identifier is `n' itself, following this, each octet of the string is encoded in a separate sub-identifier); Please cc such questions to the disman mailing list in the future - you'll get a faster response that way (plus others may have the same questions)... Thanks, Ram >you have too snmpNotifyFilterMask.11."link status".1.3.6.1.6.3.1.1.5.3 = ' 'H > >snmpNotifyFilterMask, which is a member of snmpNotifyFilterTable, is indexed >by FilterName(ProfileName) and subtree. My question is again, where does the >number 11 come from? > >I appreciate the usage of examples as they make the MIBs more understable >than the definitions. > >Thanks in advance! > >Regards! >Yosief Sium > > > > From owner-disman@dorothy.peer.com Wed Jul 12 07:23:50 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 HAA16527 for ; Wed, 12 Jul 2000 07:23:49 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e6CBLvZ28086; Wed, 12 Jul 2000 06:21:57 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA27498 for disman-list; Wed, 12 Jul 2000 04:15:56 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA27493 for ; Wed, 12 Jul 2000 04:15:52 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e6CBGSZ27606 for ; Wed, 12 Jul 2000 06:16:29 -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 HAA16360; Wed, 12 Jul 2000 07:16:29 -0400 (EDT) Message-Id: <200007121116.HAA16360@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: disman@dorothy.peer.com From: The IESG Subject: Protocol Action: Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations to Proposed Standard Date: Wed, 12 Jul 2000 07:16:28 -0400 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list The IESG has approved the Internet-Draft 'Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations' 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 Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperibility. This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. When managing a network it is useful to be able to initiate and retrieve the results of ping or traceroute operations when performed at a remote host. A Lookup capability is defined in order to enable resolving of either an IP address to an DNS name or an DNS name to an IP address at a remote host. Working Group Summary The WG has had quite a set of debates about these documents. But this final revision of the document has consensus of the WG. Protocol Quality This memo has been reviewed for the IESG by Bert Wijnen and David Partain. From owner-disman@dorothy.peer.com Wed Jul 12 16:15:00 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 QAA12138 for ; Wed, 12 Jul 2000 16:14:59 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e6CKBwZ09080; Wed, 12 Jul 2000 15:11:58 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA00297 for disman-list; Wed, 12 Jul 2000 13:08:24 -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 NAA00292 for ; Wed, 12 Jul 2000 13:08:20 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e6CK8uZ08479 for ; Wed, 12 Jul 2000 15:08:56 -0500 (CDT) Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Wed, 12 Jul 2000 16:04:46 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 12 Jul 2000 16:04:42 -0400 Message-ID: <6DDA62170439D31185750000F80826AC031CC7EC@zmerd004.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.peer.com Subject: notification log MIB and Opaque type Date: Wed, 12 Jul 2000 16:04:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEC3C.6AC4A1CC" 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_01BFEC3C.6AC4A1CC Content-Type: text/plain; charset="iso-8859-1" hi I'm trying not to spew html, but apologies if I am. I suspect the Opaque type was included in the data types for completeness, but there are some pretty prominent compilers out there that don't support the type. What's the correct way to handle this? Convert it to an octet string, leave it out, or beat up on the vendor? Sharon Chisholm Preside Management Nortel Networks Ottawa, Ontario ------_=_NextPart_001_01BFEC3C.6AC4A1CC Content-Type: text/html; charset="iso-8859-1" notification log MIB and Opaque type

hi

I'm trying not to spew html, but apologies if I am.

I suspect the Opaque type was included in the data types
for completeness, but there are some pretty prominent compilers
out there that don't support the type.

What's the correct way to handle this?  Convert it to an octet
string, leave it out, or beat up on the vendor?  

Sharon Chisholm
Preside Management
Nortel Networks
Ottawa, Ontario

------_=_NextPart_001_01BFEC3C.6AC4A1CC-- From owner-disman@dorothy.peer.com Wed Jul 12 17:32: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 RAA15813 for ; Wed, 12 Jul 2000 17:32:23 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e6CLUQZ24570; Wed, 12 Jul 2000 16:30:27 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA03465 for disman-list; Wed, 12 Jul 2000 14:29:13 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA03459 for disman@dorothy.bmc.com; Wed, 12 Jul 2000 14:29:10 -0700 (PDT) Date: Wed, 12 Jul 2000 14:29:10 -0700 (PDT) From: Randy Presuhn Message-Id: <200007122129.OAA03459@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Re: notification log MIB and Opaque type 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: <6DDA62170439D31185750000F80826AC031CC7EC@zmerd004.ca.nortel.com> > From: "Sharon Chisholm" > To: disman@dorothy.bmc.com > Subject: notification log MIB and Opaque type > Date: Wed, 12 Jul 2000 16:04:26 -0400 > List-Id: IETF disman Working Group mailing list ... > I suspect the Opaque type was included in the data types > for completeness, but there are some pretty prominent compilers > out there that don't support the type. > > What's the correct way to handle this? Convert it to an octet > string, leave it out, or beat up on the vendor? ... Despite the disparaging words in RFC 2578 clause 7.1.9, Opaque is clearly one of the SMI data types. A product that can't deal with it is broken, in my opinion. How you work around this will depend on the tools you're using and what you're doing with their output. ------------------------------------------------------- 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 Jul 12 18:50:40 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 SAA17644 for ; Wed, 12 Jul 2000 18:50:40 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e6CMmDZ09162; Wed, 12 Jul 2000 17:48:14 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA05255 for disman-list; Wed, 12 Jul 2000 15:46:35 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA05248 for disman@dorothy.bmc.com; Wed, 12 Jul 2000 15:46:32 -0700 (PDT) Date: Wed, 12 Jul 2000 15:46:32 -0700 (PDT) From: Randy Presuhn Message-Id: <200007122246.PAA05248@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: disman slot in Pittsburgh 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 - The time slot for the disman working group is still not known. I expect it to be nailed down by July 17. I will forward the information to this mailing list as soon as I have it. ------------------------------------------------------- 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 Mon Jul 17 15:23: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 PAA28745 for ; Mon, 17 Jul 2000 15:23:41 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e6HJJTZ12522; Mon, 17 Jul 2000 14:19:34 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA02601 for disman-list; Mon, 17 Jul 2000 12:16: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 MAA02592 for ; Mon, 17 Jul 2000 12:16:29 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e6HJH1Z12105 for ; Mon, 17 Jul 2000 14:17:01 -0500 (CDT) Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Mon, 17 Jul 2000 14:25:13 -0400 Received: by ZRTPD004 with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jul 2000 14:25:12 -0400 Message-ID: <6DDA62170439D31185750000F80826AC032A2F2F@zmerd004.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.peer.com Subject: Distributed Active Alarms Date: Mon, 17 Jul 2000 14:25:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF01C.58941FDA" 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_01BFF01C.58941FDA Content-Type: text/plain; charset="iso-8859-1" hi 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. Sharon Chisholm Preside Management Nortel Networks Ottawa, Ontario ---------------------------------------------------------------------------- --- Sharon Chisholm Nortel Networks July 17, 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. 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, 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 } 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 { 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, 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. References [1] Stewart, B, "Notification Log MIB, draft 12, October 1999 ------_=_NextPart_001_01BFF01C.58941FDA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Distributed Active Alarms

hi

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.

Sharon Chisholm
Preside Management
Nortel Networks
Ottawa, Ontario

---------------------------------------------------------------= ----------------

        =         =         =         =         =         Sharon = Chisholm
        =         =         =         =         =         Nortel = Networks
        =         =         =         =         =         July 17, = 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.

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

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,
    = 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 = }

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       {  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,
        =         = activeAlarmContextName,
        =         activeAlarmVariables,
        =         = activeAlarmNotificationID,
        =         activeAlarmLogIndex,
        =         = activeAlarmVariableIndex,
        =         = activeAlarmVariableID,
        =         = activeAlarmVariableValueType,
        =         = activeAlarmVariableCounter32Val,
        =         = activeAlarmVariableUnsigned32Val,
        =         = activeAlarmVariableTimeTicksVal,
        =         = activeAlarmVariableInteger32Val,
        =         = activeAlarmVariableOctetStringVal,
        =         = activeAlarmVariableIpAddressVal,
        =         = activeAlarmVariableOidVal,
        =         = activeAlarmVariableCounter64Val,
        =         = activeAlarmVariableOpaqueVal     =         
         &nbs= p;              = }
         =           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
       =20
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         = |
        =         |__________________________________________________|  =

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


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

        =          = _____________________________________________
        =         | = nlmLogTable          &= nbsp;           &= nbsp;          = |   
        =         |---------------------------------------------|  &nbs= p;
        =         | nlmLogIndex = |  = alarm           &= nbsp;            = |   
        =         |---------------------------------------------|  &nbs= p;
        =         |      = 1      | acmeWidgetTemperatureCritical = |
        =         |      = 2      | = bgpBackwardTransition         = |
        =         |      = 3      | = acmeWidgetTemperatureNormal   |
        =         |_____________________________________________| 


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

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

        =          = _____________________________________________
        =         | = nlmLogTable          &= nbsp;           &= nbsp;          = |   
        =         |---------------------------------------------|  &nbs= p;
        =         | nlmLogIndex = |  = alarm           &= nbsp;            = |   
        =         |---------------------------------------------|  &nbs= p;
        =         |      = 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. References
        [1] Stewart, = B, "Notification Log MIB, draft 12, October 1999   =        
       =20

------_=_NextPart_001_01BFF01C.58941FDA-- From owner-disman@dorothy.peer.com Wed Jul 19 15:06:52 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 PAA21099 for ; Wed, 19 Jul 2000 15:06:47 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e6JJ4EZ26507; Wed, 19 Jul 2000 14:04:19 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA08508 for disman-list; Wed, 19 Jul 2000 11:56:19 -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 LAA08503 for ; Wed, 19 Jul 2000 11:56:15 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e6JIukZ24981 for ; Wed, 19 Jul 2000 13:56:46 -0500 (CDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20845 for ; Wed, 19 Jul 2000 11:56:37 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.89.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id LAA24027 for ; Wed, 19 Jul 2000 11:56:27 -0700 (PDT) Received: from sunfish2 (sunfish2.Eng.Sun.COM [129.146.81.210]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e6JIuQI189106 for ; Wed, 19 Jul 2000 11:56:26 -0700 (PDT) Message-Id: <200007191856.e6JIuQI189106@jurassic.eng.sun.com> Date: Wed, 19 Jul 2000 11:56:26 -0700 (PDT) From: "David M Fishman(SunUP-HA)" Reply-To: "David M Fishman(SunUP-HA)" Subject: DISMAN schedule at pittsburgh IETF? To: disman@dorothy.peer.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Qty/w4OQwP8S+vlrcJ980g== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Any word on the DISMAN discussions at IETF? They say the schedule was to be posted by 48 hours ago, but it's now (nearly) 10 days old. David M. Fishman Manager, Application Strategies tel. 650-786-8811 fax 650-786-8890 MS MPK17-114 david.m.fishman@sun.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "No, the APPLICATION is the computer..." -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= (NOTE: There is more than one David Fishman at Sun. My email is david.m.fishman@sun.com. PLEASE DO NOT send email to david.fishman@sun.com) From owner-disman@dorothy.peer.com Thu Jul 20 17:47:34 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 RAA23250 for ; Thu, 20 Jul 2000 17:47:34 -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 e6KLitP23056; Thu, 20 Jul 2000 16:44:56 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA13414 for disman-list; Thu, 20 Jul 2000 14:40:24 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA13408 for disman@dorothy.bmc.com; Thu, 20 Jul 2000 14:40:21 -0700 (PDT) Date: Thu, 20 Jul 2000 14:40:21 -0700 (PDT) From: Randy Presuhn Message-Id: <200007202140.OAA13408@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Disman session in Pittsburg 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 secretariat has put the disman working group's session in the 13:00-15:00 slot on Monday, July 31. ------------------------------------------------------- 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 Jul 21 10:14: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 KAA14606 for ; Fri, 21 Jul 2000 10:14: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 e6LEBrq16871; Fri, 21 Jul 2000 09:11:54 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA15188 for disman-list; Fri, 21 Jul 2000 07:09:58 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA15183 for ; Fri, 21 Jul 2000 07:09:54 -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 e6LEAN616508 for ; Fri, 21 Jul 2000 09:10:23 -0500 (CDT) Received: from [129.250.38.56] (helo=dfw-mx2.email.verio.net) by dfw-smtpout3.email.verio.net with esmtp (Exim 3.12 #7) id 13FdVb-000498-00 for disman@dorothy.peer.com; Fri, 21 Jul 2000 14:10:35 +0000 Received: from [206.176.136.115] (helo=cwk) by dfw-mx2.email.verio.net with smtp (Exim 3.15 #4) id 13FdVa-0005te-00 for disman@dorothy.peer.com; Fri, 21 Jul 2000 14:10:34 +0000 From: "Carl W. Kalbfleisch" To: Subject: FW: I-D ACTION:draft-kalbfleisch-sspmmib-00.txt Date: Fri, 21 Jul 2000 09:10:31 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_002B_01BFF2F3.8510AAE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list This is a multi-part message in MIME format. ------=_NextPart_000_002B_01BFF2F3.8510AAE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Discussions from the RPERFMON BOF in Adielade have taken place on this list previously. At Pittsburgh a further discussion will be held in RMON during RMON's Thursday session. This is the document for discussion during that slot. I just wanted to keep this group in the loop as this discussion should now be moving to RMON... Carl -----Original Message----- From: nsyracus@cnri.reston.va.us [mailto:nsyracus@cnri.reston.va.us]On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, July 20, 2000 5:44 AM To: IETF-Announce: ; Subject: I-D ACTION:draft-kalbfleisch-sspmmib-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definition of Managed Objects for Synthetic Sources for Performance Monitoring algorithms Author(s) : C. Kalbfleisch, R. Cole, D. Romascanu Filename : draft-kalbfleisch-sspmmib-00.txt Pages : 27 Date : 19-Jul-00 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 objects for configuring Synthetic Sources for Performance Monitoring algorithms (SSPM). This memo specifies a MIB module in a manner that is both compliant to the SMIv2, and semantically identical to the peer SMIv1 definitions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kalbfleisch-sspmmib-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kalbfleisch-sspmmib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kalbfleisch-sspmmib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_002B_01BFF2F3.8510AAE0 Content-Type: Message/External-body; name="ATT00017.dat" Content-Disposition: attachment; filename="ATT00017.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20000719141045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kalbfleisch-sspmmib-00.txt ------=_NextPart_000_002B_01BFF2F3.8510AAE0 Content-Type: Message/External-body; name="draft-kalbfleisch-sspmmib-00.txt" Content-Disposition: attachment; filename="draft-kalbfleisch-sspmmib-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20000719141045.I-D@ietf.org> ------=_NextPart_000_002B_01BFF2F3.8510AAE0-- From owner-disman@dorothy.peer.com Fri Jul 21 17:23: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 RAA06380 for ; Fri, 21 Jul 2000 17:23: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 e6LLLti15069; Fri, 21 Jul 2000 16:21:56 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA19086 for disman-list; Fri, 21 Jul 2000 14:19:31 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA19080; Fri, 21 Jul 2000 14:19:28 -0700 (PDT) Date: Fri, 21 Jul 2000 14:19:28 -0700 (PDT) From: Randy Presuhn Message-Id: <200007212119.OAA19080@dorothy.bmc.com> To: ietf-web@ietf.org, scoya@ietf.org Subject: Updates to disman WG charter Cc: bwijnen@lucent.com, disman@dorothy.peer.com, randy@psg.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 - Several updates are needed to the disman WG charter web page. 1) The technical advisor Bob Stewart should be deleted. He has retired, and the ADs have determined that the WG has sufficient expertise to make this position unnecessary. 2) The ftp archive address should be: ftp://amethyst.bmc.com/pub/disman/archives 3) The following three items have been completed, and should be marked "Done": May 99 Submit final versions of Internet-Drafts for Expression, Event and Notification MIB documents for consideration as Proposed Standards. Jun 99 Submit final version of Internet-Draft for Remote Ping, Traceroute, and Lookup Operations using SMIv2 Jul 99 Meeting in Oslo to discuss implementation and deployment experience with Schedule and Script mibs, identify any updates needed to these documents. ------------------------------------------------------- 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 Jul 21 17:31:20 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09105 for ; Fri, 21 Jul 2000 17:31: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 e6LLTDq16288; Fri, 21 Jul 2000 16:29:13 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA19171 for disman-list; Fri, 21 Jul 2000 14:28:29 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA19165 for disman@dorothy.bmc.com; Fri, 21 Jul 2000 14:28:26 -0700 (PDT) Date: Fri, 21 Jul 2000 14:28:26 -0700 (PDT) From: Randy Presuhn Message-Id: <200007212128.OAA19165@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Disman agenda for Pittsburgh (proposed) 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 - Comments and any further additions would be appreciated. I need to get this to the secretariat by 17:00 Eastern Daylight Time on Monday. If additional issues arise before the meeting, please bring them to this mailing list so that meeting attendees can prepare. Proposed Agenda for the Disman working group 48th IETF meeting in Pittsburgh, Pennsylvania, USA Monday, July 31 from 13:00 to 15:00 1. Administrative matters 1.1 introductions 1.2 selection of minute-taker See http://www.ietf.org/instructions/minutes.html 1.3 circulation of sign-up sheet 1.4 Review of Agenda 1.5 Allocation of time 2. Status of Current work 2.1 Script MIB: updates to RFC 2592 2.2 Schedule MIB: updates to RFC 2591 2.3 Notification/Log MIB: IETF last call 2.4 Event MIB: IETF last call 2.5 Expression MIB: IETF last call 2.6 Remote Operations MIB: in RFC editor's queue 3. Other relevant work 3.1 rperfman BOF in Adelaide 3.2 SnmpConf 3.3 RmonMib 4. Technical Discussions See http://www.ietf.org/instructions/slides.html 4.1 closing remaining script/schedule issues Juergen Schoenwaelder, estimated 1/2 hour 5. Charter updates 5.1 completed items 5.2 changes to target dates 5.3 Possible additions to charter 5.3.1 "Script MIB Extensibility" (RFC 2593) 5.3.2 anything else? 6. Wrap-up 6.1 review of action items 6.2 reminders to minute-takers and presenters 6.3 retrieval of sign-up sheet ------------------------------------------------------- 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 Mon Jul 24 13:36:27 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 NAA05582 for ; Mon, 24 Jul 2000 13:36:27 -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 e6OHVvr00886; Mon, 24 Jul 2000 12:32:02 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA00184 for disman-list; Mon, 24 Jul 2000 10:27:29 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA00178 for disman@dorothy.bmc.com; Mon, 24 Jul 2000 10:27:25 -0700 (PDT) Date: Mon, 24 Jul 2000 10:27:25 -0700 (PDT) From: Randy Presuhn Message-Id: <200007241727.KAA00178@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Re: Distributed Active Alarms 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: <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 Mon Jul 24 13:49:03 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 NAA09146 for ; Mon, 24 Jul 2000 13:49:03 -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 e6OHVvh00887; Mon, 24 Jul 2000 12:32:02 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA00209 for disman-list; Mon, 24 Jul 2000 10:31:14 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA00201; Mon, 24 Jul 2000 10:31:10 -0700 (PDT) Date: Mon, 24 Jul 2000 10:31:10 -0700 (PDT) From: Randy Presuhn Message-Id: <200007241731.KAA00201@dorothy.bmc.com> To: agenda@ietf.org Subject: Disman WG agenda for Pittsburgh 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 - Here's the agenda for the disman WG meeting. ------------------------------------------------------- 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. ------------------------------------------------------- Agenda for the Disman working group 48th IETF meeting in Pittsburgh, Pennsylvania, USA Monday, July 31 from 13:00 to 15:00 1. Administrative matters 1.1 introductions 1.2 selection of minute-taker See http://www.ietf.org/instructions/minutes.html 1.3 circulation of sign-up sheet 1.4 Review of Agenda 1.5 Allocation of time 2. Status of Current work 2.1 Script MIB: updates to RFC 2592 2.2 Schedule MIB: updates to RFC 2591 2.3 Notification/Log MIB: IETF last call 2.4 Event MIB: IETF last call 2.5 Expression MIB: IETF last call 2.6 Remote Operations MIB: in RFC editor's queue 3. Other relevant work 3.1 rperfman BOF in Adelaide 3.2 SnmpConf 3.3 RmonMib 4. Technical Discussions See http://www.ietf.org/instructions/slides.html 4.1 closing remaining script/schedule issues Juergen Schoenwaelder, estimated 1/2 hour 4.2 Distributed Active Alarms (Sharon Chisholm) 5. Charter updates 5.1 completed items 5.2 changes to target dates 5.3 Possible additions to charter 5.3.1 "Script MIB Extensibility" (RFC 2593) 5.3.2 anything else? 6. Wrap-up 6.1 review of action items 6.2 reminders to minute-takers and presenters 6.3 retrieval of sign-up sheet -- end of agenda -- From owner-disman@dorothy.peer.com Mon Jul 24 18:12:21 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 SAA24707 for ; Mon, 24 Jul 2000 18:12: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 e6OM0vx23003; Mon, 24 Jul 2000 17:01:01 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA07515 for disman-list; Mon, 24 Jul 2000 14:59:19 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA06918; Mon, 24 Jul 2000 14:58:43 -0700 (PDT) Date: Mon, 24 Jul 2000 14:58:43 -0700 (PDT) From: Randy Presuhn Message-Id: <200007242158.OAA06918@dorothy.bmc.com> To: schishol@nortelnetworks.com Subject: IPR on Distributed Active Alarms 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 Sharon - When you get that reference to the patent on Distributed Active Alarms (patent number or URL), please include Steve Coya (scoya@ietf.org) so that he can update the IESG's IPR pages appropriately. ------------------------------------------------------- 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 Mon Jul 24 22:39: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 WAA00107 for ; Mon, 24 Jul 2000 22:39:47 -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 e6P2bvF26857; Mon, 24 Jul 2000 21:37:57 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id TAA17529 for disman-list; Mon, 24 Jul 2000 19:36: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 TAA17523; Mon, 24 Jul 2000 19:36:14 -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 e6P2ag526790; Mon, 24 Jul 2000 21:36:42 -0500 (CDT) Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Mon, 24 Jul 2000 22:32:12 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 24 Jul 2000 22:30:17 -0400 Message-ID: <6DDA62170439D31185750000F80826AC033BD8D4@zmerd004.ca.nortel.com> From: "Sharon Chisholm" To: Randy Presuhn , disman@dorothy.peer.com Cc: scoya@ietf.org Subject: RE: Distributed Active Alarms Date: Mon, 24 Jul 2000 22:29:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF5E0.2FEDDB60" 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_01BFF5E0.2FEDDB60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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? =20 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. >=20 > 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. >=20 > Please let me know what you think. ... I'll add this to the agenda for the Pittsburgh meeting. Will an internet draft be appearing? =20 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=E9, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- ------_=_NextPart_001_01BFF5E0.2FEDDB60 Content-Type: text/html; charset="iso-8859-1" RE: Distributed Active Alarms

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" <schishol@nortelnetworks.com>
> 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.
 -------------------------------------------------------

------_=_NextPart_001_01BFF5E0.2FEDDB60-- From owner-disman@dorothy.peer.com Tue Jul 25 10:40: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 KAA09229 for ; Tue, 25 Jul 2000 10:40:36 -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 e6PEaK029034; Tue, 25 Jul 2000 09:36:21 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA18805 for disman-list; Tue, 25 Jul 2000 07:34:05 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA18799 for disman@dorothy.bmc.com; Tue, 25 Jul 2000 07:34:02 -0700 (PDT) Date: Tue, 25 Jul 2000 07:34:02 -0700 (PDT) From: Randy Presuhn Message-Id: <200007251434.HAA18799@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: RE: Distributed Active Alarms 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: <6DDA62170439D31185750000F80826AC033BD8D4@zmerd004.ca.nortel.com> > From: "Sharon Chisholm" > To: Randy Presuhn , disman@dorothy.bmc.com > Cc: scoya@ietf.org > Subject: RE: Distributed Active Alarms > Date: Mon, 24 Jul 2000 22:29:41 -0400 ... > 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? Just add the appropriate boilerplate and IPR statements. > 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? =20 RFC 2026 contains some magical incantations that should be included, along with instructions for their use. If your intention is to request that the working group consider making this a work item, it would probably make sense to use the boilerplate for "standards track" documents. > 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. At this time, it would be an individual submission. If there is sufficient interest on this mailing list and at the Pittsburgh meeting, and if our area director approves, we could add this as a work item to our charter. At that point, a draft-ietf-disman-* name would be appropriate. > 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. ... The deadline for I-D submission has passed. We can still talk about whether there is interest in taking this on as a new work item. I'd like to hear what other participants in the WG think. ------------------------------------------------------- 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 Jul 25 10:49:24 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11757 for ; Tue, 25 Jul 2000 10:49: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 e6PEhKi00657; Tue, 25 Jul 2000 09:43:20 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA18909 for disman-list; Tue, 25 Jul 2000 07:42:38 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA18903; Tue, 25 Jul 2000 07:42:34 -0700 (PDT) Date: Tue, 25 Jul 2000 07:42:34 -0700 (PDT) From: Randy Presuhn Message-Id: <200007251442.HAA18903@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: fwd: RE: Distributed Active Alarms Cc: scoya@ietf.org 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 - Here's a message from Steve Coya for the disman list. I've added him to the "posters" file so he can now post to this list without having to subscribe. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- > Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA18465; > Tue, 25 Jul 2000 05:14: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 e6PCFR402831; > Tue, 25 Jul 2000 07:15:27 -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 IAA22010; > Tue, 25 Jul 2000 08:15:38 -0400 (EDT) > Date: Tue, 25 Jul 2000 08:14:23 -0400 (Eastern Daylight Time) > From: Steve Coya > Reply-To: Steve Coya > To: Sharon Chisholm > cc: Randy Presuhn , disman@dorothy.bmc.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 IAA22010 > Content-Transfer-Encoding: 8bit > X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id FAA18466 > > > Hi Sharon, > > 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? > > I'm assuming the above question is for Randy :-) > > >>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? > > Yes, though much depends on which option you choose, and your intention > with respect to changes and/or derrivitive works. > > Assuming you wish to retain change control, including contact information > for licensing (assuming you intend to offer this) in the I-D is a good > idea. > > > >>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. > > You did just right. It is up to the WG Chair as to whether your document > is to be a WG Internet-Draft. And it is up to each WG chair to make this > decision based on the IPR statements (some will not allow any submissions > encumbered, others will). Of course, if you chose option three, the point > is moot. > > > >>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. > > You did miss thre deadline. Anything you send prior to July 31 will NOT be > processed as an Internet-Draft, but you certainly may resubmit beginning > July 31 (though announcements will not be made until August 7). > > > > > >>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 Jul 25 11:30:42 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 LAA27761 for ; Tue, 25 Jul 2000 11:30:39 -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 e6PFLgX09229; Tue, 25 Jul 2000 10:21:42 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA19173 for disman-list; Tue, 25 Jul 2000 08:20:56 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA19168 for ; Tue, 25 Jul 2000 08: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 e6PFLI709140 for ; Tue, 25 Jul 2000 10:21:19 -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 RAA28915; Tue, 25 Jul 2000 17:21:28 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA01448; Tue, 25 Jul 2000 17:21:28 +0200 Date: Tue, 25 Jul 2000 17:21:28 +0200 Message-Id: <200007251521.RAA01448@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: eamonn.mcmanus@france.sun.com CC: disman@dorothy.peer.com In-reply-to: <39699AE9.8D6E62C5@france.sun.com> (message from Eamonn McManus on Mon, 10 Jul 2000 11:44:09 +0200) Subject: Re: draft-ietf-disman-script-mib-v2-01.txt References: <200007071614.SAA18296@henkell.ibr.cs.tu-bs.de> <39699AE9.8D6E62C5@france.sun.com> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Eamonn McManus writes: Eamonn> Some small things in the Script MIB draft just posted: Eamonn> * Description of smLaunchScriptName: "this objects" should be Eamonn> "this object" (this typo was already in RFC2592). Fixed in my nroff sources. Eamonn> * Description of smLaunchAdminStatus (autostart): "indicates Eamonn> that a script is being started automatically" sounds a bit Eamonn> strange. "indicates that the associated script should be Eamonn> started automatically", perhaps? Also, it might be useful to Eamonn> mention explicitly that this is useful for scripts that are to Eamonn> be launched on system start-up. Cleaned up the wordings and added additional text as suggested. Eamonn> * Description of smLaunchError: "must first clear the error Eamonn> message to a launch a script is started" -- garbled sentence. Fixed in my nroff sources. Eamonn> * Description of smRunError: "if the script terminates in an Eamonn> abnormally". Should be "...terminates abnormally" (this typo Eamonn> was already in RFC2592). Fixed in my nroff sources. Eamonn> * Section 7.6, "Launching a script": "A manager can also try Eamonn> to guess an unused value for smRunIndex if he wants to start Eamonn> script in a single transaction". Should be "it", not "he" Eamonn> (also in following sentence), and should be "a script". (This Eamonn> was already in RFC2592.) Fixed in my nroff sources. Eamonn> * Section 7.10, "Removing a Launch Button": "running script" Eamonn> should be "running scripts". Fixed in my nroff sources. Thanks for carefully reading the nevest revision. /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 Jul 25 20:27: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 UAA04900 for ; Tue, 25 Jul 2000 20:27: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 e6Q0Lgn16805; Tue, 25 Jul 2000 19:21:42 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA25797 for disman-list; Tue, 25 Jul 2000 17:21:00 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA25787; Tue, 25 Jul 2000 17:20:57 -0700 (PDT) Date: Tue, 25 Jul 2000 17:20:57 -0700 (PDT) From: Randy Presuhn Message-Id: <200007260020.RAA25787@dorothy.bmc.com> To: iesg@ietf.org Subject: Re: Last Call: Distributed Management Expression MIB to Proposed Standard Cc: bwijnen@lucent.com, 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: <200007101843.OAA22582@ietf.org> > To: IETF-Announce: ; > Cc: disman@dorothy.bmc.com > From: The IESG > SUBJECT: Last Call: Distributed Management Expression MIB to Proposed > Standard > Reply-to: iesg@ietf.org > Date: Mon, 10 Jul 2000 14:43:28 -0400 ... > The IESG has received a request from the Distributed Management Working > Group to consider Distributed Management Expression MIB > as a Proposed Standard. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by July 24, 2000. ... I haven't seen any IETF last call comments on this document on the ietf@ietf.org list or disman WG mailing list. Bert: is this ready to go to 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 Tue Jul 25 20:27:37 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 UAA05033 for ; Tue, 25 Jul 2000 20:27:36 -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 e6Q0IPQ16412; Tue, 25 Jul 2000 19:18:25 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA25750 for disman-list; Tue, 25 Jul 2000 17:15:39 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA25744; Tue, 25 Jul 2000 17:15:36 -0700 (PDT) Date: Tue, 25 Jul 2000 17:15:36 -0700 (PDT) From: Randy Presuhn Message-Id: <200007260015.RAA25744@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Re: Last Call: Notification Log MIB to Proposed Standard Cc: bwijnen@lucent.com, iesg@ietf.org 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: <200007101816.OAA21050@ietf.org> > To: IETF-Announce: ; > Cc: disman@dorothy.bmc.com > From: The IESG > SUBJECT: Last Call: Notification Log MIB to Proposed Standard > Reply-to: iesg@ietf.org > Date: Mon, 10 Jul 2000 14:16:57 -0400 > List-Id: IETF disman Working Group mailing list ... > The IESG has received a request from the Distributed Management Working > Group to consider Notification Log MIB > as a Proposed Standard. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by July 24, 2000. ... I have seen no comments on this draft on ietf@ietf.org list. The editor is aware of some minor typos that need to be fixed, there was no adverse reaction to these on the disman WG mailing list. Bert: were any issues raised on the IESG list? I think it's ready to go to the RFC editor's queue, assuming that Ram can fix the typos during the publication process. ------------------------------------------------------- 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 Jul 25 20:43:46 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 UAA08728 for ; Tue, 25 Jul 2000 20:43: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 e6Q0JbB16554; Tue, 25 Jul 2000 19:19:37 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA25777 for disman-list; Tue, 25 Jul 2000 17:18:56 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA25771; Tue, 25 Jul 2000 17:18:52 -0700 (PDT) Date: Tue, 25 Jul 2000 17:18:52 -0700 (PDT) From: Randy Presuhn Message-Id: <200007260018.RAA25771@dorothy.bmc.com> To: iesg@ietf.org Subject: Re: Last Call: Event MIB to Proposed Standard Cc: bwijnen@lucent.com, 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: <200007101829.OAA21775@ietf.org> > To: IETF-Announce: ; > Cc: disman@dorothy.bmc.com > From: The IESG > SUBJECT: Last Call: Event MIB to Proposed Standard > Reply-to: iesg@ietf.org > Date: Mon, 10 Jul 2000 14:29:24 -0400 ... > The IESG has received a request from the Distributed Management Working > Group to consider Event MIB as a > Proposed Standard. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by July 24, 2000. ... I have seen no IETF last call comments on this document on the ietf@ietf.org list nor on the disman WG mailing list. Bert: were any issues raised on the iesg@ietf.org list? If not, I think it's ready to go into the RFC editor's queue. ------------------------------------------------------- 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 Jul 26 08:18:48 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 IAA24471 for ; Wed, 26 Jul 2000 08:18:47 -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 e6QCFtW07288; Wed, 26 Jul 2000 07:16:00 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA26969 for disman-list; Wed, 26 Jul 2000 05:12:41 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA26963; Wed, 26 Jul 2000 05:12:37 -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 e6QCD5P06810; Wed, 26 Jul 2000 07:13:05 -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 IAA23011; Wed, 26 Jul 2000 08:13:22 -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 IAA22923; Wed, 26 Jul 2000 08:13:17 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id <303P4YPX>; Wed, 26 Jul 2000 14:13:07 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB08621D25@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Randy Presuhn Cc: Disman@dorothy.peer.com, IESG Subject: RE: Last Call: for 3 disman WG MIB documents Date: Wed, 26 Jul 2000 14:12:30 +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 Randy, no Last Call Comments have been received. That means, they will now go onto IESG agenda. First IESG telechat where docs get discussed is on Aug 10 I believe. I will get them discussed there. If IESG approves them there, then they go into RFC-Editor Queue (you will get qa formal announcement when it happens from Steve Coya). I will change the status on our OPS webpage to "On IESG Agenda" Thanks for the ping, Bert