From maria@xedia.com Mon Aug 3 16:13:05 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA26332 for ; Mon, 3 Aug 1998 16:13:04 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA18668 for ; Mon, 3 Aug 1998 16:11:43 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma018658; Mon, 3 Aug 98 16:11:28 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA12470 for ; Mon, 3 Aug 1998 16:10:46 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma011926; Mon, 3 Aug 98 16:10:06 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA08415; Mon, 3 Aug 1998 16:10:25 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA10442 for ; Mon, 3 Aug 1998 14:10:06 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id QAA03928 for ; Mon, 3 Aug 1998 16:10:04 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma003917; Mon, 3 Aug 98 16:09:58 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id QAA08046 for ; Mon, 3 Aug 1998 16:34:23 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id QAA04038 for ; Mon, 3 Aug 1998 16:34:05 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA13346 for ; Mon, 3 Aug 1998 15:34:03 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma013107; Mon, 3 Aug 98 15:32:58 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA08483 for ; Mon, 3 Aug 1998 15:32:12 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma005625; Mon, 3 Aug 98 15:29:07 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA27506 for ; Mon, 3 Aug 1998 15:29:37 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA10001 for disman@nexen.com; Mon, 3 Aug 1998 13:29:35 -0700 (PDT) Date: Mon, 3 Aug 1998 13:29:35 -0700 (PDT) From: Randy Presuhn Message-Id: <199808032029.NAA10001@dorothy.bmc.com> To: disman@nexen.com Subject: Re: WG Last Call: schedule MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Fri, 31 Jul 1998 21:28:36 +0200 > From: Juergen Schoenwaelder > To: dds@cnd.hp.com > CC: disman@nexen.com > Subject: Re: WG Last Call: schedule MIB > References: <199807210059.RAA06992@dorothy.bmc.com> <35C1DBFD.94604070@cnd.hp.com> ... (discussion of one-shot schedules) ... > I think this depends on a) Randy's view of the procedural aspect and > b) the WG's view whether we want to add this feature. The changes seem > to be pretty small. Please let us know what you think. ... Since 1) the change is minor 2) at least one editor supports it 3) support from the WG has been voiced 4) no opposition has been voiced 5) there appears to be no additional impact to our delivery schedule the WG chair says: add it, unless unforeseen complications appear. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From maria@xedia.com Mon Aug 3 16:19:51 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA26386 for ; Mon, 3 Aug 1998 16:19:48 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA19607 for ; Mon, 3 Aug 1998 16:18:28 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma019482; Mon, 3 Aug 98 16:17:37 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA18242 for ; Mon, 3 Aug 1998 16:16:54 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma016903; Mon, 3 Aug 98 16:15:26 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA09788; Mon, 3 Aug 1998 16:15:46 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA10494 for ; Mon, 3 Aug 1998 14:15:38 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA19126 for ; Mon, 3 Aug 1998 16:15:33 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma019083; Mon, 3 Aug 98 16:15:25 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA16298 for ; Mon, 3 Aug 1998 16:14:46 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by dresden.bmc.com via smap (3.2) id xma015056; Mon, 3 Aug 98 16:13:29 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id QAA08454 for ; Mon, 3 Aug 1998 16:44:23 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id QAA04095 for ; Mon, 3 Aug 1998 16:44:09 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA14135 for ; Mon, 3 Aug 1998 15:44:00 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma014122; Mon, 3 Aug 98 15:43:36 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA17263 for ; Mon, 3 Aug 1998 15:42:57 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma017086; Mon, 3 Aug 98 15:42:41 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA01366; Mon, 3 Aug 1998 15:43:02 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA10117; Mon, 3 Aug 1998 13:42:58 -0700 (PDT) Date: Mon, 3 Aug 1998 13:42:58 -0700 (PDT) From: Randy Presuhn Message-Id: <199808032042.NAA10117@dorothy.bmc.com> To: agenda@ietf.org Subject: Disman agenda for Chicago Cc: disman@nexen.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - Here's the agenda for the Disman working group, meeting in Chicago on Thursday, August 27 at 0900-1130. 1. Adminstrative matters 1.1 selection of minute-taker See http://www.ietf.org/instructions/minutes.html 1.2 circulation of signup sheet 1.3 Review of Agenda 1.4 Allocation of time 2. Status of Current work 2.1 Script MIB 2.2 Schedule MIB 2.3 Notification/Log MIB 2.4 Event MIB 2.5 Expression MIB 2.6 Framework 3. Review of Interactions with other working groups 3.1 SNMPv3 issues (forwarded from SNMPv3 WG meeting on Monday) 3.2 AgentX issues (forwarded from AgentX WG meeting on Wednesday) 4. Charter updates See http://www.ietf.org/html.charters/disman-charter.html 4.1 completed items 4.2 changes to target dates 4.3 Possibile additions to charter: 4.3.1 Remote Operations MIB http://ftp.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-00.txt (an update may soon be available) 4.3.2 "Script MIB Extensibility" http://www.ibr.cs.tu-bs.de/projects/jasmin/smx.ps 5. Technical Presentations See http://www.ietf.org/instructions/slides.html 5.1 implementation reports 6. Wrap-up 6.1 reminders to minute-takers and presenters 6.2 retrieval of sign-up sheet ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From maria@xedia.com Mon Aug 3 16:50:23 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA26625 for ; Mon, 3 Aug 1998 16:50:17 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA22760 for ; Mon, 3 Aug 1998 16:48:48 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma022561; Mon, 3 Aug 98 16:47:48 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA16618 for ; Mon, 3 Aug 1998 16:47:03 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma014143; Mon, 3 Aug 98 16:44:35 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA17668; Mon, 3 Aug 1998 16:44:59 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA10704 for ; Mon, 3 Aug 1998 14:44:52 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA22033 for ; Mon, 3 Aug 1998 16:44:49 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma021869; Mon, 3 Aug 98 16:44:09 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id RAA09211 for ; Mon, 3 Aug 1998 17:14:58 -0400 (EDT) Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id RAA00788 for ; Mon, 3 Aug 1998 17:14:57 -0400 (EDT) Received: from tootsie.cisco.com (tootsie.cisco.com [171.69.128.44]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id OAA16835 for ; Mon, 3 Aug 1998 14:14:51 -0700 (PDT) Message-Id: <3.0.5.32.19980803171418.007c7690@zipper.cisco.com> X-Sender: bstewart@zipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 03 Aug 1998 17:14:18 -0400 To: Distributed Management WG From: Bob Stewart Subject: Internet Draft - Notification Log MIB Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Here is a new draft of the Notification Log MIB as submitted to become: draft-ietf-disman-notif-log-mib-03.txt. This draft has the following changes from the interim draft posted here a few days ago (thanks to a quality review by Martin Bjorklund: Removed the idea of no limit on entries. Changed logging control to key off snmpNotifyFilterProfileName (it was broken, suffering from major, improperly tracked changes in the Notification MIB). This draft has the following changes from the previous Internet Draft: Updated boilerplate. Added a real overview, including security operation. Especially note what I did with security for lack of a better idea. I made the security depend on the *contents* of MIB objects in related tables. Although this is computable it sure won't fall out for free in any implementation I can imagine. This is your chance to suggest improvements. Corrected the SYNTAX of nlmNotificationID and various other typos. Separated some of the objects in the variable table so it now directly reflects the wire-visible SNMP data types. Changed the capacity configuration for units of entries or bytes and stated operation when reducing the limit. Allowed limit to be hard coded. Added a logged variable count for each notification and made the variable index monotonic from one. Clarified that only one variable value per variable is instantiated. Added objects to record the engine ID and context of a notification. Bob --------------- Internet Draft Notification Log MIB 31 July 1998 Notification Log MIB 31 July 1998 draft-ietf-disman-notif-log-mib-03.txt Bob Stewart Cisco Systems, Inc. bstewart@cisco.com Status of this Memo This document is an Internet-Draft. 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.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Please send comments to the Distributed Management Working Group, . Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Expires 31 July 1998+6 months [Page 1] Internet Draft Notification Log MIB 31 July 1998 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 used for logging SNMP Notifications. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. 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 RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. 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 Expires 31 July 1998+6 months [Page 2] Internet Draft Notification Log MIB 31 July 1998 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. Expires 31 July 1998+6 months [Page 3] Internet Draft Notification Log MIB 31 July 1998 3. Overview Systems that support SNMP often need a mechanism for recording Notification information as a hedge against lost Notifications, whether those are Traps or Informs that exceed retransmission limits. This MIB therefore provides common infrastructure for other MIBs in the form of a local logging function. It is intended primarily for senders of Notifications but could be used also by receivers. Given the Notification Log MIB, individual MIBs bear less responsibility to record the transient information associated with an event against the possibility that the Notification message is lost, and applications can poll the log to know that they have not missed important Notifications or to suspect that they might have. 3.1. Environment The overall environmental concerns for the MIB are: o SNMP Engines and Contexts o Security 3.1.1. SNMP Engines and Contexts As described in the SNMPv3 architecture [1], a given system may support multiple SNMP engines operating independently of one another, each with its own SNMP engine identification. Furthermore, within the perview of a given engine there may be multiple named management contexts supporting overlapping or disjoint sets of MIB objects and Notifications. Thus understanding a particular Notification requires knowing the SNMP engine and management context from whence it came. The simplest system may have only one SNMP engine, and the simplest engine may support only one context. In these cases, knowledge of the engine ID and context name can be assumed and need not be explicit. In a given implementation, an instance of the Notification Log MIB may be confined to a single engine or context or may combine information from multiple engines or contexts, allowing for the full range of exclusive or inclusive contents. To provide the necessary source information for a logged Notification, Expires 31 July 1998+6 months [Page 4] Internet Draft Notification Log MIB 31 July 1998 the MIB includes objects to record that Notification's source SNMP engine ID and management context name. In the case where such information can be assumed, the related object need not be instantiated, thus allowing the simplest implemenetation for the simplest system. 3.1.2. Security Except for the log itself security of this MIB falls under normal SNMP security policies. For the log, Notifications containing objects not within a requester's authorized view will appear not to exist, thus causing apparent holes in the log index space. If the log contains Notifications from SNMP engines not part of the local system, those Notifications fall under the overall local access policy for the log. 3.2. Structure The MIB has the following sections: o Configuration -- control over how much the log can hold and what Notifications are to be logged. o Statistics -- indications of logging activity. o Log -- the Notifications themselves. 3.2.1. Configuration The configuration section contains objects to manage resource use by the MIB in units of either bytes or entries. This section also contains a table that uses the initial index (snmpNotifyFilterName) from the snmpNotifyFilterTable in the standard SNMP Notification MIB, using those filters to provide a means of deciding which Notifications are to be logged. Expires 31 July 1998+6 months [Page 5] Internet Draft Notification Log MIB 31 July 1998 3.2.2. Statistics The statistics section contains counters for Notifications logged and discarded, supplying a means to understand the results of log capacity configuration. 3.2.3. Log The log contains the Notifications and the objects that came in their variable binding list, indexed by an integer that reflects when the entry was made. An application that wants to collect all logged Notifications or to know if it may have missed any can keep track of the highest index it has retrieved and start from there on its next poll, checking sysUpTime for a discontinuity that would have reset the index and perhaps have lost entries. Variables are in a table indexed by Notification index and variable index within that Notification. The values are kept as a "discriminated union," with one value object per variable. Exactly which value object is instantiated depends on the SNMP data type of the variable, with a separate object of appropriate type for each distinct SNMP data type. An application can thus reconstruct the information from the Notification PDU from what is recorded in the log. Expires 31 July 1998+6 months [Page 6] Internet Draft Notification Log MIB 31 July 1998 4. Definitions NOTIFICATION-LOG-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, experimental, Integer32, Unsigned32, TimeTicks, Counter32, Counter64, IpAddress FROM SNMPv2-SMI TimeStamp, TruthValue, StorageType FROM SNMPv2-TC SnmpAdminString, SnmpEngineID FROM SNMP-FRAMEWORK-MIB snmpNotifyFilterProfileName FROM SNMP-NOTIFICATION-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; notificationLogMIB MODULE-IDENTITY LAST-UPDATED "9807311700Z" ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 526 4527 Email: bstewart@cisco.com" DESCRIPTION "The MIB module for logging SNMP Notifications, that is, Traps and Informs." ::= { experimental xx } notificationLogMIBObjects OBJECT IDENTIFIER ::= { notificationLogMIB 1 } nlmConfig OBJECT IDENTIFIER ::= { notificationLogMIBObjects 1 } nlmStats OBJECT IDENTIFIER ::= { notificationLogMIBObjects 2 } nlmLog OBJECT IDENTIFIER ::= { notificationLogMIBObjects 3 } -- -- Configuration Section -- nlmConfigEntryLimitUnits OBJECT-TYPE SYNTAX INTEGER { entries(1), bytes(2) } MAX-ACCESS read-write STATUS current DESCRIPTION Expires 31 July 1998+6 months [Page 7] Internet Draft Notification Log MIB 31 July 1998 "The units for nlmConfigEntryLimit. See nlmConfigEntryLimit for further details. Implementations may allow choice of unit types or may chose either unit type and not allow it to be changed." ::= { nlmConfig 1 } nlmConfigEntryLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of entries or bytes that can be held in nlmLogTable. If an application changes the limit while there are Notifications in the log, the oldest Notifications are discarded to bring the log down to the new limit. Measuring in bytes is not necessarily subject to exact external calculations as to what will fit, as the implementation may or may not include internal overhead and is free to use any internal incoding. Implementations may choose a limit and not allow it to be changed or may enforce an upper bound on the limit." ::= { nlmConfig 2 } -- -- Notify Table Logging Control Table -- nlmConfigLogControlTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmConfigLogControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of logging control entries, related to filter profiles from the SNMP Notification MIB." ::= { nlmConfig 3 } nlmConfigLogControlEntry OBJECT-TYPE SYNTAX NlmConfigLogControlEntry MAX-ACCESS not-accessible STATUS current Expires 31 July 1998+6 months [Page 8] Internet Draft Notification Log MIB 31 July 1998 DESCRIPTION "A logging control entry. Depending on the entry's storage type entries may be supplied by the system or created and deleted by applications using nlmConfigLogControlStatus." INDEX { snmpNotifyFilterProfileName } ::= { nlmConfigNotifyTable 1 } NlmConfigLogControlEntry ::= SEQUENCE { nlmConfigLogControlLog TruthValue, nlmConfigLogControlStorageType StorageType, nlmConfigLogControlStatus RowStatus } nlmConfigLogControlLog OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Control for whether this set of Notifications is logged in nlmLogTable." DEFVAL { false } ::= { nlmConfigLogControlEntry 1 } nlmConfigLogControlStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type of this conceptual row." DEFVAL { false } ::= { nlmConfigLogControlEntry 2 } nlmConfigLogControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Control for creating and deleting entries. Entries may be modified while active." DEFVAL { createAndWait } ::= { nlmConfigLogControlEntry 3 } -- -- Statisitics Section -- Expires 31 July 1998+6 months [Page 9] Internet Draft Notification Log MIB 31 July 1998 nlmStatsNotificationsLogged OBJECT-TYPE SYNTAX Counter32 UNITS "entries" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Notifications put in the nlmLogTable." ::= { nlmStats 1 } nlmStatsEntriesDiscarded OBJECT-TYPE SYNTAX Counter32 UNITS "entries" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of log entries discarded to make room for a new entry or because of a change in nlmConfigEntryLimitUnits or nlmConfigEntryLimit." ::= { nlmStats 2 } -- -- Log Section -- -- -- Log Table -- nlmLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Notification log entries. It is an implementation-specific matter whether entries in this table are preserved across initializations of the management system. In general one would expect that they are not." ::= { nlmLog 1 } nlmLogEntry OBJECT-TYPE SYNTAX NlmLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires 31 July 1998+6 months [Page 10] Internet Draft Notification Log MIB 31 July 1998 "A Notification log entry. Entries appear in this table when Notifications occur and are enabled for logging by nlmConfigNotifyLog. They are removed to make way for new entries or in response to an application setting nlmConfigEntryLimit or nlmConfigEntryLimitUnits to reduce capacity." INDEX { nlmLogIndex } ::= { nlmLogTable 1 } NlmLogEntry ::= SEQUENCE { nlmLogIndex Unsigned32, nlmLogTime TimeStamp, nlmLogEngineID SnmpEngineID, nlmLogContextName SnmpAdminString, nlmLogVariables Unsigned32, nlmLogNotificationID OBJECT IDENTIFIER } nlmLogIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A monotonically increasing integer for the sole purpose of indexing entries. When it reaches the maximum value, an extremely unlikely event, the agent wraps the value back to 1 and may flush existing entries." ::= { nlmLogEntry 1 } nlmLogTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the entry occurred." ::= { nlmLogEntry 2 } nlmLogEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current DESCRIPTION "The identification of the SNMP engine at which the Notification originated. Expires 31 July 1998+6 months [Page 11] Internet Draft Notification Log MIB 31 July 1998 If the log can contain Notifications from only one engine this object need not be instantiated." ::= { nlmLogEntry 3 } nlmLogContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the SNMP MIB context from which the Notification came. If the Notification's source SNMP engine does not support multiple contexts, this object need not be instantiated." ::= { nlmLogEntry 4 } nlmLogVariables OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of variables in nlmLogVariableTable for this Notification." ::= { nlmLogEntry 5 } nlmLogNotificationID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The NOTIFICATION-TYPE object identifer of the Notification that occurred." ::= { nlmLogEntry 6 } -- -- Log Variable Table -- nlmLogVariableTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmLogVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of variables to go with Notification log entries." ::= { nlmLog 2 } Expires 31 July 1998+6 months [Page 12] Internet Draft Notification Log MIB 31 July 1998 nlmLogVariableEntry OBJECT-TYPE SYNTAX NlmLogVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log entry variable. Entries appear in this table when there are variables in the varbind list of a Notification in nlmLogTable." INDEX { nlmLogIndex, nlmLogVariableIndex } ::= { nlmLogVariableTable 1 } NlmLogVariableEntry ::= SEQUENCE { nlmLogVariableIndex Unsigned32, nlmLogVariableID OBJECT IDENTIFIER, nlmLogVariableValueType INTEGER, nlmLogVariableCounter32Val Counter32, nlmLogVariableUnsigned32Val Unsigned32, nlmLogVariableTimeTicksVal TimeTicks, nlmLogVariableInteger32Val Integer32, nlmLogVariableOctetStringVal OCTET STRING, nlmLogVariableIpAddressVal IpAddress, nlmLogVariableOidVal OBJECT IDENTIFIER, nlmLogVariableCounter64Val Counter64 } nlmLogVariableIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A monotonically increasing integer, starting at 1 for a given nlmLogIndex, for indexing variables within the logged Notification." ::= { nlmLogVariableEntry 1 } nlmLogVariableID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The variable's object identifier." ::= { nlmLogVariableEntry 2 } nlmLogVariableValueType OBJECT-TYPE SYNTAX INTEGER { counter32(1), unsignedOrGauge32(2), Expires 31 July 1998+6 months [Page 13] Internet Draft Notification Log MIB 31 July 1998 timeTicks(3), integer32(4), ipAddress(5), octetString(6), objectId(7), counter64(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the value. One and only one of the value objects that follow is instantiated, based on this type." ::= { nlmLogVariableEntry 3 } nlmLogVariableCounter32Val OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'counter32'." ::= { nlmLogVariableEntry 4 } nlmLogVariableUnsigned32Val OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'unsignedOrGauge32'." ::= { nlmLogVariableEntry 5 } nlmLogVariableTimeTicksVal OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'timeTicks'." ::= { nlmLogVariableEntry 6 } nlmLogVariableInteger32Val OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'integer32'." ::= { nlmLogVariableEntry 7 } nlmLogVariableOctetStringVal OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current Expires 31 July 1998+6 months [Page 14] Internet Draft Notification Log MIB 31 July 1998 DESCRIPTION "The value when nlmLogVariableType is 'octetString'." ::= { nlmLogVariableEntry 8 } nlmLogVariableIpAddressVal OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'ipAddress'." ::= { nlmLogVariableEntry 9 } nlmLogVariableOidVal OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'objectId'." ::= { nlmLogVariableEntry 10 } nlmLogVariableCounter64Val OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'counter64'." ::= { nlmLogVariableEntry 11 } -- -- Conformance -- notificationLogMIBConformance OBJECT IDENTIFIER ::= { notificationLogMIB 3 } notificationLogMIBCompliances OBJECT IDENTIFIER ::= { notificationLogMIBConformance 1 } notificationLogMIBGroups OBJECT IDENTIFIER ::= { notificationLogMIBConformance 2 } -- Compliance notificationLogMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Notification Log MIB." MODULE -- this module Expires 31 July 1998+6 months [Page 15] Internet Draft Notification Log MIB 31 July 1998 MANDATORY-GROUPS { notificationLogConfigGroup, notificationLogStatsGroup, notificationLogLogGroup } ::= { notificationLogMIBCompliances 1 } -- Units of Conformance notificationLogConfigGroup OBJECT-GROUP OBJECTS { nlmConfigEntryLimitUnits, nlmConfigEntryLimit, nlmConfigNotifyLog } STATUS current DESCRIPTION "Notification log configuration management." ::= { notificationLogMIBGroups 1 } notificationLogStatsGroup OBJECT-GROUP OBJECTS { nlmStatsNotificationsLogged, nlmStatsEntriesDiscarded } STATUS current DESCRIPTION "Notification log statistics." ::= { notificationLogMIBGroups 2 } notificationLogLogGroup OBJECT-GROUP OBJECTS { nlmLogTime, nlmLogEngineID, nlmLogContextName, nlmLogVariables, nlmLogNotificationID, nlmLogVariableID, nlmLogVariableValueType, nlmLogVariableCounter32Val, nlmLogVariableUnsigned32Val, nlmLogVariableTimeTicksVal, nlmLogVariableInteger32Val, nlmLogVariableOctetStringVal, Expires 31 July 1998+6 months [Page 16] Internet Draft Notification Log MIB 31 July 1998 nlmLogVariableIpAddressVal, nlmLogVariableOidVal, nlmLogVariableCounter64Val } STATUS current DESCRIPTION "Notification log data." ::= { notificationLogMIBGroups 3 } END Expires 31 July 1998+6 months [Page 17] Internet Draft Notification Log MIB 31 July 1998 5. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998 [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991 [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. Expires 31 July 1998+6 months [Page 18] Internet Draft Notification Log MIB 31 July 1998 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, January 1998 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., Cisco Systems, Inc., January 1998 Expires 31 July 1998+6 months [Page 19] Internet Draft Notification Log MIB 31 July 1998 6. Security Considerations Security issues are discussed in the overview. 7. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 Phone: 408-526-4527 Email: bstewart@cisco.com Expires 31 July 1998+6 months [Page 20] Internet Draft Notification Log MIB 31 July 1998 Table of Contents 1 Abstract ........................................................ 2 2 The SNMP Management Framework ................................... 2 3 Overview ........................................................ 4 3.1 Environment ................................................... 4 3.1.1 SNMP Engines and Contexts ................................... 4 3.1.2 Security .................................................... 5 3.2 Structure ..................................................... 5 3.2.1 Configuration ............................................... 5 3.2.2 Statistics .................................................. 6 3.2.3 Log ......................................................... 6 4 Definitions ..................................................... 7 5 References ...................................................... 18 6 Security Considerations ......................................... 20 7 Author's Address ................................................ 20 Expires 31 July 1998+6 months [Page 21] From maria@xedia.com Mon Aug 3 18:35:46 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id SAA27453 for ; Mon, 3 Aug 1998 18:35:45 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA06791 for ; Mon, 3 Aug 1998 18:34:29 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma006782; Mon, 3 Aug 98 18:34:23 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id SAA29032 for ; Mon, 3 Aug 1998 18:33:48 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma028996; Mon, 3 Aug 98 18:33:30 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id SAA14622; Mon, 3 Aug 1998 18:34:03 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA11665 for ; Mon, 3 Aug 1998 16:34:02 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id SAA11223 for ; Mon, 3 Aug 1998 18:34:00 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma011213; Mon, 3 Aug 98 18:33:48 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id TAA11126 for ; Mon, 3 Aug 1998 19:10:47 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id TAA00210 for ; Mon, 3 Aug 1998 19:10:42 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA04522 for ; Mon, 3 Aug 1998 18:10:40 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma004415; Mon, 3 Aug 98 18:10:07 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id SAA18506 for ; Mon, 3 Aug 1998 18:09:31 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma018184; Mon, 3 Aug 98 18:09:03 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id SAA09086; Mon, 3 Aug 1998 18:09:19 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA11460; Mon, 3 Aug 1998 16:09:12 -0700 (PDT) Date: Mon, 3 Aug 1998 16:09:12 -0700 (PDT) From: Randy Presuhn Message-Id: <199808032309.QAA11460@dorothy.bmc.com> To: wijnen@VNET.IBM.COM Subject: Re: WG Last Call: Script MIB Cc: Harald.Alvestrand@maxware.no, disman@nexen.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Bert - The disman working group as completed its working group last call for . There were no comments on this draft during this period, so as working group chair I'm handing it off to you to subject it to review and the tender mercies of the IESG. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From maria@xedia.com Tue Aug 4 01:44:51 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id BAA00772 for ; Tue, 4 Aug 1998 01:44:51 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id BAA28417 for ; Tue, 4 Aug 1998 01:43:33 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma028409; Tue, 4 Aug 98 01:43:29 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id BAA02723 for ; Tue, 4 Aug 1998 01:42:54 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma002631; Tue, 4 Aug 98 01:42:32 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id BAA27866; Tue, 4 Aug 1998 01:43:05 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id XAA12947 for ; Mon, 3 Aug 1998 23:43:04 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id BAA28401 for ; Tue, 4 Aug 1998 01:43:03 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma028396; Tue, 4 Aug 98 01:42:54 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id CAA13817 for ; Tue, 4 Aug 1998 02:06:42 -0400 (EDT) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id CAA05434 for ; Tue, 4 Aug 1998 02:06:40 -0400 (EDT) Received: from alden (alvestrand.kvatro.no [193.216.167.143]) by dokka.maxware.no (8.8.5/8.8.5) with SMTP id IAA27696; Tue, 4 Aug 1998 08:02:23 +0200 Message-Id: <3.0.2.32.19980804080429.01087360@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Tue, 04 Aug 1998 08:04:29 +0200 To: Juergen Schoenwaelder From: Harald Tveit Alvestrand Subject: Re: WG Last Call: schedule MIB Cc: disman@nexen.com In-Reply-To: <199807311922.VAA01346@henkell.ibr.cs.tu-bs.de> References: <3.0.2.32.19980731154317.013255d0@dokka.maxware.no> <3.0.2.32.19980731154317.013255d0@dokka.maxware.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 21:22 31.07.98 +0200, Juergen Schoenwaelder wrote: > >>>>>> Harald Tveit Alvestrand writes: > >Harald> Worse: I could not find in the schedule-mib-04 draft >Harald> *anything* about whether times specified are in UTC or in >Harald> local time. > >They are meant to be in local time. I agree that this needs to be >defined somewhere. Hmmm.....after all the things I learned about "local time" in the CALSCH context, I urge you to take care. Having a full CALSCH timezone specification of what "local time" means might be a bit of overkill, but I'd suggest that in order for "local time" to be unambiguous, you should have MIB variables to tell: - Current offset to GMT - Time of next change to current offset - Offset after the next change to current offset That would be enough to guarantee that at all times, you can tell how long is it to an event less than 24 hours away in local time, and mostly the time left until all events less than 6 months away. Daylight Saving Time: another invention to make programmers' lives harder... Harald -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From maria@xedia.com Tue Aug 4 12:52:48 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA05801 for ; Tue, 4 Aug 1998 12:52:46 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA06217 for ; Tue, 4 Aug 1998 12:51:25 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma006195; Tue, 4 Aug 98 12:51:02 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA28580 for ; Tue, 4 Aug 1998 12:50:26 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma028366; Tue, 4 Aug 98 12:50:14 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA24903; Tue, 4 Aug 1998 12:50:30 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA15035 for ; Tue, 4 Aug 1998 10:50:25 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id MAA23432 for ; Tue, 4 Aug 1998 12:50:23 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma023398; Tue, 4 Aug 98 12:50:12 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id NAA21256 for ; Tue, 4 Aug 1998 13:08:00 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id NAA05245 for ; Tue, 4 Aug 1998 13:07:58 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.1/8.9.0) with ESMTP id TAA23802; Tue, 4 Aug 1998 19:07:53 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id TAA19491; Tue, 4 Aug 1998 19:07:52 +0200 Date: Tue, 4 Aug 1998 19:07:52 +0200 Message-Id: <199808041707.TAA19491@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Harald.Alvestrand@maxware.no CC: disman@nexen.com In-reply-to: <3.0.2.32.19980804080429.01087360@dokka.maxware.no> (message from Harald Tveit Alvestrand on Tue, 04 Aug 1998 08:04:29 +0200) Subject: Re: WG Last Call: schedule MIB References: <3.0.2.32.19980731154317.013255d0@dokka.maxware.no> <3.0.2.32.19980731154317.013255d0@dokka.maxware.no> <3.0.2.32.19980804080429.01087360@dokka.maxware.no> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Harald Tveit Alvestrand writes: Harald> Hmmm.....after all the things I learned about "local time" in Harald> the CALSCH context, I urge you to take care. Having a full Harald> CALSCH timezone specification of what "local time" means might Harald> be a bit of overkill, but I'd suggest that in order for "local Harald> time" to be unambiguous, you should have MIB variables to Harald> tell: Harald> - Current offset to GMT Harald> - Time of next change to current offset Harald> - Offset after the next change to current offset Harald> That would be enough to guarantee that at all times, you can Harald> tell how long is it to an event less than 24 hours away in Harald> local time, and mostly the time left until all events less Harald> than 6 months away. In other words, we would require that an agent implementing this MIB is able to find out the start and end dates for daylight saving time periods, right? How hard is this on devices such as routers or switches or other non-UNIX systems? Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) From maria@xedia.com Tue Aug 4 14:30:16 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA06578 for ; Tue, 4 Aug 1998 14:30:15 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA12830 for ; Tue, 4 Aug 1998 14:28:56 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012814; Tue, 4 Aug 98 14:28:34 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA22040 for ; Tue, 4 Aug 1998 14:27:59 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma021998; Tue, 4 Aug 98 14:27:56 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA18558; Tue, 4 Aug 1998 14:28:29 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA15933 for ; Tue, 4 Aug 1998 12:28:27 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA12811 for ; Tue, 4 Aug 1998 14:28:26 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma012809; Tue, 4 Aug 98 14:28:23 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id OAA22957 for ; Tue, 4 Aug 1998 14:51:23 -0400 (EDT) Received: from relay6.UU.NET (relay6.UU.NET [192.48.96.16]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id OAA08739 for ; Tue, 4 Aug 1998 14:51:22 -0400 (EDT) Received: from xedia.com by relay6.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfazz27108; Tue, 4 Aug 1998 14:51:22 -0400 (EDT) Received: from (espanola) by xedia.com (4.1/SMI-4.1) id AA26557; Tue, 4 Aug 98 14:51:10 EDT Received: by (5.x/SMI-SVR4) id AA08613; Tue, 4 Aug 1998 14:51:20 -0400 Date: Tue, 4 Aug 1998 14:51:20 -0400 From: maria@xedia.com (Maria Greene) Message-Id: <9808041851.AA08613@> To: disman@nexen.com Subject: bounce test, please ignore From maria@xedia.com Tue Aug 4 16:06:14 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA07304 for ; Tue, 4 Aug 1998 16:06:14 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA19236 for ; Tue, 4 Aug 1998 16:04:55 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma019223; Tue, 4 Aug 98 16:04:34 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA17204 for ; Tue, 4 Aug 1998 16:03:56 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma016889; Tue, 4 Aug 98 16:03:37 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA12186; Tue, 4 Aug 1998 16:04:04 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA16280 for ; Tue, 4 Aug 1998 14:03:50 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id QAA05015 for ; Tue, 4 Aug 1998 16:03:49 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma004999; Tue, 4 Aug 98 16:03:26 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id QAA24519 for ; Tue, 4 Aug 1998 16:27:40 -0400 (EDT) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id QAA09347 for ; Tue, 4 Aug 1998 16:27:38 -0400 (EDT) Received: from alden (alvestrand.kvatro.no [193.216.167.143]) by dokka.maxware.no (8.8.5/8.8.5) with SMTP id WAA04954; Tue, 4 Aug 1998 22:23:18 +0200 Message-Id: <3.0.2.32.19980804221833.01c287c0@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Tue, 04 Aug 1998 22:18:33 +0200 To: Juergen Schoenwaelder From: Harald Tveit Alvestrand Subject: Re: WG Last Call: schedule MIB Cc: disman@nexen.com In-Reply-To: <199808041707.TAA19491@henkell.ibr.cs.tu-bs.de> References: <3.0.2.32.19980804080429.01087360@dokka.maxware.no> <3.0.2.32.19980731154317.013255d0@dokka.maxware.no> <3.0.2.32.19980731154317.013255d0@dokka.maxware.no> <3.0.2.32.19980804080429.01087360@dokka.maxware.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 19:07 04.08.98 +0200, Juergen Schoenwaelder wrote: > > >In other words, we would require that an agent implementing this MIB >is able to find out the start and end dates for daylight saving time >periods, right? How hard is this on devices such as routers or >switches or other non-UNIX systems? > Juergen > Not necessarily require; it is perfectly sane to have a system that knows nothing about timezones, and do DST by manual configuration; the operator will be on hand to take care of the scheduling damage. The thing I'm looking for is "least surprise" when dealing with boxes that *automatically* do strange things to the local-time clock. My knowledge of Ciscos is rusty & spotty, but I think Cisco routers *do* have a way to specify DST rules (single date move-forward/move-back, no concept of "next year's rule will be different" - just like Windows 95). Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From maria@xedia.com Tue Aug 4 18:14:38 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id SAA08324 for ; Tue, 4 Aug 1998 18:14:38 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA28004 for ; Tue, 4 Aug 1998 18:13:18 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma027970; Tue, 4 Aug 98 18:12:55 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id SAA02895 for ; Tue, 4 Aug 1998 18:12:19 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma002683; Tue, 4 Aug 98 18:11:57 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id SAA15278; Tue, 4 Aug 1998 18:12:15 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA17772 for ; Tue, 4 Aug 1998 16:12:13 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id SAA11347 for ; Tue, 4 Aug 1998 18:12:11 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma011336; Tue, 4 Aug 98 18:11:46 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id SAA26455 for ; Tue, 4 Aug 1998 18:31:46 -0400 (EDT) From: remoore@us.ibm.com Received: from smtp4.ny.us.ibm.COM (smtp4.ny.us.ibm.com [198.133.22.43]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id SAA11252 for ; Tue, 4 Aug 1998 18:31:45 -0400 (EDT) Received: from relay1.server.ibm.com (relay1.server.ibm.com [9.14.2.98]) by smtp4.ny.us.ibm.COM (8.8.7/8.8.7) with ESMTP id SAA80934 for ; Tue, 4 Aug 1998 18:22:04 -0400 Received: from us.ibm.com (d51mta01.pok.ibm.com [9.117.30.75]) by relay1.server.ibm.com (8.8.7/8.8.7) with SMTP id SAA32056 for ; Tue, 4 Aug 1998 18:28:57 -0400 Received: by us.ibm.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 85256656.007B3419 ; Tue, 4 Aug 1998 18:25:42 -0400 X-Lotus-FromDomain: IBMUS To: disman@nexen.com cc: schoenw@ibr.cs.tu-bs.de, levi@snmp.com, rpresuhn@bmc.com, wijnen@VNET.IBM.COM, Harald.Alvestrand@maxware.no Message-ID: <85256655.004DA72C.00@us.ibm.com> Date: Mon, 3 Aug 1998 11:39:39 -0400 Subject: Re: WG Last Call: schedule MIB Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I had just finished a first pass through the Schedule MIB for the Area review that Bert had requested, when I noticed that there was going to be an additional draft to accommodate comments received during Disman WG last call. Rather than waiting, I'll provide my initial comments now, so that the WG will have a chance to react to them, and the editors may be able to incorporate their responses into the next draft. 1. "SHALL" / "SHOULD" paragraph, reference to RFC 2119 missing. The paragraph is usually placed as the last paragraph in the "Introduction" section. 2. Section 3, first paragraph: "...or trigger management functions in a DISMAN application." What *is* "a DISMAN application"? If it's just an abbreviation for "a distributed management application", then fine: just remove the abbreviation. If, however, there's something more to it (e.g., "the kind of application we've been discussing in the DISMAN WG"), then you need to spell out this additional meaning. 3. Section 3.2: two points should be clarified: - these schedules do *not* provide for "specified dates and times", in the way that the DateAndTime TC does: they provide for specified days of the week and days of the month, but not for specified dates. If you add the capability for the one-shot schedule, you'll have to be especially clear that even this doesn't provide for scheduling an action on a specified date. - the central semantics of the scheduling objects need to be spelled out, both here and in the objects' DESCRIPTIONS: the mask bits in each individual objects are OR-ed, and the values from the five objects are then AND-ed. I was able to infer these semantics from the examples, but they need to be spelled out explicitly. 4. SnmpPduErrorStatus TC Description, possibly other places: check the encoding for the opening single quote character, e.g., in 'noResponse'. This doesn't display correctly for me, and it doesn't print at all. 5. schedInterval object: how about a DEFVAL of 0, meaning don't perform the action at all? This would match the DEFVALs for the five calendar objects, and would provide for uniform agent behavior for entries that are created as calendar schedules and are then changed to periodic. 6. schedDay object: when I worked on ISO 10164-20 ITU Rec. X.743, we included the capability to count days backward from the end of the month, in addition to counting them forward from the beginning. It would be easy to extend the enumeration in this object to add this capability: BITS { d1(0), d2(1), d3(2), d4(3), d5(4), d6(5), d7(6), d8(7), d9(8), d10(9), d11(10), d12(11), d13(12), d14(13), d15(14), d16(15), d17(16), d18(17), d19(18), d20(19), d21(20), d22(21), d23(22), d24(23), d25(24), d26(25), d27(26), d28(27), d29(28), d30(29), d31(30), e1(31), e2(32), e3(33), e4(34), e5(35), e6(36), e7(37), e8(38), e9(39), e10(40), e11(41), e12(42), e13(43), e14(44), e15(45), e16(46), e17(47), e18(48), e19(49), e20(50), e21(51), e22(52), e23(53), e24(54), e25(55), e26(56), e27(57), e28(58), e29(59), e30(60), e31(61) } Before you dismiss this as needlessly complicated, think carefully about whether there will be a requirement to trigger an action at, say, 5:00 PM on the last day of every month. 7. schedAdminStatus object: At first glance the enumeration values for this object look peculiar. You're combining both the "traditional" AdminStatus values (enabled / disabled) and values I'd expect to see in an object named "schedType". One implication of this approach is that if an entry's Admin Status is set to 'disabled' (and its Oper Status follows suit), the entry "forgets" whether it was a periodic schedule or a calendar schedule (or a one-shot schedule, if you add that as a third option). Maybe this is exactly what you intended, but to me the type of a schedule is distinct from whether the schedule is currently enabled, so I'd expect to see the two represented with separate objects. 8. schedAdminStatus object: Regardless of how the previous issue is resolved, there's a question about what it means for a schedule to change from periodic to calendar, or vice versa, or from either of these values to one-shot. The agent's behavior should be pretty easy to describe in these cases: changing a schedule's type is equivalent to deleting the old-type schedule and creating a new-type one. But why would a management application, or an operator using a management application, ever want to do this? A plausible example (not here, but back in the Usage Examples section) would be helpful. 9. schedLastFailed object: The term "the scheduler" is never defined in the document, so the meaning of this object is unclear. You should define the scheduler as something like "the entity that implements support for the schedMIB". 10. comments before schedTraps OID (p.13): These comments refer to an object schedMIBTraps that's not in the module. I can't find any entry in the change logs stating that an object with this name was removed from the MIB, so I'm not sure what's going on. 11. schedActionFailure notification: since you have it defined, why not include schedLastFailed in the notification as well? Then the last error and when it happened will be together in the VarBindList, so the trap receiver won't have to try to figure out the time associated with a failure. 12. section 5.1, second paragraph: you introduce the term "launch button" here in the examples. You should either remove it from here, or define it earlier in the document. 13. section 6, fourth paragraph ("This MIB limits...."): In the last sentence, change "...it is suggested that entries in the schedTable be cleaned up..." to "...entries in the schedTable SHOULD be cleaned up...", to align with RFC 2119. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com From maria@xedia.com Tue Aug 4 19:49:05 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id TAA09014 for ; Tue, 4 Aug 1998 19:48:30 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id TAA01542 for ; Tue, 4 Aug 1998 19:46:46 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma001529; Tue, 4 Aug 98 19:46:23 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id TAA20390 for ; Tue, 4 Aug 1998 19:45:33 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020195; Tue, 4 Aug 98 19:44:34 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id TAA04303; Tue, 4 Aug 1998 19:44:18 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id RAA18684 for ; Tue, 4 Aug 1998 17:43:31 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id TAA01440 for ; Tue, 4 Aug 1998 19:43:15 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma001431; Tue, 4 Aug 98 19:43:03 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id UAA28455 for ; Tue, 4 Aug 1998 20:18:57 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id UAA12819 for ; Tue, 4 Aug 1998 20:18:55 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id TAA00665 for ; Tue, 4 Aug 1998 19:18:52 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma000657; Tue, 4 Aug 98 19:18:46 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id TAA11076 for ; Tue, 4 Aug 1998 19:18:11 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma010905; Tue, 4 Aug 98 19:17:43 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id TAA00171; Tue, 4 Aug 1998 19:18:13 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA18555; Tue, 4 Aug 1998 17:18:12 -0700 (PDT) Date: Tue, 4 Aug 1998 17:18:12 -0700 (PDT) From: Randy Presuhn Message-Id: <199808050018.RAA18555@dorothy.bmc.com> To: disman@nexen.com, remoore@us.ibm.com Subject: Re: WG Last Call: schedule MIB Cc: Harald.Alvestrand@maxware.no, levi@snmp.com, schoenw@ibr.cs.tu-bs.de, wijnen@VNET.IBM.COM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Bob - Thank-you for the lightning-fast review. Can we trim the CC list to just for the follow-up discussion? ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From maria@xedia.com Wed Aug 5 09:15:06 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id JAA15102 for ; Wed, 5 Aug 1998 09:15:06 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id JAA01540 for ; Wed, 5 Aug 1998 09:13:44 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma001516; Wed, 5 Aug 98 09:13:28 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id JAA27524 for ; Wed, 5 Aug 1998 09:12:52 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma026890; Wed, 5 Aug 98 09:12:21 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id JAA29322; Wed, 5 Aug 1998 09:12:54 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA21076 for ; Wed, 5 Aug 1998 07:12:45 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id JAA10956 for ; Wed, 5 Aug 1998 09:12:43 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma010924; Wed, 5 Aug 98 09:12:19 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id JAA07884 for ; Wed, 5 Aug 1998 09:47:21 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id JAA12797 for ; Wed, 5 Aug 1998 09:47:21 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA03536; Wed, 5 Aug 1998 09:47:18 -0400 (EDT) Message-Id: <199808051347.JAA03536@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@nexen.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-notif-log-mib-03.txt Date: Wed, 05 Aug 1998 09:47:17 -0400 Sender: cclark@ns.cnri.reston.va.us --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 : Notification Log MIB Author(s) : B. Stewart Filename : draft-ietf-disman-notif-log-mib-03.txt Pages : 21 Date : 04-Aug-98 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 used for logging SNMP Notifications. Internet-Drafts are 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-notif-log-mib-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-notif-log-mib-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-notif-log-mib-03.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: <19980804110107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-notif-log-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-notif-log-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980804110107.I-D@ietf.org> --OtherAccess-- --NextPart-- From maria@xedia.com Wed Aug 5 11:24:34 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id LAA16755 for ; Wed, 5 Aug 1998 11:24:34 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA16151 for ; Wed, 5 Aug 1998 11:23:12 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma016005; Wed, 5 Aug 98 11:22:23 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA14308 for ; Wed, 5 Aug 1998 11:21:47 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma013854; Wed, 5 Aug 98 11:21:21 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA07587; Wed, 5 Aug 1998 11:21:54 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA21363 for ; Wed, 5 Aug 1998 09:21:52 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA15965 for ; Wed, 5 Aug 1998 11:21:51 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by almond.bmc.com via smap (V2.0) id xma015862; Wed, 5 Aug 98 11:21:22 -0500 Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id LAA10103 for ; Wed, 5 Aug 1998 11:43:08 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id LAA13851 for ; Wed, 5 Aug 1998 11:43:07 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.1/8.9.0) with ESMTP id RAA26750; Wed, 5 Aug 1998 17:43:05 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA06429; Wed, 5 Aug 1998 17:43:03 +0200 Date: Wed, 5 Aug 1998 17:43:03 +0200 Message-Id: <199808051543.RAA06429@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: remoore@us.ibm.com, levi@snmp.com CC: disman@nexen.com In-reply-to: <85256655.0080331D.00@us.ibm.com> (remoore@us.ibm.com) Subject: Re: WG Last Call: schedule MIB References: <85256655.0080331D.00@us.ibm.com> >>>>> Bob Moore writes: Bob> I had just finished a first pass through the Schedule MIB for Bob> the Area review that Bert had requested, when I noticed that Bob> there was going to be an additional draft to accommodate Bob> comments received during Disman WG last call. Rather than Bob> waiting, I'll provide my initial comments now, so that the WG Bob> will have a chance to react to them, and the editors may be Bob> able to incorporate their responses into the next draft. Bob, thanks for your comments. Below are the changes I propose to address your comments. To everyone on this list: please let us know ASAP if you have problems with the proposed action or if you have better proposals. The ID cutoff is approaching pretty fast... Bob> 1. "SHALL" / "SHOULD" paragraph, reference to RFC 2119 Bob> missing. The paragraph is usually placed as the last Bob> paragraph in the "Introduction" section. Proposal: Add the relevant text from RFC 2119. Bob> 2. Section 3, first paragraph: "...or trigger management Bob> functions in a DISMAN application." What *is* "a DISMAN Bob> application"? If it's just an abbreviation for "a Bob> distributed management application", then fine: just remove Bob> the abbreviation. If, however, there's something more to it Bob> (e.g., "the kind of application we've been discussing in the Bob> DISMAN WG"), then you need to spell out this additional Bob> meaning. Proposal: Replace "DISMAN application" with "distributed management application". Bob> 3. Section 3.2: two points should be clarified: Bob> - these schedules do *not* provide for "specified dates Bob> and times", in the way that the DateAndTime TC does: they Bob> provide for specified days of the week and days of the month, Bob> but not for specified dates. If you add the capability for Bob> the one-shot schedule, you'll have to be especially clear Bob> that even this doesn't provide for scheduling an action on a Bob> specified date. Proposal: Need to put in better wordings as suggested. Bob> - the central semantics of the scheduling objects need to Bob> be spelled out, both here and in the objects' DESCRIPTIONS: Bob> the mask bits in each individual objects are OR-ed, and the Bob> values from the five objects are then AND-ed. I was able to Bob> infer these semantics from the examples, but they need to be Bob> spelled out explicitly. Proposal: Text needs to be added to section 3.2 and the DESCRIPTION clauses to clarify this. Bob> 4. SnmpPduErrorStatus TC Description, possibly other places: Bob> check the encoding for the opening single quote character, Bob> e.g., in 'noResponse'. This doesn't display correctly for Bob> me, and it doesn't print at all. Proposal: No action. The character is ASCII code 60 (hexadecimal) and it is used in MIBs that are already standards (e.g. RFC 1213). Maybe this is a problem with your local editor or mail reader? Can you read and print RFC 1213? Bob> 5. schedInterval object: how about a DEFVAL of 0, meaning Bob> don't perform the action at all? This would match the Bob> DEFVALs for the five calendar objects, and would provide for Bob> uniform agent behavior for entries that are created as Bob> calendar schedules and are then changed to periodic. Proposal: Add the DEFVAL 0 and add text which defines the special semantics of the value 0. Bob> 6. schedDay object: when I worked on ISO 10164-20 ITU Bob> Rec. X.743, we included the capability to count days backward Bob> from the end of the month, in addition to counting them Bob> forward from the beginning. It would be easy to extend the Bob> enumeration in this object to add this capability: Bob> BITS { d1(0), d2(1), d3(2), d4(3), d5(4), d6(5), d7(6), Bob> d8(7), d9(8), d10(9), d11(10), d12(11), d13(12), d14(13), Bob> d15(14), d16(15), d17(16), d18(17), d19(18), d20(19), Bob> d21(20), d22(21), d23(22), d24(23), d25(24), d26(25), Bob> d27(26), d28(27), d29(28), d30(29), d31(30), e1(31), e2(32), Bob> e3(33), e4(34), e5(35), e6(36), e7(37), e8(38), e9(39), Bob> e10(40), e11(41), e12(42), e13(43), e14(44), e15(45), Bob> e16(46), e17(47), e18(48), e19(49), e20(50), e21(51), Bob> e22(52), e23(53), e24(54), e25(55), e26(56), e27(57), Bob> e28(58), e29(59), e30(60), e31(61) } Bob> Before you dismiss this as needlessly complicated, think Bob> carefully about whether there will be a requirement to Bob> trigger an action at, say, 5:00 PM on the last day of every Bob> month. Proposal: Add this new feature. Bob> 7. schedAdminStatus object: At first glance the enumeration Bob> values for this object look peculiar. You're combining both Bob> the "traditional" AdminStatus values (enabled / disabled) and Bob> values I'd expect to see in an object named "schedType". One Bob> implication of this approach is that if an entry's Admin Bob> Status is set to 'disabled' (and its Oper Status follows Bob> suit), the entry "forgets" whether it was a periodic schedule Bob> or a calendar schedule (or a one-shot schedule, if you add Bob> that as a third option). Maybe this is exactly what you Bob> intended, but to me the type of a schedule is distinct from Bob> whether the schedule is currently enabled, so I'd expect to Bob> see the two represented with separate objects. Proposal: Add a new object schedType and change the schedAdminStatus schedOperStatus enumeration to enabled/disabled. Bob> 8. schedAdminStatus object: Regardless of how the previous Bob> issue is resolved, there's a question about what it means for Bob> a schedule to change from periodic to calendar, or vice Bob> versa, or from either of these values to one-shot. The Bob> agent's behavior should be pretty easy to describe in these Bob> cases: changing a schedule's type is equivalent to deleting Bob> the old-type schedule and creating a new-type one. But why Bob> would a management application, or an operator using a Bob> management application, ever want to do this? A plausible Bob> example (not here, but back in the Usage Examples section) Bob> would be helpful. Proposal: Add text which says that the effect is equivalent to to deleting the old-type schedule and creating a new-type one. Bob> 9. schedLastFailed object: The term "the scheduler" is never Bob> defined in the document, so the meaning of this object is Bob> unclear. You should define the scheduler as something like Bob> "the entity that implements support for the schedMIB". Proposal: The term scheduler is used in many places of the document. Add text to section to section 3 which defines the term scheduler. Bob> 10. comments before schedTraps OID (p.13): These comments Bob> refer to an object schedMIBTraps that's not in the module. I Bob> can't find any entry in the change logs stating that an Bob> object with this name was removed from the MIB, so I'm not Bob> sure what's going on. Proposal: Replace schedMIBTraps with schedTraps. Bob> 11. schedActionFailure notification: since you have it Bob> defined, why not include schedLastFailed in the notification Bob> as well? Then the last error and when it happened will be Bob> together in the VarBindList, so the trap receiver won't have Bob> to try to figure out the time associated with a failure. Proposal: Add schedLastFailed to the schedActionFailure notification. Bob> 12. section 5.1, second paragraph: you introduce the term Bob> "launch button" here in the examples. You should either Bob> remove it from here, or define it earlier in the document. Proposal: Rewrite the text to use the MIB names defined in the Script MIB instead of the phrase "launch button". Bob> 13. section 6, fourth paragraph ("This MIB limits...."): In Bob> the last sentence, change "...it is suggested that entries in Bob> the schedTable be cleaned up..." to "...entries in the Bob> schedTable SHOULD be cleaned up...", to align with RFC 2119. Proposal: Use SHOULD as suggested. Juergen -- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) From maria@xedia.com Wed Aug 5 12:47:45 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA18470 for ; Wed, 5 Aug 1998 12:47:44 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA22858 for ; Wed, 5 Aug 1998 12:46:19 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma022848; Wed, 5 Aug 98 12:46:17 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA29015 for ; Wed, 5 Aug 1998 12:45:41 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma028852; Wed, 5 Aug 98 12:45:29 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA29477; Wed, 5 Aug 1998 12:45:18 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA22863 for ; Wed, 5 Aug 1998 10:45:16 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id MAA25403 for ; Wed, 5 Aug 1998 12:45:14 -0500 (CDT) Received: from maelstrom.nexen.com(204.249.99.5) by cashew.bmc.com via smap (V2.0) id xma025391; Wed, 5 Aug 98 12:45:02 -0500 Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom (8.8.5/8.7.3) with ESMTP id NAA12876 for ; Wed, 5 Aug 1998 13:20:35 -0400 (EDT) Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id NAA19010 for ; Wed, 5 Aug 1998 13:20:33 -0400 (EDT) Received: from relay3.server.ibm.com (relay3.server.ibm.com [9.14.2.100]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id NAA31222; Wed, 5 Aug 1998 13:09:12 -0400 Received: from US.IBM.COM (d04lms02.raleigh.ibm.com [9.37.164.194]) by relay3.server.ibm.com (8.8.7/8.8.7) with SMTP id NAA103440; Wed, 5 Aug 1998 13:14:01 -0400 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU006 id 5040200017864676; Wed, 5 Aug 1998 13:30:20 -0400 From: Robert Moore To: Cc: , Message-ID: <5040200017864676000002L062*@MHS> Date: Wed, 5 Aug 1998 13:30:20 -0400 MIME-Version: 1.0 Content-Type: text/plain Juergen, > Bob> 4. SnmpPduErrorStatus TC Description, possibly other places: > Bob> check the encoding for the opening single quote character, > Bob> e.g., in 'noResponse'. This doesn't display correctly for > Bob> me, and it doesn't print at all. > > Proposal: No action. The character is ASCII code 60 (hexadecimal) and > it is used in MIBs that are already standards (e.g. RFC 1213). Maybe > this is a problem with your local editor or mail reader? Can you read > and print RFC 1213? I'm certainly not going to hold an extended argument about which quote character to use in DESCRIPTION text, but...I did look at RFC 1213, and it gives me exactly the same problem that your draft does. Looking at other RFCs, I find two practices (although there are probably more): RFC 1213, your draft, RFC 2271, ...: > ASCII 60 for open single quote > ASCII 27 for close single quote, open / close hex (e.g., DEFVAL {''H}), possessive, apostrophe (O'Dell, for example) RFC 2273, RFC 2274, any RFC I've edited (OK, maybe that's cheating:-): > ASCII 27 for all of these, including open single quote I'm not going to lose sleep over this either way. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com From maria@xedia.com Wed Aug 5 16:40:54 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA23255 for ; Wed, 5 Aug 1998 16:40:53 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA07334 for ; Wed, 5 Aug 1998 16:39:29 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma007125; Wed, 5 Aug 98 16:38:39 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA19852 for ; Wed, 5 Aug 1998 16:38:00 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma018712; Wed, 5 Aug 98 16:36:54 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA28270; Wed, 5 Aug 1998 16:37:22 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA06142 for ; Wed, 5 Aug 1998 14:37:18 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id QAA10576 for ; Wed, 5 Aug 1998 16:37:13 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by cashew.bmc.com via smap (V2.0) id xma010565; Wed, 5 Aug 98 16:36:37 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id RAA01056; Wed, 5 Aug 1998 17:28:48 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.Nexen.COM (8.8.5/8.7.3) with ESMTP id PAA15335 for ; Wed, 5 Aug 1998 15:22:07 -0400 (EDT) Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id PAA21693 for ; Wed, 5 Aug 1998 15:22:05 -0400 (EDT) Received: from tootsie.cisco.com (tootsie.cisco.com [171.69.128.44]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id MAA15505 for ; Wed, 5 Aug 1998 12:21:55 -0700 (PDT) Message-Id: <3.0.5.32.19980805152130.007c5df0@zipper.cisco.com> X-Sender: bstewart@zipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 05 Aug 1998 15:21:30 -0400 To: Distributed Management WG From: Bob Stewart Subject: Internet Draft - Event MIB Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Here is a new draft of the Event MIB as submitted to become draft-ietf-disman-event-mib-04.txt. This draft has the following changes from the previous draft: Updated boilerplate. Added a real overview, including security operation. Added the compliance section. Fixed various typos and made various clarifications. Added a table of trigger-related objects that can be added to a Notification resulting from a trigger or event. Added SNMP error conditions to FailureReason textual convention. Reconsidered the error handling objects and moved them to a notfication-only section. Bob --------------- Internet Draft Event MIB 5 August 1998 Event MIB 5 August 1998 draft-ietf-disman-event-mib-04.txt Bob Stewart Cisco Systems, Inc. bstewart@cisco.com Status of this Memo This document is an Internet-Draft. 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.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Please send comments to the Distributed Management Working Group, . Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Expires 5 August 1998+6 months [Page 1] Internet Draft Event MIB 5 August 1998 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 used for managing monitoring of MIB objects and taking action through events. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. 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 RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. 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 Expires 5 August 1998+6 months [Page 2] Internet Draft Event MIB 5 August 1998 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. Expires 5 August 1998+6 months [Page 3] Internet Draft Event MIB 5 August 1998 3. Overview With network sizes well beyond the ability of people to management their networks 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. All of these components must 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 [16] and its alarm and event groups and is intended as a replacement for those groups. 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 [17] which was declared Historic pending this work. The Event MIB depends on the services of the SNMPv3 Management Target and Notification MIBs [14]. The Event MIB is nicely complemented by the Distributed Management Expression MIB [18], which is the expected source of boolean objects to monitor. 5. MIB Sections The MIB has three sections, triggers, events, and notifications. Triggers define the conditions that lead to events. Events may cause notifications. The trigger table lists what objects are to be monitored and how and relates each trigger to an event. In the same section the trigger Expires 5 August 1998+6 months [Page 4] Internet Draft Event MIB 5 August 1998 object table lists trigger-related objects that can be added to notifications either for a trigger or for an event. The event table defines what happens when an event is triggered, sending a notificaiton, setting a MIB object or both. The notification section defines a set of generic notifications to go with the events and for Event MIB error handlling, and it defines a set of objects to put in those notifications. 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 to select and access remote systems as an ordinary SNMP-based management application. Local monitoring may be be a more intimate, local interface which may, for example, bypass SNMP formatting but otherwise is functionally identical to remote SNMP operation. A self-management only system may not implemenet 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. Error handling is by notification, which at first thought violates the principle that notifications may be lost or become a crippling burden, but the intent is that such error notifications be enabled only for the diagnosis of problems indicated by error counters and if the notifications are being lost they be directed to the log as described in the Notification Log MIB [19]. 7. Security Security of Event MIB entries depends on SNMPv3 access control for the entire MIB or for subsets based on substrings of trigger and event names. Expires 5 August 1998+6 months [Page 5] Internet Draft Event MIB 5 August 1998 Security of monitored objects for remote access depends on the Management Target MIB. 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. Expires 5 August 1998+6 months [Page 6] Internet Draft Event MIB 5 August 1998 8. Definitions EVENT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, experimental, Integer32, Unsigned32 NOTIFICATION-TYPE FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, TimeStamp, DisplayString FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpTagValue FROM SNMP-TARGET-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB; eventMIB MODULE-IDENTITY LAST-UPDATED "9808051700Z" ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 526 4527 Email: bstewart@cisco.com" DESCRIPTION "The MIB module for defining event triggers and actions for network management purposes." ::= { experimental xx } eventMIBObjects OBJECT IDENTIFIER ::= { eventMIB 1 } mteTrigger OBJECT IDENTIFIER ::= { eventMIBObjects 1 } mteEvent OBJECT IDENTIFIER ::= { eventMIBObjects 2 } -- -- Textual Conventions -- FailureReason ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Reasons for failures in an attempt to send a management message. The first group of errors, numbered less than 100, are copied directly from SNMP protocol operations and are intended to carry exactly the meanings defined for the protocol as returned in Expires 5 August 1998+6 months [Page 7] Internet Draft Event MIB 5 August 1998 an SNMP response. Those numbered 100 or greater are related to problems in sending the request." SYNTAX INTEGER { tooBig(1), noSuchName(2), badValue(3), 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), localResourceLack(101), badDestination(102), noAck(103) } -- -- Trigger Section -- -- Counters mteTriggerFailures OBJECT-TYPE SYNTAX Counter32 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 } -- Expires 5 August 1998+6 months [Page 8] Internet Draft Event MIB 5 August 1998 -- 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 "Information about a single trigger. Applications create and delete entries using mteTriggerStatus." INDEX { IMPLIED mteTriggerName } ::= { mteTriggerteble 1 } MteTriggerEntry ::= SEQUENCE { mteTriggerName SnmpAdminString, mteTriggerComment DisplayString, mteTriggerTest INTEGER, mteTriggerValueID Integer32, mteTriggerValueIDWildcard TruthValue, mteTriggerTargetTag SnmpTagValue, mteTriggerContextName SnmpAdminString, mteTriggerContextNameWildcard TruthValue, mteTriggerFrequency Integer32, mteTriggerBooleanStartup INTEGER, mteTriggerThresholdStartup INTEGER, mteTriggerRisingThreshold Integer32, mteTriggerFallingThreshold Integer32, mteTriggerEvent SnmpAdminString, mteTriggerRisingEvent SnmpAdminString, mteTriggerFallingEvent SnmpAdminString, mteTriggerObjects SnmpAdminString, mteTriggerStatus RowStatus } mteTriggerName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..64)) MAX-ACCESS not-accessible STATUS current Expires 5 August 1998+6 months [Page 9] Internet Draft Event MIB 5 August 1998 DESCRIPTION "A locally-unique, administratively assigned name for the trigger." ::= { mteTriggerEntry 1 } mteTriggerComment OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "A description of the trigger's function and use." DEFVAL { ''H } ::= { mteTriggerEntry 2 } mteTriggerTest OBJECT-TYPE SYNTAX INTEGER { boolean(1), threshold(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of trigger test to perform. For all tests, mteTriggerValue must evaluate to an integer. For 'boolean', a value of 0 is false. A non-zero value is true and fires the trigger. The trigger will not fire again until the value has become false and come back to true. For 'threshold' it works as described below for mteTriggerThresholdStartup, mteTriggerRisingThreshold, and mteTriggerFallingThreshold." DEFVAL { boolean } ::= { mteTriggerEntry 3 } mteTriggerValueID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The object identifier of the MIB object to check to see if the trigger should fire. This may be wildcarded by truncating all or part of the instance portion, in which case the condition is obtained as if with a GetNext function, checking multiple values if they exist. If such wildcarding is applied, mteTriggerIDWildcard must be 'true' and if not it must Expires 5 August 1998+6 months [Page 10] Internet Draft Event MIB 5 August 1998 be 'false'." DEFVAL { 0 0 } ::= { mteTriggerEntry 4 } 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 5 } 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. Systems limited to self management may not accept 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 mteTriggerValueID is under the security credentials of the requester that set mteTriggerStatus to 'active'." DEFVAL { ''H } ::= { mteTriggerEntry 6 } mteTriggerContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The management context from which to obtain mteTriggerValueID. This may be wildcarded by leaving characters off the end. To indicate such wildcarding mteTriggerContextNameWildcard must be 'true'." DEFVAL { ''H } ::= { mteTriggerEntry 7 } Expires 5 August 1998+6 months [Page 11] Internet Draft Event MIB 5 August 1998 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 8 } mteTriggerFrequency OBJECT-TYPE SYNTAX Integer32 (0..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds to wait between trigger condition checks. 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. If the next check begins before the previous one completed the system may either attempt to make the check or treat this as an error condition. A frequency of 0 indicates instantaneous recognition of the condition. This is not possible in many cases, but such may be supported in cases where it makes sense and the system is able to do so." DEFVAL { 600 } ::= { mteTriggerEntry 9 } mteTriggerBooleanStartup OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Control for whether an event may be triggered when this entry is first set to 'active'. If the value mteTriggerBooleanStartup is 'true' and the first sample after this entry becomes active is true then one mteTriggerEvent is triggered. If mteTriggerType is not 'boolean', this object is not instantiated." Expires 5 August 1998+6 months [Page 12] Internet Draft Event MIB 5 August 1998 DEFVAL { true } ::= { mteTriggerEntry 10 } mteTriggerThresholdStartup OBJECT-TYPE SYNTAX INTEGER { rising(1), falling(2), risingOrFalling(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The event that may be triggered when this entry is first set to 'active'. If the first sample after this entry becomes active is greater than or equal to mteTriggerRisingThreshold and mteTriggerThresholdStartup is equal to 'rising' or 'risingOrFalling', then one mteTriggerRisingEvent is triggered. If the first sample after this entry becomes active is less than or equal to mteTriggerFallingThreshold and mteTriggerThresholdStartup is equal to 'falling' or 'risingOrFalling', then one mteTriggerRisingEvent is triggered. If mteTriggerType is not 'threshold', this object is not instantiated." DEFVAL { risingOrFalling } ::= { mteTriggerEntry 11 } mteTriggerRisingThreshold OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create 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 mteTriggerRisingEvent is triggered. That event is also triggered if the first sample afer this entry bcomes 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 mteTriggerFallingThreshold. If mteTriggerType is not 'threshold', this object is not Expires 5 August 1998+6 months [Page 13] Internet Draft Event MIB 5 August 1998 instantiated." DEFVAL { 0 } ::= { mteTriggerEntry 12 } mteTriggerFallingThreshold OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create 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 mteTriggerFallingEvent is triggered. That event is also triggered if the first sample afer this entry bcomes 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 mteTriggerRisingThreshold. If mteTriggerType is not 'threshold', this object is not instantiated." DEFVAL { 0 } ::= { mteTriggerEntry 13 } mteTriggerEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..64)) MAX-ACCESS read-create STATUS current DESCRIPTION "The event to invoke when mteTriggerType is 'boolean' and this trigger fires. A length of 0 indicates no event. If mteTriggerType is not 'boolean', this object is not instantiated." DEFVAL { ''H } ::= { mteTriggerEntry 14 } mteTriggerRisingEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..64)) MAX-ACCESS read-create Expires 5 August 1998+6 months [Page 14] Internet Draft Event MIB 5 August 1998 STATUS current DESCRIPTION "The event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerRisingThreshold. A value of 0 indicates no event. If mteTriggerType is not 'threshold', this object is not instantiated." DEFVAL { ''H } ::= { mteTriggerEntry 15 } mteTriggerFallingEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..64)) MAX-ACCESS read-create STATUS current DESCRIPTION "The event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerFallingThreshold. A value of 0 indicates no event. If mteTriggerType is not 'threshold', this object is not instantiated." DEFVAL { ''H } ::= { mteTriggerEntry 16 } mteTriggerObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..64)) MAX-ACCESS read-create STATUS current DESCRIPTION "The mteTriggerObjectNName of a group of objects from mteTriggerObjectTable. These objects are to be added to any Notification resulting from the firing of this trigger. A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteTriggerEntry 17 } mteTriggerStatus 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 Expires 5 August 1998+6 months [Page 15] Internet Draft Event MIB 5 August 1998 delete it." DEFVAL { createAndWait } ::= { mteTriggerEntry 18 } -- -- Trigger Object Table -- mteTriggerObjectTable OBJECT-TYPE SYNTAX SEQUENCE OF mteTriggerObjectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects related to a trigger and to be added to Notifications resulting from that trigger." ::= { mteTrigger 3 } mteTriggerObjectEntry OBJECT-TYPE SYNTAX mteTriggerObjectEntry MAX-ACCESS not-accessible STATUS current "Objects for a single trigger. Applications create and delete entries using mteTriggerObjectStatus." INDEX { mteTriggerObjectName, mteTriggerObjectIndex } ::= { mteTriggerObjectteble 1 } mteTriggerObjectEntry ::= SEQUENCE { mteTriggerObjectName SnmpAdminString, mteTriggerObjectIndex Unsigned32, mteTriggerObjectID Integer32, mteTriggerObjectIDWildcard TruthValue, mteTriggerObjectStatus RowStatus } mteTriggerObjectName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..64)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-unique, administratively assigned name for a group of objects to associate with a trigger." ::= { mteTriggerObjectEntry 1 } mteTriggerObjectIndex OBJECT-TYPE Expires 5 August 1998+6 months [Page 16] Internet Draft Event MIB 5 August 1998 SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary small integer for the purpose of identifying individual objects with a mteTriggerObjectName group." ::= { mteTriggerObjectEntry 2 } mteTriggerObjectID 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 mteTriggerObjectValueID that fired. If such wildcarding is applied, mteTriggerObjectIDWildcard must be 'true' and if not it must be 'false'." DEFVAL { 0 0 } ::= { mteTriggerObjectEntry 3 } mteTriggerObjectValueIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Control for whether mteTriggerObjectValueID is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard. DEFVAL { false } ::= { mteTriggerObjectEntry 4 } mteTriggerObjectStatus 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." DEFVAL { createAndWait } ::= { mteTriggerObjectEntry 5 } Expires 5 August 1998+6 months [Page 17] Internet Draft Event MIB 5 August 1998 -- -- 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." ::= { 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 mteEventStatus." INDEX { IMPLIED mteEventName } ::= { mteEventTable 1 } MteEventEntry ::= SEQUENCE { mteEventName SnmpAdminString, mteEventComment DisplayString, mteEventActions BITS, mteEventNotification OBJECT IDENTIFIER, Expires 5 August 1998+6 months [Page 18] Internet Draft Event MIB 5 August 1998 mteEventObjects SnmpAdminString, mteEventSetObject OBJECT IDENTIFIER, mteEventSetObjectWildcard TruthValue, mteEventSetValue Integer32, mteEventSetTargetTag SnmpTagValue, mteEventSetContextName SnmpAdminString, mteEventSetContextNameWildcard TruthValue, mteEventStatus RowStatus } mteEventName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..64)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-unique, administratively assigned name for the event." ::= { mteEventCreationEntry 1 } mteEventComment OBJECT-TYPE SYNTAX DisplayString 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, set } MAX-ACCESS read-create STATUS current DESCRIPTION "The actions to peform when this event occurs. 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 { 0 } ::= { mteEventEntry 3 } mteEventNotification OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create Expires 5 August 1998+6 months [Page 19] Internet Draft Event MIB 5 August 1998 STATUS current DESCRIPTION "The object identifier from the NOTIFICATION-TYPE for the notification to use if metEventActions has 'notification' set. If 'notification' is not set, this object is not instantiated." DEFVAL { 0 0 } ::= { mteEventEntry 4 } mteEventObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..64)) MAX-ACCESS read-create STATUS current DESCRIPTION "The mteTriggerObjectName of a group of objects from mteTriggerObjectTable if mteEventActions has 'notification' set. These objects are to be added to any Notification generated by this event. If 'notification' is not set, this object is not instantiated. A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteEventEntry 5 } mteEventSetObject OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "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 it is the same as the instance for the value of mteTriggerValueID that triggered the event." If 'set' is not set, this object is not instantiated." DEFVAL { 0 0 } ::= { mteEventEntry 6 } Expires 5 August 1998+6 months [Page 20] Internet Draft Event MIB 5 August 1998 mteEventSetObjectWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create 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. If 'set' is not set, this object is not instantiated." DEFVAL { false } ::= { mteEventEntry 7 } mteEventSetValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The value to which to set the object at mteEventSetObject if mteEventActions has 'set' set. If 'set' is not set, this object is not instantiated." DEFVAL { 0 } ::= { mteEventEntry 8 } mteEventSetTargetTag OBJECT-TYPE SYNTAX SnmpTagValue MAX-ACCESS read-create STATUS current DESCRIPTION "The tag for the target(s) at which to set the object at mteEventSetObject to mteEventSetValue if mteEventActions has 'set' set. If 'set' is not set, this object is not instantiated." Systems limited to self management may not accept 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 mteEventObjectID is under the security credentials of the requester that set mteEventStatus to 'active'." DEFVAL { ''H } ::= { mteEventEntry 9 } Expires 5 August 1998+6 months [Page 21] Internet Draft Event MIB 5 August 1998 mteEventSetContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The management context in which to set mteEventObjectID. if mteEventActions has 'set' set. If 'set' is not set, this object is not instantiated." 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 } ::= { mteEventEntry 10 } mteEventSetContextNameWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create 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. If 'set' is not set, this object is not instantiated." DEFVAL { false } ::= { mteTriggerEntry 10 } mteEventStatus 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." DEFVAL { createAndWait } ::= { mteEventEntry 12 } -- Expires 5 August 1998+6 months [Page 22] Internet Draft Event MIB 5 August 1998 -- Notifications -- eventMIBNotificationPrefix OBJECT IDENTIFIER ::= { eventMIB 2 } eventMIBNotifications OBJECT IDENTIFIER ::= { eventMIBNotificationPrefix 0 } eventMIBNotificationObjectss OBJECT IDENTIFIER ::= { eventMIBNotificationPrefix 1 } -- -- Notification Objects -- mteHotTrigger OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The name of the trigger causing the notification. ::= { mteTrigger 1 } mteHotTargetName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The SNMP Target MIB's snmpTargetAddrName related to the notification. ::= { mteTrigger 2 } mteHotContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The context name related to the notification. This must be as fully-qualified as possible, inluding filling in wildcard informaation determined in processing." ::= { mteTrigger 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 Expires 5 August 1998+6 months [Page 23] Internet Draft Event MIB 5 August 1998 notification. This must be as fully-qualified as possible, inluding filling in wildcard informaation determined in processing. For a trigger-related notification this is from mteTriggerValueID. For a set failure this is from mteEventSetObject." ::= { mteTrigger 3 } mterHotValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The value of the object at mteTriggerValueID when a trigger fired." ::= { mteTrigger 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. ::= { mteTrigger 6 } -- -- Notifications -- mteTriggerSenseAlarm 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'." ::= { eventMIBNotifications 1 } mteTriggerRisingAlarm NOTIFICATION-TYPE OBJECTS { mteHotTrigger, Expires 5 August 1998+6 months [Page 24] Internet Draft Event MIB 5 August 1998 mteHotTargetName, mteHotContextName, mteHotOID, mteHotValue } STATUS current DESCRIPTION "Notification that the rising threshold was met for triggers with mteTriggerType 'threshold'." ::= { eventMIBNotifications 2 } mteTriggerFallingAlarm NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteHotValue } STATUS current DESCRIPTION "Notification that the falling threshold was met for triggers with mteTriggerType 'threshold'." ::= { eventMIBNotifications 3 } mteTriggerFailureAlarm NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteFailedReason } STATUS current DESCRIPTION "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." ::= { eventMIBNotifications 4 } mteEventSetFailureAlarm NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteFailedReason } Expires 5 August 1998+6 months [Page 25] Internet Draft Event MIB 5 August 1998 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." ::= { eventMIBNotifications 5 } -- -- Conformance -- eventMIBConformance OBJECT IDENTIFIER ::= { eventMIB 3 } eventMIBCompliances OBJECT IDENTIFIER ::= { eventMIBConformance 1 } eventMIBGroups OBJECT IDENTIFIER ::= { eventMIBConformance 2 } -- Compliance eventMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Event MIB." MODULE -- this module MANDATORY-GROUPS { eventTriggerGroup, eventEventGroup, eventNotificationObjectGroup, eventNotificationGroup } OBJECT mteTriggerTargetTag MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus limiting monitoring to the local system or preconfigured remote systems."" OBJECT mteEventSetTargetTag MIN-ACCESS read-only Expires 5 August 1998+6 months [Page 26] Internet Draft Event MIB 5 August 1998 DESCRIPTION "Write access is not required, thus limiting setting to the local system or preconfigured 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 mteTriggerObjectValueIDWildcard MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus allowing the system not to implement wildcarding." OBJECT mteEventSetContextNameWildcard MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus allowing the system not to implement wildcarding." ::= { eventMIBCompliances 1 } -- Units of Conformance eventTriggerGroup OBJECT-GROUP OBJECTS { mteTriggerFailures, mteTriggerComment, mteTriggerTest, mteTriggerValueID, mteTriggerValueIDWildcard, mteTriggerTargetTag, mteTriggerContextName, mteTriggerContextNameWildcard, Expires 5 August 1998+6 months [Page 27] Internet Draft Event MIB 5 August 1998 mteTriggerFrequency, mteTriggerBooleanStartup, mteTriggerThresholdStartup, mteTriggerRisingThreshold, mteTriggerFallingThreshold, mteTriggerEvent, mteTriggerRisingEvent, mteTriggerFallingEvent, mteTriggerObjects, mteTriggerStatus, mteTriggerObjectID, mteTriggerObjectIDWildcard, mteTriggerObjectStatus } STATUS current DESCRIPTION "Event triggers and supplemental objects." ::= { eventMIBGroups 1 } eventEventGroup OBJECT-GROUP OBJECTS { mteEventComment, mteEventActions, mteEventNotification, mteEventObjects, mteEventSetObject, mteEventSetObjectWildcard, mteEventSetValue, mteEventSetTargetTag, mteEventSetContextName, mteEventSetContextNameWildcard, mteEventStatus } STATUS current DESCRIPTION "Events." ::= { eventMIBGroups 2 } eventNotificationObjectGroup OBJECT-GROUP OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, Expires 5 August 1998+6 months [Page 28] Internet Draft Event MIB 5 August 1998 mterHotValue, mteFailedReason } STATUS current DESCRIPTION "Notification objects." ::= { eventMIBGroups 3 } eventNotificationGroup OBJECT-GROUP OBJECTS { mteTriggerSenseAlarm, mteTriggerRisingAlarm, mteTriggerFallingAlarm, mteTriggerFailureAlarm, mteEventSetFailureAlarm } STATUS current DESCRIPTION "Notifications." ::= { eventMIBGroups 4 } END Expires 5 August 1998+6 months [Page 29] Internet Draft Event MIB 5 August 1998 9. Acknowledgements This MIB contains considerable contributions from the RMON MIB, the Distributed Management Design Team (Andy Bierman, Maria Greene, Bob Stewart, and Steve Waldbusser), and colleagues at Cisco. Expires 5 August 1998+6 months [Page 30] Internet Draft Event MIB 5 August 1998 10. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998 [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991 [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. Expires 5 August 1998+6 months [Page 31] Internet Draft Event MIB 5 August 1998 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, January 1998 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., Cisco Systems, Inc., January 1998 [16] Waldbusser, S., "Remote Network Monitoring Management Information Base", RFC 1757, International Network Services, February 1995 [17] Case, J., McCloghrie, K., Rose, M., Waldbusser, S., "Manager-to- Manager Management Information Base", RFC 1451, SNMP Research, Inc., Cisco SYSTEMS< Inc., Dover Beach Consulting, Inc., International Network Services, April 1993 [18] Stewart, B., "Expression MIB", RFC ????, Cisco Systems, Inc., ?Month? 1998 [19] Stewart, B., "Notification Log MIB", RFC ????, Cisco Systems, Inc., ?Month? 1998 Expires 5 August 1998+6 months [Page 32] Internet Draft Event MIB 5 August 1998 11. Security Considerations Security issues are discussed in the Overview section and in the DESCRIPTION clauses of relevant objects. 12. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 Phone: 408-526-4527 Email: bstewart@cisco.com Expires 5 August 1998+6 months [Page 33] Internet Draft Event MIB 5 August 1998 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 ....................................................... 5 7 Security ........................................................ 5 8 Definitions ..................................................... 7 9 Acknowledgements ................................................ 30 10 References ..................................................... 31 11 Security Considerations ........................................ 33 12 Author's Address ............................................... 33 Expires 5 August 1998+6 months [Page 34] From maria@xedia.com Wed Aug 5 18:20:32 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id SAA25316 for ; Wed, 5 Aug 1998 18:20:32 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA14323 for ; Wed, 5 Aug 1998 18:19:10 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma014315; Wed, 5 Aug 98 18:18:56 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id SAA29379 for ; Wed, 5 Aug 1998 18:18:20 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma029298; Wed, 5 Aug 98 18:18:12 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id SAA17983; Wed, 5 Aug 1998 18:18:43 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA07815 for ; Wed, 5 Aug 1998 16:18:41 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA14310 for ; Wed, 5 Aug 1998 18:18:39 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by almond.bmc.com via smap (V2.0) id xma014304; Wed, 5 Aug 98 18:18:14 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id TAA01710; Wed, 5 Aug 1998 19:14:15 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id TAA14239 for ; Wed, 5 Aug 1998 19:13:54 -0400 (EDT) Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id TAA27064 for ; Wed, 5 Aug 1998 19:13:52 -0400 (EDT) Received: from tootsie.cisco.com (tootsie.cisco.com [171.69.128.44]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id QAA10742; Wed, 5 Aug 1998 16:13:40 -0700 (PDT) Message-Id: <3.0.5.32.19980805191335.0095e6c0@zipper.cisco.com> X-Sender: bstewart@zipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 05 Aug 1998 19:13:35 -0400 To: Distributed Management WG From: Bob Stewart Subject: Internet Draft - Expression MIB Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Here is a new draft of the Expression MIB as submitted to become: draft-ietf-disman-notif-log-mib-05.txt. This draft has the following changes from the previous Internet Draft: Updated boilerplate. Added a real overview. Separated expValueTimeTicksVal out of expValueUnsigned32Val so the values now directly reflect the wire-visible SNMP data types. Bob --------------- Internet Draft Expression MIB 5 August 1998 Expression MIB 5 August 1998 draft-ietf-disman-express-mib-05.txt Bob Stewart Cisco Systems, Inc. bstewart@cisco.com Status of this Memo This document is an Internet-Draft. 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.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Please send comments to the Distributed Management Working Group, . Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Expires 5 August 1998+6 months [Page 1] Internet Draft Expression MIB 5 August 1998 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 used for managing expressions of MIB objects. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. 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 RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. 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 Expires 5 August 1998+6 months [Page 2] Internet Draft Expression MIB 5 August 1998 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. Expires 5 August 1998+6 months [Page 3] Internet Draft Expression MIB 5 August 1998 3. Overview End users of MIBs often desire MIB objects that MIB designers have not provided. Furthermore, such needs vary from one management philosphy to another. Rather than fill more and more MIBs with standardized objects, the Expression MIB supports externally defined expressions of existing MIB objects. In the Expression MIB the results of an evaluated expression are MIB objects that appear no different from any other and are thus usable anywhere any other MIB object can be used, whether by a management application directly or via another MIB, including the Expression MIB itself, forming expressions of expressions. The Expression MIB is instrumentation for relatively powerful, complex, high-level application, considerably different from simple instrumentation for a communication driver or a protocol. The MIB is appropriate in a relatively powerful, resource-rich managed system and not necessarily in a more limited environment. Implementation of the Expression MIB in an agent environment led to the addition of objects that may not have been necessary in an application environment with complete knowledge of compiled MIB definitions. This is appropriate since that is the expected environment and it is not reasonable that the MIB should assume a full-blown application-level environment. 3.1. Usage On managed systems that can afford the overhead, the Expression MIB is a way to create new, customized MIB objects for monitoring. Although these can save some network traffic and overhead on management systems, that is often not a good tradeoff for objects that are simply to be recorded or displayed. The primary purpose of the Expression MIB is to provide custom objects for the Event MIB [16]. A complex expression can evaluate to a rate of flow or a boolean and thus be subject to testing as an event trigger, resulting in an SNMP notification. Without the Expression MIB such monitoring is limited to the objects in predefined MIBs. The Expression MIB thus supports powerful tools for the network manager faced with the monitoring of large, complex systems that can support a significant level of self management. Expires 5 August 1998+6 months [Page 4] Internet Draft Expression MIB 5 August 1998 3.2. Operation Most of the operation of the MIB is described or implied in the object definitions but a few highlights bear mentioning here. 3.2.1. Sampling The MIB supports three types of object sampling for the MIB objects that make up the expression: absolute, delta, and changed. Absolute samples are simply the value of the MIB object at the time it is sampled. Absolute samples are not sufficient for expressions of counters, as counters have meaning only as a delta (difference) from one sample to the next. Thus objects may be sampled as deltas. Delta sampling requires the application to maintain state for the value at the last sample, and to do continuous sampling whether or not anyone is looking at the results. It thus creates constant overhead. Changed sampling is a simple fallout of delta sampling where rather than a difference the result is a boolean indicating whether or not the object changed value since the last sample. 3.2.2. Wildcards Wildlcards allow the application of a single expression to multiple instances of the same MIB object. The definer of the expression indicates this choice and provides a partial object identifier, with some or all of the instance portion left off. The application then does the equivalent of GetNext to obtain the object values, thus discovering the instances. All wildcarded objects in an expression must have the same semantics for the missing portion of their object identifiers or the results are unpredictable. The expression can be evaluated only for those instances where all the objects in the given potential of the expression are available. Expires 5 August 1998+6 months [Page 5] Internet Draft Expression MIB 5 August 1998 3.2.3. Evaluation There are two important aspects of evaluation that may not be obvious: what objects and when. What objects get used in the evaluation depends on the type of request and whether or not the expression contains wildcarded objects. If the request was a Get, that locks down the instances to be used. If the request was a GetNext or GetBulk, the application must work its way up to the next full set of objects for the expression. Evaluation of expressions happens at two possible times, depending on the sampling. For fully absolute expressions evaluation occurs on demand, when a requester attempts to read a value. In this case all requesters get a freshly calculated value. For expressions with delta or change values, evaluation goes on continuously, every sample period. In this case requesters get the value as of the last sample period. For any given sample period of a given expression, only those instances exist that provided a full set of object values. No obsolete values are kept from one sample period to the next. 3.3. Structure The MIB has the following sections: o Resource -- management of the MIB's use of system resources. o Definition -- definition of expressions. o Value -- values of evaluated expressions. 3.3.1. Resource The resource section has objects to manage resource usage by wildcarded delta expressions, a potential major consumer of CPU and memory. Expires 5 August 1998+6 months [Page 6] Internet Draft Expression MIB 5 August 1998 3.3.2. Definition The definition section contains the tables that define expressions. The expression table, indexed by expression name, contains those parameters that apply to the entire expression, such as the expression itself, the data type of the result, and the sampling interval if it contains delta or change values. The object table, indexed by expression name and object index within each expression, contains the parameters that apply to the individual objects that go into the expression, including the object identifier, sample type, discontinuity indicator, and such. 3.3.3. Value The value section contains the values of evaluated expressions. The value table, indexed by expression name and instance fragment contains a "discriminated union" of evaluated expression results. For a given expression only one of the columns is instantiated, depending on the result data type for the expression. The instance fragment is a constant or the final section of object identifier that filled in a wildcard. Expires 5 August 1998+6 months [Page 7] Internet Draft Expression MIB 5 August 1998 4. Definitions EXPRESSION-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Gauge32, Unsigned32, Counter32, Counter64, IpAddress, TimeTicks FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus,TruthValue, TimeStamp, DisplayString FROM SNMPv2-TC OwnerString FROM IF-MIB sysUpTime FROM SNMPv2-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; expressionMIB MODULE-IDENTITY LAST-UPDATED "9808051700Z" ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 526 4527 Email: bstewart@cisco.com" DESCRIPTION "The MIB module for defining expressions of MIB objects for network management purposes. This MIB is a work in progress of the IETF Distributed Management working group and is subject to change by that body." ::= { experimental xx } expressionMIBObjects OBJECT IDENTIFIER ::= { expressionMIB 1 } expResource OBJECT IDENTIFIER ::= { expressionMIBObjects 1 } expDefine OBJECT IDENTIFIER ::= { expressionMIBObjects 2 } expValue OBJECT IDENTIFIER ::= { expressionMIBObjects 3 } -- -- Wildcarding Example -- Expires 5 August 1998+6 months [Page 8] Internet Draft Expression MIB 5 August 1998 -- This example refers to tables and objects defined below. It may well -- make more sense after reading those definitions. -- -- An expression may use wildcarded MIB objects that result in multiple -- values for the expression. To specify a wildcarded MIB object a -- management application leaves off part or all of the instance portion -- of the object identifier, and sets expObjectWildcard to true(1) for that -- object. For our example we'll use a counter of total blessings -- from a table of people. Another table, indexed by town and person -- has blessings just from that town. -- -- So the index clauses are: -- -- personEntry OBJECT-TYPE -- ... -- INDEX { personIndex } -- -- And: -- -- townPersonEntry OBJECT-TYPE -- ... -- INDEX { townIndex, personIndex } -- -- In our friendly application we may have entered our expression as: -- -- 100 * townPersonBlessings.976.* / personBlessings.* -- -- What goes in expExpression is: -- -- 100*$1/$2 -- -- For example purposes we'll use some slightly far-fetched OIDs, but the -- weirdity won't matter. The People MIB is 1.3.6.1.99.7 and the Town MIB -- is 1.3.6.1.99.11, so for our two counters the OIDs are: -- -- personBlessings 1.3.6.1.99.7.1.3.1.4 -- townPersonBlessings 1.3.6.1.99.11.1.2.1.9 -- -- The rule for wildcards is that all the wildcarded parts have to match -- exactly. In this case that means we have to hardwire the town and only -- the personIndex can be wildcarded. So our values for expObjectID are: -- -- 1.3.6.1.99.7.1.3.1.4 -- 1.3.6.1.99.11.1.2.1.9.976 -- Expires 5 August 1998+6 months [Page 9] Internet Draft Expression MIB 5 August 1998 -- We're hardwired to townIndex 976 and personIndex is allowed to vary. -- -- The value of expExpressionPrefix can be either of those two counter OIDs -- (including the instance fragment in the second case), since either of -- them takes you to a MIB definition where you can look at the INDEX -- clause and figure out what's been left off. What's been left off -- doesn't have to work out to be the same object, but it does have to work -- out to be the same values (semantics) for the result to make sense. -- Note that the agent can not typically check such semantics and if given -- nonsense will return nonsense. -- -- If we have people numbered 6, 19, and 42 in town number 976, the -- successive values of expValueInstance will be: -- -- 0.0.6 -- 0.0.19 -- 0.0.42 -- -- So there will be three values in expValueTable, with those OIDs as the -- expValueInstance part of their indexing. -- -- -- Resource Control -- expResourceDeltaMinimum OBJECT-TYPE SYNTAX Integer32 (-1 | 1..600) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum expExpressionDeltaInterval this system will accept. A system may use the larger values of this minimum to lessen the impact of constantly computing deltas. The value -1 indicates this system will not accept deltaValue as a value for expObjectSampleType. Unless explicitly resource limited, a system's value for this object should be 1. Changing this value will not invalidate an existing setting of expObjectSampleType." Expires 5 August 1998+6 months [Page 10] Internet Draft Expression MIB 5 August 1998 ::= { expResource 1 } expResourceDeltaWildcardInstanceMaximum OBJECT-TYPE SYNTAX Unsigned32 UNITS "instances" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of dynamic instance entries this system will support for wildcarded delta objects in expressions. These are the entries that maintain state, one for each instance of each deltaValue object for each value of an expression. That is, for a given delta expression, the number of such instances is the number of values that meet all criteria to exist times the number of delta values in the expression. 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 delta wildcard instance objects but will prevent the creation of more such objects." ::= { expResource 2 } expResourceDeltaWildcardInstances OBJECT-TYPE SYNTAX Gauge32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of currently active instance entries as defined for expResourceDeltaWildcardInstanceMaximum." ::= { expResource 3 } expResourceDeltaWildcardInstancesHigh OBJECT-TYPE SYNTAX Gauge32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest value of expResourceDeltaWildcardInstances that has occurred since initialization of the management Expires 5 August 1998+6 months [Page 11] Internet Draft Expression MIB 5 August 1998 system." ::= { expResource 4 } expResourceDeltaWildcardInstanceResourceLacks OBJECT-TYPE SYNTAX Counter32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this system could not evaluate an expression because that would have created a value instance in excess of expResourceDeltaWildcardInstanceMaximum." ::= { expResource 5 } -- -- Definition -- -- Expression Definition Table -- expExpressionTable OBJECT-TYPE SYNTAX SEQUENCE OF ExpExpressionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of expression definitions." ::= { expDefine 1 } expExpressionEntry OBJECT-TYPE SYNTAX ExpExpressionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single expression. New expressions can be created using expExpressionStatus. To create an expression first create the named entry in this table. Then use expExpressionName to populate expObjectTable. For expression evaluation to succeed all related entries in expExpressionTable and expObjectTable must be 'active'. If these conditions are not met the corresponding values in expValue simply are not instantiated. Deleting an entry deletes all related entries in expObjectTable. Expires 5 August 1998+6 months [Page 12] Internet Draft Expression MIB 5 August 1998 Because of the relationships among the multiple tables for an expression (expExpressionTable, expObjectTable, and expValueTable) and the SNMP rules for independence in setting object values, it is necessary to do final error checking when an expression is evaluated, that is, when one of its instances in expValueTable is read or a delta interval expires. Earlier checking need not be done and an implementation may not impose any ordering on the creation of objects related to an expression. To maintain security of MIB information, when creating a new row in this table, the managed system must record the security credentials of the requester. If the subsequent expression includes objects with expObjectSampleType 'deltaValue' the evaluation of that expression takes place under the security credentials of the creator of its expExpressionEntry." Values of read-write objects in this table may be changed at any time." INDEX { IMPLIED expExpressionName } ::= { expExpressionTable 1 } ExpExpressionEntry ::= SEQUENCE { expExpressionName SnmpAdminString, expExpression OCTET STRING, expExpressionValueType INTEGER, expExpressionComment DisplayString, expExpressionDeltaInterval Integer32, expExpressionPrefix OBJECT IDENTIFIER, expExpressionErrors Counter32, expExpressionErrorTime TimeStamp, expExpressionErrorIndex Integer32, expExpressionError INTEGER, expExpressionInstance OBJECT IDENTIFIER, expExpressionOwner OwnerString, expExpressionStatus RowStatus } expExpressionName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..64)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the expression. Choosing names with useful lexical ordering supports using GetNext or GetBulk to retrieve a useful subset of the table or to provide instance- Expires 5 August 1998+6 months [Page 13] Internet Draft Expression MIB 5 August 1998 level access control for security purposes." ::= { expNameEntry 1 } expExpression OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..1024)) MAX-ACCESS read-write STATUS current DESCRIPTION "The expression to be evaluated. This object is the same as a DisplayString (RFC 1903) except for its maximum length. Except for the variable names the expression is in ANSI C syntax. Only the subset of ANSI C operators and functions listed here is allowed. Variables are expressed as a dollar sign ('$') and an integer that corresponds to an expObjectIndex. An example of a valid expression is: ($1-$5)*100 Expressions may not be recursive, that is although an expression may use the results of another expression, it may not contain any variable that is directly or indirectly a result of its own evaluation. The only allowed operators are: ( ) - (unary) + - * / % & | ^ << >> ~ ! && || == != > >= < <= Note the parentheses are included for parenthesizing the expression, not for casting data types. The only constant types defined are: int (32-bit signed) long (64-bit signed) unsigned int unsigned long hexadecimal character Expires 5 August 1998+6 months [Page 14] Internet Draft Expression MIB 5 August 1998 string oid The default type for a positive integer is int unless it is too large in which case it is long. All but oid are as defined for ANSI C. Note that a hexadecimal constant may end up as a scalar or an array of 8-bit integers. A string constant is enclosed in double quotes and may contain back-slashed individual characters as in ANSI C. An oid constant comprises 32-bit, unsigned integers and at least one period, for example: 0. .0 1.3.6.1 Integer-typed objects are treated as 32- or 64-bit, signed or unsigned integers, as appropriate. The results of mixing them are as for ANSI C, including the type of the result. Note that a 32-bit value is thus promoted to 64 bits only in an operation with a 64-bit value. There is no provision for larger values to handle overflow. Relative to SNMP data types, a resulting value becomes unsigned when calculating it uses any unsigned value, including a counter. To force the final value to be of data type counter the expression must explicitly use the counter32() or counter64() function (defined below). OCTET STRINGS and OBJECT IDENTIFIERs are treated as 1-based arrays of unsigned 8-bit integers and unsigned 32-bit integers, respectively. IpAddresses are treated as 32-bit, unsigned integers in network byte order, that is, the hex version of 255.0.0.0 is 0xff000000. Conditional expressions result in a 32-bit, unsigned integer of value 0 for false or 1 for true. When an arbitrary value is used as a boolean 0 is false and non-zero is true. Rules for the resulting data type from an operation, based on the Expires 5 August 1998+6 months [Page 15] Internet Draft Expression MIB 5 August 1998 operator: For << and >> the result is the same as the left hand operand. For &&, ||, ==, !=, <, <=, >, and >= the result is always Unsigned32. For unary - the result is always Integer32. For +, -, *, /, %, &, |, and ^ the result is promoted according to the following rules, in order from most to least preferred: If left hand and right hand operands are the same type, use that. If either side is Counter64, use that. If either side is IpAddress, use that. If either side is TimeTicks, use that. If either side is Counter32, use that. Otherwise use Unsigned32. The following rules say what operators apply with what data types. Any combination not explicitly defined does not work. For all operators any of the following can be the left hand or right hand operand: Integer32, Counter32, Unsigned32, Counter64. The operators +, -, *, /, %, <, <=, >, and >= also work with TimeTicks. The operators &, |, and ^ also work with IpAddress. The operators << and >> also work with IpAddress but only as the left hand operand. The + operator performs a concatenation of two OCTET STRINGs or two OBJECT IDENTIFIERs. The operators &, | perform bitwise operations on OCTET STRINGs. If the OCTET STRING happens to be a DisplayString the results may be meaningless, but the agent system does not check this as some such Expires 5 August 1998+6 months [Page 16] Internet Draft Expression MIB 5 August 1998 systems do not have this information. The operators << and >> perform bitwise operations on OCTET STRINGs appearing as the left hand operand. The only functions defined are: counter32 counter64 arraySection stringBegins stringEnds stringContains oidBegins oidEnds oidContains sum exists The following function definitions indicate their by naming the data type of the parameter in the parameter's position in the parameter list. The parameter must be of the type indicated and generally may be a constant, a MIB object, a function, or an expression. counter32(integer) - wrapped around an integer value counter32 forces Counter32 as a data type. counter64(integer) - similar to counter32 except that the resulting data type is 'counter64'. arraySection(array, integer, integer) - selects a piece of an array (i.e. part of an OCTET STRING or OBJECT IDENTIFIER). The integer arguments are in the range 0 to 4,294,967,295. The first is an initial array index (1-based) and the second is an ending array index. A value of 0 indicates first or last element, respectively. If the first element is larger than the array length the result is 0 length. If the second integer is less than or equal to the first, the result is 0 length. If the second is larger than the array length it indicates last element. stringBegins/Ends/Contains(octetString, octetString) - looks for the second string (which can be a string constant) in the first and returns the 1-based index where the match began. A return value of 0 indicates no match (i.e. boolean false). Expires 5 August 1998+6 months [Page 17] Internet Draft Expression MIB 5 August 1998 oidBegins/Ends/Contains(oid, oid) - looks for the second OID (which can be an OID constant) in the first and returns the the 1-based index where the match began. A return value of 0 indicates no match (i.e. boolean false). sum(integerObject*) - sums all availiable values of the wildcarded integer object, resulting in an integer scalar. Must be used with caution as it wraps on overflow with no notification. exists(anyTypeObject) - verifies the object instance exists. A return value of 0 indicates NoSuchInstance (i.e. boolean false)." ::= { expExpressionEntry 2 } expExpressionValueType OBJECT-TYPE SYNTAX INTEGER { counter32(1), unsignedOrGauge32(2), timeTicks(3), integer32(4), ipAddress(5), octetString(6), objectId(7), counter64(8) } MAX-ACCESS read-write STATUS current DESCRIPTION "The type of the expression value. One and only one of the value objects in expValueTable will be instantiated to match this type. If the result of the expression can not be made into this type, an invalidOperandType error will occur." DEFVAL { counter32 } ::= { expExpressionEntry 3 } expExpressionComment OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "A comment to explain the use or meaning of the expression." DEFVAL { ''H } ::= { expExpressionEntry 4 } expExpressionDeltaInterval OBJECT-TYPE SYNTAX Integer32 (0..86400) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Sampling interval for objects in this expression with expObjectSampleType 'deltaValue'. Expires 5 August 1998+6 months [Page 18] Internet Draft Expression MIB 5 August 1998 This object is has no effect if the the expression has no deltaValue objects. A value of 0 indicates no automated sampling. In this case the delta is the difference from the last time the expression was evaluated. Note that this is subject to unpredictable delta times in the face of retries or multiple managers. A value greater than zero is the number of seconds between automated samples. Until the delta interval has expired once the delta for the object is effectively not instantiated and evaluating the expression has results as if the object itself were not instantiated. Note that delta values potentially consume large amounts of system CPU and memory. Delta state and processing must continue constantly even if the expression is not being used. That is, the expression is being evaluated every delta interval, even if no application is reading those values. For wildcarded objects this can be substantial overhead. Note that delta intervals, external expression value sampling intervals and delta intervals for expressions within other expressions can have unusual interactions as they are impossible to synchronize accurately. In general one interval embedded below another must be enough shorter that the higher sample sees relatively smooth, predictable behavior." DEFVAL { 0 } ::= { expExpressionEntry 5 } expExpressionPrefix OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An object prefix to assist an application in determining the instance indexing to use in expValueTable, relieving the application of the need to scan the expObjectTable to determine such a prefix. See expObjectTable for information on wildcarded objects. If the expValueInstance portion of the value OID may Expires 5 August 1998+6 months [Page 19] Internet Draft Expression MIB 5 August 1998 be treated as a scalar (that is, normally, 0) the value of expExpressionPrefix is zero length, that is, no OID at all. Note that zero length implies a null OID, not the OID 0.0. Otherwise, the value of expExpressionPrefix is the expObjectID value of any one of the wildcarded objects for the expression. This is sufficient, as the remainder, that is, the instance fragment relevant to instancing the values, must be the same for all wildcarded objects in the expression." ::= { expExpressionEntry 6 } expExpressionErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of errors encountered while evaluating this expression. Note that an object in the expression not being accessible is not considered an error. It is a legitimate condition that causes the corresponding expression value not to be instantiated." ::= { expExpressionEntry 7 } expExpressionErrorTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime the last time an error caused a failure to evaluate this expression. This object is not instantiated if there have been no errors." ::= { expExpressionEntry 8 } expExpressionErrorIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The 1-based character index into expExpression for where the error occurred. The value zero indicates irrelevance. Expires 5 August 1998+6 months [Page 20] Internet Draft Expression MIB 5 August 1998 This object is not instantiated if there have been no errors." ::= { expExpressionEntry 9 } expExpressionError OBJECT-TYPE SYNTAX INTEGER { invalidSyntax(1), undefinedObjectIndex(2), unrecognizedOperator(3), unrecognizedFunction(4), invalidOperandType(5), unmatchedParenthesis(6), tooManyWildcardValues(7), recursion(8), deltaTooShort(9), resourceUnavailable(10), divideByZero(11) } MAX-ACCESS read-only STATUS current DESCRIPTION "The error that occurred. In the following explanations the expected timing of the error is in parentheses. 'S' means the error occurs on a Set request. 'E' means the error occurs on the attempt to evaluate the expression either due to Get from expValueTable or in ongoing delta processing. invalidSyntax the value sent for expExpression is not valid Expression MIB expression syntax (S) undefinedObjectIndex an object reference ($n) in expExpression does not have a matching instance in expObjectTable (E) unrecognizedOperator the value sent for expExpression held an unrecognized operator (S) unrecognizedFunction the value sent for expExpression held an unrecognized function name (S) invalidOperandType an operand in expExpression is not the right type for the associated operator or result (SE) unmatchedParenthesis the value sent for expExpression is not correctly parenthesized (S) tooManyWildcardValues evaluating the expression exceeded the limit set by expResourceDeltaWildcardInstanceMaximum (E) recursion through some chain of embedded expressions Expires 5 August 1998+6 months [Page 21] Internet Draft Expression MIB 5 August 1998 the expression invokes itself (E) deltaTooShort the delta for the next evaluation passed before the system could evaluate the present sample (E) resourceUnavailable some resource, typically dynamic memory, was unavailable (SE) divideByZero an attempt to divide by zero occurred (E) For the errors that occur when the attempt is made to set expExpression Set request fails with the SNMP error code 'wrongValue'. Such failures refer to the most recent failure to Set expExpression, not to the present value of expExpression which must be either unset or syntactically correct. Errors that occur during evalutaion for a Get* operation return the SNMP error code 'genErr' except for 'tooManyWildcardValues' and 'resourceUnavailable' which return the SNMP error code 'resourceUnavailable'. This object is not instantiated if there have been no errors." ::= { expExpressionEntry 10 } expExpressionInstance OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The expValueInstance being evaluated when the error occurred. A zero-length indicates irrelevance. This object is not instantiated if there have been no errors." ::= { expExpressionEntry 11 } expExpressionOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-write STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." DEFVAL { "" } ::= { expExpressionEntry 12 } Expires 5 August 1998+6 months [Page 22] Internet Draft Expression MIB 5 August 1998 expExpressionStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation and deletion of entries." ::= { expExpressionEntry 13 } -- -- Object Table -- expObjectTable OBJECT-TYPE SYNTAX SEQUENCE OF ExpObjectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of object definitions for each expExpression. Wildcarding instance IDs: It is legal to omit all or part of the instance portion for some or all of the objects in an expression. (See the DESCRIPTION of expObjectID for details. However, note that if more than one object in the same expression is wildcarded in this way, they all must be objects where that portion of the instance is the same. In other words, all objects may be in the same SEQUENCE or in different SEQUENCEs but with the same semantic index value (e.g., a value of ifIndex) for the wildcarded portion." ::= { expDefine 2 } expObjectEntry OBJECT-TYPE SYNTAX ExpObjectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about an object. An application uses expObjectStatus to create entries in this table while in the process of defining an expression. Values of read-create objects in this table may be changed at any time." INDEX { expExpressionName, expObjectIndex } Expires 5 August 1998+6 months [Page 23] Internet Draft Expression MIB 5 August 1998 ::= { expObjectTable 1 } ExpObjectEntry ::= SEQUENCE { expObjectIndex Unsigned32, expObjectID OBJECT IDENTIFIER, expObjectIDWildcard TruthValue, expObjectSampleType INTEGER, expObjectDeltaDiscontinuityID OBJECT IDENTIFIER, expObjectDiscontinuityIDWildcard TruthValue, expObjectDiscontinuityIDType INTEGER, expObjectConditional OBJECT IDENTIFIER, expObjectConditionalWildcard TruthValue, expObjectStatus RowStatus } expObjectIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Within an expression, a unique, numeric identification for an object. Prefixed with a dollar sign ('$') this is used to reference the object in the corresponding expExpression." ::= { expObjectEntry 1 } expObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of this object. The OID may be fully qualified, meaning it includes a complete instance identifier part (e.g., ifInOctets.1 or sysUpTime.0), or it may not be fully qualified, meaning it may lack all or part of the instance identifier. If the expObjectID is not fully qualified, then expObjectWildcard must be set to true(1). The value of the expression will be multiple values, as if done for a GetNext sweep of the object. An object here may itself be the result of an expression but recursion is not allowed. NOTE: The simplest implementations of this MIB may not allow wildcards." ::= { expObjectEntry 2 } Expires 5 August 1998+6 months [Page 24] Internet Draft Expression MIB 5 August 1998 expObjectIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A true value indicates the expObjecID of this row is a wildcard object. False indicates that expObjectID is fully instanced. If all expObjectWildcard values for a given expression are FALSE, expExpressionPrefix will reflect a scalar object (ie will be 0.0). NOTE: The simplest implementations of this MIB may not allow wildcards." DEFVAL { false } ::= { expObjectEntry 3 } expObjectSampleType OBJECT-TYPE SYNTAX INTEGER { absoluteValue(1), deltaValue(2), changedValue(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The method of sampling the selected variable. An 'absoluteValue' is simply the present value of the object. A 'deltaValue' is the present value minus the previous value, which was sampled expExpressionDeltaInterval seconds ago. This is intended primarily for use with SNMP counters, which are meaningless as an 'absoluteValue', but may be used with any integer-based value. A 'changedValue' is a boolean for whether the present value is different from the previous value. It is applicable to any data type and results in an Unsigned32 with value 1 if the object's value is changed and 0 if not. In all other respects it is as a 'deltaValue' and all statements and operation regarding delta values apply to changed values. When an expression contains both delta and absolute values the absolute values are obtained at the end of the delta period." DEFVAL { absoluteValue } ::= { expObjectEntry 4 } Expires 5 August 1998+6 months [Page 25] Internet Draft Expression MIB 5 August 1998 expObjectDeltaDiscontinuityID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of a TimeTicks or TimeStamp object that indicates a discontinuity in the value at expObjectID. This object is not instantiated if expObject is not 'deltaValue'. The OID may be for a leaf object (e.g. sysUpTime.0) or may be wildcarded to match expObjectID. 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 no discontinuity check will be made." DEFVAL { sysUpTime 0 } ::= { expObjectEntry 5 } expObjectDiscontinuityIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A true value indicates the expObjectDeltaDiscontinuityID of this row is a wildcard object. False indicates that expObjectDeltaDiscontinuityID is fully instanced. This object is not instantiated if expObject is not 'deltaValue'. NOTE: The simplest implementations of this MIB may not allow wildcards." DEFVAL { false } ::= { expObjectEntry 6 } expObjectDiscontinuityIDType OBJECT-TYPE SYNTAX INTEGER { timeTicks(1), timeStamp(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value 'timeTicks' indicates the expObjectDeltaDiscontinuityID Expires 5 August 1998+6 months [Page 26] Internet Draft Expression MIB 5 August 1998 of this row is of syntax TimeTicks. The value 'timeStamp' indicates that expObjectDeltaDiscontinuityID is of syntax TimeStamp. This object is not instantiated if expObject is not 'deltaValue'." DEFVAL { timeTicks } ::= { expObjectEntry 7 } expObjectConditional OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of an object that overrides whether the instance of expObjectID is to be considered usable. If the value of the object at expObjectConditional is 0 or not instantiated, the object at expObjectID is treated as if it is not instantiated. In other words, expObjectConditional is a filter that controls whether or not to use the value at expObjectID. The OID may be for a leaf object (e.g. sysObjectID.0) or may be wildcarded to match expObjectID. If expObject is wildcarded and expObjectID in the same row is not, the wild portion of expObjectConditional must match the wildcarding of the rest of the expression. If no object in the expression is wildcarded but expObjectConditional is, use the lexically first instance (if any) of expObjectConditional. If the value of expObjectConditional is 0.0 operation is as if the value pointed to by expObjectConditional is a non-zero (true) value. Note that expObjectConditional can not trivially use an object of syntax TruthValue, since the underlying value is not 0 or 1." DEFVAL { zeroDotZero } ::= { expObjectEntry 8 } expObjectConditionalWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A true value indicates the expObjectConditional of this row is a Expires 5 August 1998+6 months [Page 27] Internet Draft Expression MIB 5 August 1998 wildcard object. False indicates that expObjectConditional is fully instanced. NOTE: The simplest implementations of this MIB may not allow wildcards." DEFVAL { false } ::= { expObjectEntry 9 } expObjectStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation/deletion of entries. Objects in this table may be changed while expObjectStatus is in any state." ::= { expObjectEntry 10 } -- -- Expression Value Table -- expValueTable OBJECT-TYPE SYNTAX SEQUENCE OF ExpValueEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of values from evaluated expressions." ::= { expValue 1 } expValueEntry OBJECT-TYPE SYNTAX ExpValueEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single value from an evaluated expression. For a given instance, only one 'Val' object in the conceptual row will be instantiated, that is, the one with the appropriate type for the value. For values that contain no objects of expObjectSampleType 'deltaValue', reading a value from the table causes the evaluation of the expression for that value. For those that contain a 'deltaValue' the value read is as of the last delta interval. Expires 5 August 1998+6 months [Page 28] Internet Draft Expression MIB 5 August 1998 If in the attempt to evaluate the expression one or more of the necessary objects is not available, the corresponding entry in this table is effectively not instantiated. To maintain security of MIB information, expression evaluation must take place using security credentials for the implied Gets of the objects in the expression. For expressions with no deltaValue those security credentials are the ones that came with the Get* for the value. For expressions with a deltaValue the ongoing expression evaluation is under the security credentials of the creator of the corresponding expNameEntry." INDEX { expExpressionName, IMPLIED expValueInstance } ::= { expValueTable 1 } ExpValueEntry ::= SEQUENCE { expValueInstance OBJECT IDENTIFIER, expValueCounter32Val Counter32, expValueUnsigned32Val Unsigned32, expValueTimeTicksVal TimeTicks, expValueInteger32Val Integer32, expValueIpAddressVal IpAddress, expValueOctetStringVal OCTET STRING, expValueOidVal OBJECT IDENTIFIER, expValueCounter64Val Counter64 } expValueInstance OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The final instance portion of a value's OID according to the wildcarding in instances of expObjectID for the expression. The prefix of this OID fragment is 0.0, leading to the following behavior. If there is no wildcarding, the value is 0.0.0. In other words, there is one value which standing alone would have been a scalar with a 0 at the end of its OID. If there is wildcarding, the value is 0.0 followed by a value that the wildcard can take, thus defining one value instance for each real, possible value of the wildcard. So, for example, if the wildcard worked out to be an ifIndex, Expires 5 August 1998+6 months [Page 29] Internet Draft Expression MIB 5 August 1998 there is an expValueInstance for each applicable ifIndex." ::= { expValueEntry 1 } expValueCounter32Val OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'counter32'." ::= { expValueEntry 2 } expValueUnsigned32Val OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'unsignedOrGauge32'." ::= { expValueEntry 3 } expValueTimeTicksVal OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'timeTicks'." ::= { expValueEntry 4 } expValueInteger32Val OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'integer32'." ::= { expValueEntry 5 } expValueIpAddressVal OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'ipAddress'." ::= { expValueEntry 6 } expValueOctetStringVal OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..65536)) Expires 5 August 1998+6 months [Page 30] Internet Draft Expression MIB 5 August 1998 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'octetString'." ::= { expValueEntry 7 } expValueOidVal OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'objectId'." ::= { expValueEntry 8 } expValueCounter64Val OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'counter64'." ::= { expValueEntry 9 } -- -- Conformance -- expressionMIBConformance OBJECT IDENTIFIER ::= { expressionMIB 3 } expressionMIBCompliances OBJECT IDENTIFIER ::= { expressionMIBConformance 1 } expressionMIBGroups OBJECT IDENTIFIER ::= { expressionMIBConformance 2 } -- Compliance expressionMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Expression MIB." MODULE -- this module MANDATORY-GROUPS { expressionResourceGroup, expressionDefinitionGroup, expressionValueGroup } OBJECT expResourceDeltaMinimum Expires 5 August 1998+6 months [Page 31] Internet Draft Expression MIB 5 August 1998 SYNTAX Integer32 (-1 | 60..600) DESCRIPTION "Implementation need not allow deltas or it may implement them and restrict them to higher values." OBJECT expObjectSampleType WRITE-SYNTAX INTEGER { absoluteValue(1) } DESCRIPTION "Implementation may not allow deltas." ::= { expressionMIBCompliances 1 } -- Units of Conformance expressionResourceGroup OBJECT-GROUP OBJECTS { expResourceDeltaMinimum, expResourceDeltaWildcardInstanceMaximum, expResourceDeltaWildcardInstances, expResourceDeltaWildcardInstancesHigh, expResourceDeltaWildcardInstanceResourceLacks } STATUS current DESCRIPTION "Expression definition resource management." ::= { expressionMIBGroups 1 } expressionDefinitionGroup OBJECT-GROUP OBJECTS { expExpression, expExpressionValueType, expExpressionComment, expExpressionDeltaInterval, expExpressionPrefix, expExpressionErrors, expExpressionErrorTime, expExpressionErrorIndex, expExpressionError, expExpressionInstance, expExpressionOwner, expExpressionStatus, expObjectID, expObjectIDWildcard, expObjectSampleType, Expires 5 August 1998+6 months [Page 32] Internet Draft Expression MIB 5 August 1998 expObjectDeltaDiscontinuityID, expObjectDiscontinuityIDWildcard, expObjectDiscontinuityIDType, expObjectConditional, expObjectConditionalWildcard, expObjectStatus } STATUS current DESCRIPTION "Expression definition." ::= { expressionMIBGroups 2 } expressionValueGroup OBJECT-GROUP OBJECTS { expValueCounter32Val, expValueUnsigned32Val, expValueTimeTicksVal, expValueInteger32Val, expValueIpAddressVal, expValueOctetStringVal, expValueOidVal, expValueCounter64Val } STATUS current DESCRIPTION "Expression value." ::= { expressionMIBGroups 3 } END Expires 5 August 1998+6 months [Page 33] Internet Draft Expression MIB 5 August 1998 5. Acknowledgements This MIB contains considerable contributions from the Distributed Management Design Team (Andy Bierman, Maria Greene, Bob Stewart, and Steve Waldbusser), and colleagues at Cisco who did the first implemenation. Expires 5 August 1998+6 months [Page 34] Internet Draft Expression MIB 5 August 1998 6. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998 [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991 [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. Expires 5 August 1998+6 months [Page 35] Internet Draft Expression MIB 5 August 1998 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, January 1998 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., Cisco Systems, Inc., January 1998 [16] Stewart, B., "Event MIB", RFC ????, Cisco Systems, Inc., ?Month? 1998 Expires 5 August 1998+6 months [Page 36] Internet Draft Expression MIB 5 August 1998 7. Security Considerations Security is discussed in the body of the MIB itself. 8. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 Phone: 408-526-4527 Email: bstewart@cisco.com Expires 5 August 1998+6 months [Page 37] Internet Draft Expression MIB 5 August 1998 Table of Contents 1 Abstract ........................................................ 2 2 The SNMP Management Framework ................................... 2 3 Overview ........................................................ 4 3.1 Usage ......................................................... 4 3.2 Operation ..................................................... 5 3.2.1 Sampling .................................................... 5 3.2.2 Wildcards ................................................... 5 3.2.3 Evaluation .................................................. 6 3.3 Structure ..................................................... 6 3.3.1 Resource .................................................... 6 3.3.2 Definition .................................................. 7 3.3.3 Value ....................................................... 7 4 Definitions ..................................................... 8 5 Acknowledgements ................................................ 34 6 References ...................................................... 35 7 Security Considerations ......................................... 37 8 Author's Address ................................................ 37 Expires 5 August 1998+6 months [Page 38] From maria@xedia.com Thu Aug 6 08:37:43 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id IAA12922 for ; Thu, 6 Aug 1998 08:37:42 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id IAA16080 for ; Thu, 6 Aug 1998 08:36:19 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma016042; Thu, 6 Aug 98 08:35:51 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id IAA00722 for ; Thu, 6 Aug 1998 08:35:14 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma000232; Thu, 6 Aug 98 08:34:47 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id IAA13603; Thu, 6 Aug 1998 08:35:21 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA10722 for ; Thu, 6 Aug 1998 06:35:19 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id IAA12758 for ; Thu, 6 Aug 1998 08:35:18 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by cashew.bmc.com via smap (V2.0) id xma012706; Thu, 6 Aug 98 08:34:47 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id JAA05069; Thu, 6 Aug 1998 09:31:24 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id JAA09518 for ; Thu, 6 Aug 1998 09:30:30 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id JAA04613 for ; Thu, 6 Aug 1998 09:30:28 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA04995; Thu, 6 Aug 1998 09:30:24 -0400 (EDT) Message-Id: <199808061330.JAA04995@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@nexen.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-event-mib-04.txt Date: Thu, 06 Aug 1998 09:30:24 -0400 Sender: cclark@ns.cnri.reston.va.us --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) : B. Stewart Filename : draft-ietf-disman-event-mib-04.txt Pages : 34 Date : 05-Aug-98 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 used for managing monitoring of MIB objects and taking action through events. Internet-Drafts are 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-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-event-mib-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-event-mib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980805172425.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-event-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-event-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980805172425.I-D@ietf.org> --OtherAccess-- --NextPart-- From maria@xedia.com Thu Aug 6 08:51:17 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id IAA13206 for ; Thu, 6 Aug 1998 08:51:16 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id IAA17035 for ; Thu, 6 Aug 1998 08:49:52 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma017022; Thu, 6 Aug 98 08:49:42 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id IAA13253 for ; Thu, 6 Aug 1998 08:49:06 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma012906; Thu, 6 Aug 98 08:48:49 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id IAA17601; Thu, 6 Aug 1998 08:49:19 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA10752 for ; Thu, 6 Aug 1998 06:49:12 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id IAA16952 for ; Thu, 6 Aug 1998 08:49:09 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by almond.bmc.com via smap (V2.0) id xma016897; Thu, 6 Aug 98 08:48:46 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id JAA05191; Thu, 6 Aug 1998 09:38:01 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id JAA10074 for ; Thu, 6 Aug 1998 09:37:49 -0400 (EDT) From: kennethw@VNET.IBM.COM Received: from VNET.IBM.COM (vnet.ibm.com [204.146.168.194]) by guelah.nexen.com (8.8.5/8.7.3) with SMTP id JAA04651 for ; Thu, 6 Aug 1998 09:37:46 -0400 (EDT) Message-Id: <199808061337.JAA04651@guelah.nexen.com> Received: from RALVMS by VNET.IBM.COM (IBM VM SMTP V2R4) with BSMTP id 7887; Thu, 06 Aug 98 09:37:31 EDT Date: Thu, 6 Aug 98 09:37:35 EDT To: internet-drafts@ietf.org cc: disman@nexen.com Subject: New REMOPS-MIB draft Please post the attached internet-draft as . Thanks, Ken ---------------------------------------------------------------- DISMAN Working Group Kenneth White INTERNET DRAFT: IBM Corp. Expiration Date: February 1999 August 1998 Definitions of Managed Objects for Remote Operations Using SMIv2 Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any Internet Draft. Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This memo defines a Management Information Base (MIB) for performing remote operations (ping and traceroute) at a remote host. When managing a network it is useful to be able to retrieve the results of either a ping or traceroute operation when performed at a remote host. Currently, there exists several enterprise defined MIBs for performing both a remote ping or traceroute operation. The purpose of this memo is to defined a standards-based solution to enable interoperibility. Table of Contents 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.0 The SNMP Network Management Framework . . . . . . . . . . . . 3 DISMAN Working Group Expires December 1998 [Page 1] Internet Draft REMOPS-MIB August 4, 1998 3.0 Structure of the MIB . . . . . . . . . . . . . . . . . . . . . 4 4.0 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.0 Security Considerations . . . . . . . . . . . . . . . . . . . 23 6.0 Intellectual Property . . . . . . . . . . . . . . . . . . . . 24 7.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 8.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.0 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 26 10.0 Full Copyright Statement . . . . . . . . . . . . . . . . . . 26 1.0 Introduction 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, reference [13]. This document is a product of the Distributed Management (DISMAN) Working Group. Its purpose is to define a standards-based MIB module for performing remote operations. The remote operations consist of the ping and traceroute functions. Ping and traceroute are two very useful functions for managing networks. Ping is typically used to determine if a path exists between two hosts while traceroute shows an actual path. Ping is usually implemented using the InterNet Control Message Protocol (ICMP) "ECHO" facility. It is also possible to implement a ping capability using alternate methods. For example, if the udp echo port (7) is supported at a target host it could be used instead of the ICMP echo facility. Traceroute is usually implemented by transmitting a series of probe packets with increasing time-to-live values. A probe packet is a UDP datagram encapsulated into an IP packet. Each hop in a path to the target (destination) host rejects the probe packets (probe's TTL too small) until its time-to-live value becomes large enough for the probe to be forwarded. Some systems use icmp probes instead of udp ones to implement traceroute. In both cases traceroute relies on the probes being rejected via an ICMP message to discover the hops taken along a path to the final destination. The actually method chosen to implement either the ping or traceroute functions at a remote host is considered to be implementation dependent. An agent implementation SHOULD use whatever method is thought to be best for its environment and document its behavior in its agent's capability statement when referring to the REMOPS-MIB. DISMAN Working Group Expires December 1998 [Page 2] Internet Draft REMOPS-MIB August 4, 1998 Both ping and traceroute yield the round-trip times measured in milliseconds. These times can be used as an rough approximation for network transit time. Consider the following diagram: +----------------------------------------------------------------------+ | | | Remote ping or Actual ping or | | +-----+traceroute request +------+traceroute request +------+| | |Local|------------------>|Remote|------------------>|Target|| | | Host| | Host | | Host || | +-----+ +------+ +------+| | | | | +----------------------------------------------------------------------+ A local host is the host from which the remote ping or traceroute operation is initiated from using an SNMP request. The remote host is a host where the MIB defined by this memo (REMOPS-MIB) is implemented that receives the remote ping or traceroute request via SNMP and performs the actual ping or traceroute command to the target (destination) host. 2.0 The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [7]. 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 RFC 1155 [14], RFC 1212 [15] and RFC 1215 [16]. The second version, called SMIv2, is described in RFC 1902 [3], RFC 1903 [4] and RFC 1904 [5]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [1]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [17] and RFC 1906 [18]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [18], RFC 2272 [8] and RFC 2274 [10]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [1]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [6]. o A set of fundamental applications described in RFC 2273 [9] and the view-based access control mechanism described in RFC 2275 [11]. DISMAN Working Group Expires December 1998 [Page 3] Internet Draft REMOPS-MIB August 4, 1998 Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined ore, 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.0 Structure of the MIB The REMOPS-MIB consists of the following components: o remopsSpinLock, remopsPingMaxConcurrentRequests, remopsTraceRouteMaxConcurrentRequests, remopsPingPurgeTime, and remopsTraceRoutePurgeTime o remopsPingTable and remopsPingResultsTable o remopsTraceRouteTable and remopsTraceRouteResultsTable An agent MUST implement the remopsSpinLock object to enable management applications to coordinate their use of the REMOPS-MIB. Management application use of remopsSpinLock is OPTIONAL. The objects remopsPingMaxConcurrentRequests and remopsTraceRouteMaxConcurrentRequests enable control of the maximum number of concurrent requests that an agent implementation is structured to support. It is permissible for an agent to either limit the maximum upper range allowed for these objects or to implement these objects as read-only with implementation limits expressed as their values. The two objects remopsPingPurgeTime and remopsTraceRoutePurgeTime provide a method for entries in either remopsPingTable and remopsPingResultsTable, or remopsTraceRouteTable and remopsTraceRouteResultsTable to be automatically deleted after operations complete. A remote ping or traceroute operation is initiated by performing an SNMP SET request on either remopsPingRowStatus or remopsTraceRouteRowStatus. The first index (either remopsPingOwnerIndex or remopsTraceRouteOwnerIndex) is of the SnmpAdminString textual convention that allows for use of the SNMPv3 VACM security model and also allows for a management application to identify its entries in either table. The second and 3rd indexes specify the target address for the operation. A target address can be specified as either a dnsName(2), ipv4(3), or ipv6(4) address. DISMAN Working Group Expires December 1998 [Page 4] Internet Draft REMOPS-MIB August 4, 1998 Both ping and traceroute require that an entry be created and activated in either remopsPingTable or remopsTraceRouteTable. Additionally, results can be returned using NOTIFICATIONs (refer to remopsPingNotification and remopsTraceRouteHopNotification). Notification enabled is controlled via either the request on a remopsTraceRouteResponse instance. Which remopsPingCtlType or remopsTraceRouteCtlType objects. Using the maximum value for the parameters defined within an remopsPingEntry can result in a remote ping operation taking at most 15 minutes (remopsPingTimeOut times remopsPingProbeCount) plus whatever time it takes to send the ping request and receive its response over the network. Use of the defaults for remopsPingTimeOut and remopsProbeCount yields a maximum of 3 seconds to perform the actual ping operation. The object remopsPingOperStatus can be polled to determine when a ping operation completes prior to retrieve the results of the operation from the remopsPingResultsTable. Traceroute has a much longer theoretical maximum time for completion. Basically 42 hours and 30 minutes (the product of remopsTraceRouteTimeOut, remopsTraceRouteProbesPerHop, and remopsTraceRouteMaxTtl) plus some network transit time! Use of the defaults defined within an remopsTraceRouteEntry yields a maximum of 4 minutes and 30 seconds for a default traceroute operation. Clearly 42 plus hours is too long to wait for a traceroute operation to complete. The maximum TTL value in effect for traceroute route determines how long the traceroute function will keep increasing the TTL value in the probe it transmits hoping to reach the target host. The function ends whenever the maximum TTL is exceeded or the target host is reached. The object remopsTraceRouteSetupMaxFailures was created in order to impose a throttle for how long traceroute continues to increase the TTL field in a probe without receiving any kind of response (timeouts). It is RECOMMENDED that agent implementations impose a time limit for how long it allows a traceroute operation to take relative to how the function is implemented. For example, an implemented that can't process multiple traceroute operations at the same time SHOULD impose a shorter maximum allowed time period. Consideration SHOULD also be given to whether the response is going to be polled for or returned as a series of hop NOTIFICATIONs. The object remopsTraceRouteOperStatus can be examined to determine the state of a traceroute operation. A management application can delete active remote ping or traceroute request by setting its remopsPingRowStatus or remopsTraceRouteRowStatus object to destroy(6). An implementation SHOULD NOT retain SNMP-created entries in either the remopsPingTable or remopsTraceRouteTable across reIPLs (Initial Program Loads) of its agent, since management applications need to see consistent behavior with respect to the persistence of the table entries that they create. DISMAN Working Group Expires December 1998 [Page 5] Internet Draft REMOPS-MIB August 4, 1998 4.0 Definitions REMOPS-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, experimental, Unsigned32, NOTIFICATION-TYPE FROM SNMPv2-SMI -- RFC1902 TEXTUAL-CONVENTION, RowStatus, TestAndIncr FROM SNMPv2-TC -- RFC1903 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- RFC1904 Utf8String FROM SYSAPPL-MIB -- RFC2287 SnmpAdminString FROM SNMP-FRAMEWORK-MIB; -- RFC2271 remopsMIB MODULE-IDENTITY LAST-UPDATED "9808040000Z" ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Kenneth White International Business Machines Corporation Network Computing Software Division Research Triangle Park, NC, USA E-mail: kennethw@vnet.ibm.com" DESCRIPTION "The Remote Operations MIB (REMOPS-MIB) enables use of the ping and traceroute functions via use of the SNMP protocol." ::= { experimental 84 } -- Textual Conventions RemopsHostAddressType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The textual convention for defining the type of the target host's (destination) address." SYNTAX INTEGER { none(1), dnsName(2), -- Utf8string encoded DNS name ipv4(3), -- ipv4 address ipv6(4) -- ipv6 address } RemopsHostAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The textual convention for specifying a host DISMAN Working Group Expires December 1998 [Page 6] Internet Draft REMOPS-MIB August 4, 1998 target (destination) address as indicated though use of the RemopsHostAddressType textual convention. The length of an object of this textual convention is in octets as indicated by the value of an associating object with the following RemopsHostAddressType value: RemopsHostAddressType none(1) 0 OCTETs dnsName(2) 1 to 65 OCTETs ipv4(3) 4 OCTETs ipv6(4) 16 OCTETs" SYNTAX OCTET STRING (SIZE (0..65)) RemopsStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The textual convention for specifying the states that a remops operation can be in." SYNTAX INTEGER { notStarted(1), active(2), completed(3) } -- Top-level structure of the MIB remopsNotifications OBJECT IDENTIFIER ::= { remopsMIB 0 } remopsObjects OBJECT IDENTIFIER ::= { remopsMIB 1 } remopsConformance OBJECT IDENTIFIER ::= { remopsMIB 2 } -- All simple objects remopsBaseObjects OBJECT IDENTIFIER ::= { remopsObjects 1 } -- SpinLock Definition remopsSpinLock OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "An advisory lock used to allow cooperating remops applications to coordinate their use of the remopsPingTable or the remopsTraceRouteTable. This object should be used when an application seeks to create an new entry or alter an existing entry in either the remopsPingTable or remopsTraceRouteTable. A management implementation MAY utilize the remopsSpinLock to serialize its changes or additions. Its usage is NOT REQUIRED." ::= { remopsBaseObjects 1 } DISMAN Working Group Expires December 1998 [Page 7] Internet Draft REMOPS-MIB August 4, 1998 remopsPingMaxConcurrentRequests OBJECT-TYPE SYNTAX Unsigned32 (1..100) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of concurrent active ping requests that are allowed within an agent implementation." DEFVAL { 10 } ::= { remopsBaseObjects 2 } remopsTraceRouteMaxConcurrentRequests OBJECT-TYPE SYNTAX Unsigned32 (1..100) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of concurrent active traceroute requests that are allowed within an agent implementation." DEFVAL { 10 } ::= { remopsBaseObjects 3 } remopsPingPurgeTime OBJECT-TYPE SYNTAX Unsigned32 (0..86400) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The amount of time to wait before automatically deleting an entry in remopsPingTable and all remopsPingResultsTable entries after the ping operation represented by an entry in the remopsPingTable has completed." DEFVAL { 900 } -- 15 minutes as default ::= { remopsBaseObjects 4 } remopsTraceRoutePurgeTime OBJECT-TYPE SYNTAX Unsigned32 (0..86400) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The amount of time to wait before automatically deleting an entry in remopsTraceRouteTable and all dependent remopsTraceRouteResultsTable entries after the traceroute operation represented by an remopsTraceRouteEntry has completed." DEFVAL { 900 } -- 15 minutes as default ::= { remopsBaseObjects 5 } -- Remote Operations Ping Table remopsPingTable OBJECT-TYPE SYNTAX SEQUENCE OF RemopsPingEntry MAX-ACCESS not-accessible DISMAN Working Group Expires December 1998 [Page 8] Internet Draft REMOPS-MIB August 4, 1998 STATUS current DESCRIPTION "Defines the Remote Operations Ping Table for provide via SNMP the capability of invoking ping from a remote host." ::= { remopsObjects 2 } remopsPingEntry OBJECT-TYPE SYNTAX RemopsPingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the remopsPingTable." INDEX { remopsPingOwnerIndex, remopsPingHostAddressType, remopsPingHostAddress } ::= { remopsPingTable 1 } RemopsPingEntry ::= SEQUENCE { remopsPingOwnerIndex SnmpAdminString, remopsPingHostAddressType RemopsHostAddressType, remopsPingHostAddress RemopsHostAddress, remopsPingCtlType BITS, remopsPingPacketSize Unsigned32, remopsPingTimeOut Unsigned32, remopsPingProbeCount Unsigned32, remopsPingOperStatus RemopsStatus, remopsPingRowStatus RowStatus } remopsPingOwnerIndex OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "To facilitate the provisioning of access control by a security administrator using the View-Based Access Control Model (RFC 2275, VACM) 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 that table 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 DISMAN Working Group Expires December 1998 [Page 9] Internet Draft REMOPS-MIB August 4, 1998 owner index portion, and vacmViewTreeFamilyMask 'wildcarding' the column subidentifier. More elaborate configurations are possible." ::= { remopsPingEntry 1 } remopsPingHostAddressType OBJECT-TYPE SYNTAX RemopsHostAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies the address type of the destination." ::= { remopsPingEntry 2 } remopsPingHostAddress OBJECT-TYPE SYNTAX RemopsHostAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies the host address used on by ping request by the remote host. The host address specified is indicated by remopsPingHostAddressType." ::= { remopsPingEntry 3 } remopsPingCtlType OBJECT-TYPE SYNTAX BITS { enableNotifications(0) } MAX-ACCESS read-create STATUS current DESCRIPTION "The purpose of this object is enable the following ping function: enableNotifications(0) = enable NOTIFICATIONs for a ping operation. By default no notifications are generated." ::= { remopsPingEntry 4 } remopsPingPacketSize OBJECT-TYPE SYNTAX Unsigned32 (0..65507) UNITS "octets" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the size of the data portion to be transmitted in a ping request in octets. A ping request is usually an ICMP message encoded into an IP packet. An IP packet has a maximum size of 65535 octets. Subtracting the size of the ICMP header (8 octets) and the size of the IP header (20 octets) yields a maximum size of 65507 octets." DEFVAL { 0 } ::= { remopsPingEntry 5 } remopsPingTimeOut OBJECT-TYPE DISMAN Working Group Expires December 1998 [Page 10] Internet Draft REMOPS-MIB August 4, 1998 SYNTAX Unsigned32 (1..60) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the time-out value, in seconds, for the actual PING request made by the remote host. Valid values for time out are from 1 to 60 seconds." DEFVAL { 3 } ::= { remopsPingEntry 6 } remopsPingProbeCount OBJECT-TYPE SYNTAX Unsigned32 (1..15) MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the number of times to issue a ping request at a remote host." DEFVAL { 1 } ::= { remopsPingEntry 7 } remopsPingOperStatus OBJECT-TYPE SYNTAX RemopsStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Reflects the operational state of a remote ping operation." ::= { remopsPingEntry 8 } remopsPingRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted in the remopsPingTable. Deletion of an entry in this table results in all remopsPingResultsTable entries being deleted. A remote ping operation is started when an entry in this table is created via an SNMP SET request and the entry is activated. This can occur by setting the value of this object to CreateAndGo(4) during row creation or by setting this object to active(1) after the row is created. A remote ping request starts when its entry first becomes active(1). Transitions in and out of active(1) state have no effect on the operational behavior of a remote ping operation, with the exception that deletion of an entry in this table by setting its RowStatus DISMAN Working Group Expires December 1998 [Page 11] Internet Draft REMOPS-MIB August 4, 1998 object to destroy(6) will stop an active remote ping operation. The operational state of an remote ping operation can be determined by examination of it's remopsPingOperStatus object." REFERENCE "RFC 1903, 'Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { remopsPingEntry 9 } -- Remote Operations Ping Results Table remopsPingResultsTable OBJECT-TYPE SYNTAX SEQUENCE OF RemopsPingResultsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines the Remote Operations Result Ping Table for storing the results of a ping operation." ::= { remopsObjects 3 } remopsPingResultsEntry OBJECT-TYPE SYNTAX RemopsPingResultsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the remopsPingResultsTable." INDEX { remopsPingOwnerIndex, remopsPingHostAddressType, remopsPingHostAddress, remopsPingResultsProbeIndex } ::= { remopsPingResultsTable 1 } RemopsPingResultsEntry ::= SEQUENCE { remopsPingResultsProbeIndex Unsigned32, remopsPingResultsResponse Integer32 } remopsPingResultsProbeIndex OBJECT-TYPE SYNTAX Unsigned32 (1..15) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created when the results of a ping probe is determined. The initial instance identifier value identifies the remopsPingEntry that a probe result (remopsPingResultsEntry) belongs to." ::= { remopsPingResultsEntry 1 } DISMAN Working Group Expires December 1998 [Page 12] Internet Draft REMOPS-MIB August 4, 1998 remopsPingResultsResponse OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The result of the ping operation made by a remote host for a particular probe. The results of the probe is indicated as the value of this object as follows: >=0 Round-trip response time in milliseconds. -1 Internal error. -2 ICMP echo request timed out. -3 Unknown destination address. -4 No route to host. -5 Interface inactive to host. -6 Failed to resolve host name. -7 remopsPingMaxConcurrentRequests limit reached." ::= { remopsPingResultsEntry 2 } -- Remote Operations Traceroute Table remopsTraceRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF RemopsTraceRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines the Remote Operations Traceroute Table for provide via SNMP the capability of invoking traceroute from a remote host." ::= { remopsObjects 4 } remopsTraceRouteEntry OBJECT-TYPE SYNTAX RemopsTraceRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the remopsTraceRouteTable." INDEX { remopsTraceRouteOwnerIndex, remopsTraceRouteHostAddressType, remopsTraceRouteHostAddress } ::= { remopsTraceRouteTable 1 } RemopsTraceRouteEntry ::= SEQUENCE { remopsTraceRouteOwnerIndex SnmpAdminString, remopsTraceRouteHostAddressType RemopsHostAddressType, remopsTraceRouteHostAddress RemopsHostAddress, remopsTraceRouteCtlType BITS, remopsTraceRoutePacketSize Unsigned32, remopsTraceRouteTimeOut Unsigned32, remopsTraceRouteProbesPerHop Unsigned32, remopsTraceRoutePort Unsigned32, DISMAN Working Group Expires December 1998 [Page 13] Internet Draft REMOPS-MIB August 4, 1998 remopsTraceRouteMaxTtl Unsigned32, remopsTraceRouteTos Unsigned32, remopsTraceRouteSourceAddressType RemopsHostAddressType, remopsTraceRouteSourceAddress RemopsHostAddress, remopsTraceRouteInterfaceName OCTET STRING, remopsTraceRouteMiscOptions Utf8String, remopsTraceRouteMaxFailures Unsigned32, remopsTraceRouteOperStatus RemopsStatus, remopsTraceRouteRowStatus RowStatus } remopsTraceRouteOwnerIndex OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "To facilitate the provisioning of access control by a security administrator using the View-Based Access Control Model (RFC 2275, VACM) 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 this table 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." ::= { remopsTraceRouteEntry 1 } remopsTraceRouteHostAddressType OBJECT-TYPE SYNTAX RemopsHostAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies the address type of the destination." ::= { remopsTraceRouteEntry 2 } remopsTraceRouteHostAddress OBJECT-TYPE SYNTAX RemopsHostAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies the host address used on the traceroute request at the remote host. The host address specified is indicated by remopsTraceRouteHostAddressType." ::= { remopsTraceRouteEntry 3 } DISMAN Working Group Expires December 1998 [Page 14] Internet Draft REMOPS-MIB August 4, 1998 remopsTraceRouteCtlType OBJECT-TYPE SYNTAX BITS { enableNotifications(0), bypassRouteTable(1), noDnsLookup(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The purpose of this object is enable the following remote traceroute functions: enableNotifications(0) = enable NOTIFICATIONs for a remote traceroute operation. bypassRouteTable(2) = If selected bypass the normal routing tables and send directly to a host on an attached network. If the host is not on a directly-attached network, an error is returned. This option can be used to ping a local host through an interface that has no route through it (e.g., after the interface was dropped by routed). noDnsLookup(3) =Return hop addresses numerically rather symbolically. Enabling this option saves a nameserver lookup for each hop found on a path." DEFVAL { { enableNotifications, noDnsLookup } } ::= { remopsTraceRouteEntry 4 } remopsTraceRoutePacketSize OBJECT-TYPE SYNTAX Unsigned32 (0..65507) UNITS "octets" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the size of the data portion of a traceroute request in octets. A traceroute request is essentially transmitted by encoding a UDP datagram into a IP packet. So subtracting the size of a UDP header (8 octets) and the size of a IP header (20 octets) yields a maximum of 65507 octets." DEFVAL { 0 } ::= { remopsTraceRouteEntry 5 } remopsTraceRouteTimeOut OBJECT-TYPE SYNTAX Unsigned32 (1..60) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the time-out value, in seconds, for a traceroute request." DISMAN Working Group Expires December 1998 [Page 15] Internet Draft REMOPS-MIB August 4, 1998 DEFVAL { 3 } ::= { remopsTraceRouteEntry 6 } remopsTraceRouteProbesPerHop OBJECT-TYPE SYNTAX Unsigned32 (1..10) UNITS "count" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the number of times to reissue a traceroute request with the same time-to-live (TTL) value." DEFVAL { 3 } ::= { remopsTraceRouteEntry 7 } remopsTraceRoutePort OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "UDP Port" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the UDP port to sent the traceroute request to. Need to specify a port that is not in use at the destination host." DEFVAL { 4096 } ::= { remopsTraceRouteEntry 8 } remopsTraceRouteMaxTtl OBJECT-TYPE SYNTAX Unsigned32 (1..255) UNITS "time-to-live maximum" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum time-to-live value." DEFVAL { 30 } ::= { remopsTraceRouteEntry 9 } remopsTraceRouteTos OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the value to store in the TOS OCTET in the IP probe packet that is transmitted as the traceroute request. The value must be a decimal integer in the range 0 to 255. This option can be used to see if different types-of-service result in different paths. Not all values of TOS are legal or meaningful. TOS is often not supported by IP implementations. Useful values are probably '16' (low delay) and '8' (high throughput)." DEFVAL { 0 } ::= { remopsTraceRouteEntry 10 } remopsTraceRouteSourceAddressType OBJECT-TYPE DISMAN Working Group Expires December 1998 [Page 16] Internet Draft REMOPS-MIB August 4, 1998 SYNTAX RemopsHostAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the type of address that is stored in the corresponding remopsTraceRouteSetupSourceAddress. A value of none(1) indicates that the specification of a source address is not enabled." DEFVAL { none } ::= { remopsTraceRouteEntry 11 } remopsTraceRouteSourceAddress OBJECT-TYPE SYNTAX RemopsHostAddress MAX-ACCESS read-create STATUS current DESCRIPTION "Use the specified an IP address (which must be given as an IP number, not a hostname) as the source address in outgoing probe packets. On hosts with more than one IP address, this option can be used to force the source address to be something other than the IP address of the interface the probe packet is sent on. If the IP address is not one of this machine's interface addresses, an error is returned and nothing is sent." DEFVAL { ''H } ::= { remopsTraceRouteEntry 12 } remopsTraceRouteInterfaceName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "Setting this object to an interface's name prior to starting a remote traceroute operation directs the traceroute probes to be transmitted over the specified interface." DEFVAL { ''H } ::= { remopsTraceRouteEntry 13 } remopsTraceRouteMiscOptions OBJECT-TYPE SYNTAX Utf8String (SIZE(0..64)) MAX-ACCESS read-create STATUS current DESCRIPTION "Enables an application to specify implementation dependent options." DEFVAL { ''H } ::= { remopsTraceRouteEntry 14 } remopsTraceRouteMaxFailures OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-create STATUS current DISMAN Working Group Expires December 1998 [Page 17] Internet Draft REMOPS-MIB August 4, 1998 DESCRIPTION "The value of this object indicates the maximum number of consecutive timeouts allowed before terminating a remote traceroute request. A value of 255 (maximum hop count) indicate that the function of terminating a remote traceroute request when a number of successive timeouts are detected is disabled." DEFVAL { 5 } ::= { remopsTraceRouteEntry 15 } remopsTraceRouteOperStatus OBJECT-TYPE SYNTAX RemopsStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Reflects the operational state of a remote traceroute operation." ::= { remopsTraceRouteEntry 16 } remopsTraceRouteRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted in the remopsTraceRouteTable. A remote traceroute operation is started when an entry in this table is created via an SNMP SET request and the entry is activated. This can occur by setting the value of this object to CreateAndGo(4) during row creation or by setting this object to active(1) after the row is created. A remote traceroute request starts when its entry first becomes active(1). Transitions in and out of active(1) state have no effect on the operational behavior of a remote traceroute operation, with the exception that deletion of an entry in this table by setting its RowStatus object to destroy(6) will stop an active remote traceroute operation." REFERENCE "RFC 1903, 'Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { remopsTraceRouteEntry 17 } -- Remote Operations Traceroute Results Table remopsTraceRouteResultsTable OBJECT-TYPE SYNTAX SEQUENCE OF RemopsTraceRouteResultsEntry MAX-ACCESS not-accessible STATUS current DISMAN Working Group Expires December 1998 [Page 18] Internet Draft REMOPS-MIB August 4, 1998 DESCRIPTION "Defines the Remote Operations Traceroute Results Table for storing the results of a trace route operation." ::= { remopsObjects 5 } remopsTraceRouteResultsEntry OBJECT-TYPE SYNTAX RemopsTraceRouteResultsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the remopsTraceRouteResultsTable." INDEX { remopsTraceRouteOwnerIndex, remopsTraceRouteHostAddressType, remopsTraceRouteHostAddress, remopsTraceRouteResultsHopIndex, remopsTraceRouteResultsProbeIndex } ::= { remopsTraceRouteResultsTable 1 } RemopsTraceRouteResultsEntry ::= SEQUENCE { remopsTraceRouteResultsHopIndex Unsigned32, remopsTraceRouteResultsProbeIndex Unsigned32, remopsTraceRouteResultsHopDnsName Utf8String, remopsTraceRouteResultsHopAddress RemopsHostAddress, remopsTraceRouteResultsResponse Integer32 } remopsTraceRouteResultsHopIndex OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table has as its initial instance identifier the value of its corresponding remopsTraceRouteEntry's instance identifier." ::= { remopsTraceRouteResultsEntry 1 } remopsTraceRouteResultsProbeIndex OBJECT-TYPE SYNTAX Unsigned32 (1..10) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the index of a probe for determining a hop in a traceroute path." ::= { remopsTraceRouteResultsEntry 2 } remopsTraceRouteResultsHopDnsName OBJECT-TYPE SYNTAX Utf8String (SIZE(0..65)) MAX-ACCESS read-only STATUS current DESCRIPTION "The DNS name of a hop if not the zero length octet string." DISMAN Working Group Expires December 1998 [Page 19] Internet Draft REMOPS-MIB August 4, 1998 ::= { remopsTraceRouteResultsEntry 3 } remopsTraceRouteResultsHopAddress OBJECT-TYPE SYNTAX RemopsHostAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The address of a hop in a traceroute path. This object is not allowed to be a DNS name. The length of the octet string returned determines the address type." ::= { remopsTraceRouteResultsEntry 4 } remopsTraceRouteResultsResponse OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicated the result of a traceroute probe: >=0 Round-trip response time in milliseconds. -1 Internal error. -2 probe timed out. -3 Unknown destination address. -4 No route to host. -5 Interface inactive to host. -6 Failed to resolve host name. -7 remopsTraceRouteMaxConcurrentRequests limit reached." ::= { remopsTraceRouteResultsEntry 5 } -- Notifications remopsTraceRouteHopNotification NOTIFICATION-TYPE OBJECTS { remopsTraceRouteResultsHopDnsName, remopsTraceRouteResultsHopAddress, remopsTraceRouteResultsResponse } STATUS current DESCRIPTION "This object is generated when the enableNotifications(0) option via remopsTraceRouteSetupCtlType is enabled. The result of a hop is returned via this notification." ::= { remopsNotifications 1 } remopsPingNotification NOTIFICATION-TYPE OBJECTS { remopsPingResultsResponse } STATUS current DESCRIPTION "This object is generated when the enableNotifications(0) option via remopsPingCtlType is enabled. The result of a ping probe is returned in this notification." DISMAN Working Group Expires December 1998 [Page 20] Internet Draft REMOPS-MIB August 4, 1998 ::= { remopsNotifications 2 } --------------------------------------------------------------------- -- Conformance information -- Compliance statements --------------------------------------------------------------------- remopsCompliances OBJECT IDENTIFIER ::= { remopsConformance 1 } remopsGroups OBJECT IDENTIFIER ::= { remopsConformance 2 } --------------------------------------------------------------------- -- Compliance statements --------------------------------------------------------------------- remopsCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for the REMOPS-MIB." MODULE -- this module MANDATORY-GROUPS { remopsBaseGroup, remopsPingGroup, remopsTraceRouteGroup } GROUP remopsPingNotGroup DESCRIPTION "Notification support is optional." GROUP remopsTraceRouteNotGroup DESCRIPTION "Notification support is optional." OBJECT remopsPingMaxConcurrentRequests MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object." OBJECT remopsPingPurgeTime MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object." OBJECT remopsPingCtlType MIN-ACCESS not-accessible DESCRIPTION "An agent implementation is not required to determine the DNS name of a destination and hence support of this object is optional." OBJECT remopsTraceRouteMaxConcurrentRequests MIN-ACCESS read-only DISMAN Working Group Expires December 1998 [Page 21] Internet Draft REMOPS-MIB August 4, 1998 DESCRIPTION "The agent is not required to support a SET operation to this object." OBJECT remopsTraceRoutePurgeTime MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object." OBJECT remopsTraceRouteCtlType DESCRIPTION "Prevention of hop DNS lookup is the only REQUIRED remopsTraceRouteCtlType option." ::= { remopsCompliances 1 } --------------------------------------------------------------------- -- MIB groupings --------------------------------------------------------------------- remopsBaseGroup OBJECT-GROUP OBJECTS { remopsSpinLock } STATUS current DESCRIPTION "The group of objects common to both the remote ping and remote traceroute operations." ::= { remopsGroups 1 } remopsPingGroup OBJECT-GROUP OBJECTS { remopsPingMaxConcurrentRequests, remopsPingPurgeTime, remopsPingCtlType, remopsPingPacketSize, remopsPingTimeOut, remopsPingProbeCount, remopsPingOperStatus, remopsPingRowStatus, remopsPingResultsResponse } STATUS current DESCRIPTION "The group of objects that comprise the remote ping operation." ::= { remopsGroups 2 } remopsPingNotGroup NOTIFICATION-GROUP NOTIFICATIONS { remopsPingNotification } STATUS current DESCRIPTION DISMAN Working Group Expires December 1998 [Page 22] Internet Draft REMOPS-MIB August 4, 1998 "Defines the NOTIFICATION used by the remote ping operation." ::= { remopsGroups 3 } remopsTraceRouteGroup OBJECT-GROUP OBJECTS { remopsTraceRouteMaxConcurrentRequests, remopsTraceRoutePurgeTime, remopsTraceRouteCtlType, remopsTraceRoutePacketSize, remopsTraceRouteTimeOut, remopsTraceRouteProbesPerHop, remopsTraceRoutePort, remopsTraceRouteMaxTtl, remopsTraceRouteTos, remopsTraceRouteSourceAddressType, remopsTraceRouteSourceAddress, remopsTraceRouteInterfaceName, remopsTraceRouteMiscOptions, remopsTraceRouteMaxFailures, remopsTraceRouteOperStatus, remopsTraceRouteRowStatus, remopsTraceRouteResultsHopDnsName, remopsTraceRouteResultsHopAddress, remopsTraceRouteResultsResponse } STATUS current DESCRIPTION "The group of objects that comprise the remote traceroute operation." ::= { remopsGroups 4 } remopsTraceRouteNotGroup NOTIFICATION-GROUP NOTIFICATIONS { remopsTraceRouteHopNotification } STATUS current DESCRIPTION "Defines the NOTIFICATION used by the remote traceroute operation." ::= { remopsGroups 5 } END  5.0 Security Considerations Certain management information defined in this MIB may be considered sensitive in some network environments. Therefore, authentication of received SNMP requests and controlled access to management information SHOULD be employed in such environments. The method for this authentication is a function of the SNMP Administrative Framework, and has not been expanded by this MIB. DISMAN Working Group Expires December 1998 [Page 23] Internet Draft REMOPS-MIB August 4, 1998 It is RECOMMENDED that this MIB not be supported in insecure environments. 6.0 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 implementers 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. 7.0 Acknowledgments This document is a product of the DISMAN Working Group. 8.0 References [1] Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [3] Case, J., McCloghrie, K., Rose, M., and Waldbusser S., "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996. [5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, January 1996. DISMAN Working Group Expires December 1998 [Page 24] Internet Draft REMOPS-MIB August 4, 1998 [6] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [7] Harrington D., Presuhn, R., Wijnen, B., "An Architecture for Describing SNMP Management Frameworks", RFC 2271, Cabletron Systems, BMC Software, Inc., IBM T.J. Watson Research, January 1998. [8] Harrington D., Presuhn, R., Wijnen, B., "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, Cabletron Systems, BMC Software, Inc., IBM T.J. Watson Research, January 1998. [9] Levi D., Meyer P., Stewart, B., "SNMPv3 Applications", RFC 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, January 1998. [10] Blumenthal, U., Wijnen, B., "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. [11] Wijnen, B., Presuhn, R., McCloghrie, K., "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, IBM T.J. Watson Research, BMC Software, Inc., Cisco Systems, Inc., January 1998. [12] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [13] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [14] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [15] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [16] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991. [17] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [18] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. DISMAN Working Group Expires December 1998 [Page 25] Internet Draft REMOPS-MIB August 4, 1998 9.0 Author's Address Kenneth D. White Dept. BRQA/Bldg. 501/G114 IBM Corporation P.O.Box 12195 3039 Cornwallis Research Triangle Park, NC 27709, USA E-mail: kennethw@vnet.ibm.com 10.0 Full Copyright Statement Copyright (C) The Internet Society (1997). 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. DISMAN Working Group Expires December 1998 [Page 26] From maria@xedia.com Thu Aug 6 14:39:25 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA19671 for ; Thu, 6 Aug 1998 14:39:23 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA24202 for ; Thu, 6 Aug 1998 14:37:59 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024189; Thu, 6 Aug 98 14:37:43 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA16837 for ; Thu, 6 Aug 1998 14:37:08 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma016743; Thu, 6 Aug 98 14:36:59 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA02290; Thu, 6 Aug 1998 14:37:31 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA13158 for ; Thu, 6 Aug 1998 12:37:30 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA24175 for ; Thu, 6 Aug 1998 14:37:28 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by almond.bmc.com via smap (V2.0) id xma024155; Thu, 6 Aug 98 14:37:00 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id PAA08745; Thu, 6 Aug 1998 15:34:10 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id PAA07138 for ; Thu, 6 Aug 1998 15:33:46 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id PAA08731 for ; Thu, 6 Aug 1998 15:33:40 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA23918 for ; Thu, 6 Aug 1998 14:33:37 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma023876; Thu, 6 Aug 98 14:33:06 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA13316 for ; Thu, 6 Aug 1998 14:32:30 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma013072; Thu, 6 Aug 98 14:32:09 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA00508 for ; Thu, 6 Aug 1998 14:32:43 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA13078 for disman@nexen.com; Thu, 6 Aug 1998 12:32:42 -0700 (PDT) Date: Thu, 6 Aug 1998 12:32:42 -0700 (PDT) From: Randy Presuhn Message-Id: <199808061932.MAA13078@dorothy.bmc.com> To: disman@nexen.com Subject: Re: WG Last Call: schedule MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - Since the editors have agreed to handle all the review comments received during the WG last call on the schedule MIB, and since there have been objections to the proposed resolutions of these comments, I'd like to close the WG last call on August seventh, 1998, as suggested last week. If you feel the need for another round of review before forwarding the revised drafts to the ADs for the IESG review, PLEASE raise your concerns NOW. If you're committed to reviewing the draft and don't have sufficient time to do so, PLEASE let me know. Otherwise, if the editors get it submitted by the I-D submission deadline, I will declare the WG last call complete this Friday afternoon. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From maria@xedia.com Thu Aug 6 16:50:35 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA20664 for ; Thu, 6 Aug 1998 16:50:34 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA06085 for ; Thu, 6 Aug 1998 16:49:11 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma006081; Thu, 6 Aug 98 16:48:58 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA23608 for ; Thu, 6 Aug 1998 16:48:22 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma023201; Thu, 6 Aug 98 16:48:00 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA13162; Thu, 6 Aug 1998 16:48:15 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA14129 for ; Thu, 6 Aug 1998 14:47:57 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id QAA16594 for ; Thu, 6 Aug 1998 16:47:55 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by cashew.bmc.com via smap (V2.0) id xma016539; Thu, 6 Aug 98 16:47:01 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id RAA10035; Thu, 6 Aug 1998 17:43:50 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id RAA16721 for ; Thu, 6 Aug 1998 17:40:40 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id RAA10009 for ; Thu, 6 Aug 1998 17:40:20 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA05512 for ; Thu, 6 Aug 1998 16:40:18 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma005494; Thu, 6 Aug 98 16:39:50 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA15531 for ; Thu, 6 Aug 1998 16:39:15 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma015465; Thu, 6 Aug 98 16:39:09 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA10515 for ; Thu, 6 Aug 1998 16:39:40 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA13921 for disman@nexen.com; Thu, 6 Aug 1998 14:39:39 -0700 (PDT) Date: Thu, 6 Aug 1998 14:39:39 -0700 (PDT) From: Randy Presuhn Message-Id: <199808062139.OAA13921@dorothy.bmc.com> To: disman@nexen.com Subject: Re: New REMOPS-MIB draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > From: kennethw@VNET.IBM.COM > Date: Thu, 6 Aug 98 09:37:35 EDT > To: internet-drafts@ietf.org > cc: disman@nexen.com > Subject: New REMOPS-MIB draft > > Please post the attached internet-draft as > . ... Thank-you Ken for the update. Now that the WG last call is complete for the script MIB, and all but complete for the schedule MIB, and now that Bob Stewart has delivered his updated drafts so we'll soon be able to wrap up those MIBs, it's time to officially start the discussion on whether the disman working group should request that the approximate functionality covered by the REMOPS-MIB draft should be added to our charter. This Spring there were some discussions on the relationship of MIBs like this to the script MIB; now it's time to decide whether we as a working group want to work on it. Here's a first cut at a proposal for an addition to the WG charter: | - Special-purpose MIBs for performing specific useful remote | operations, such as ping and traceroute. Is this too broad, too specific, not worth doing, or better said in a completely different way? I would also appreciate comments on an appropriate, realistic timetable if we choose to attack this problem. Agreement to add this work item to our charter should NOT be construed as approval of the REMOPS-MIB in its current form; rather that draft would be just one input into our work. Comments appreciated. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From maria@xedia.com Thu Aug 6 17:14:25 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id RAA20858 for ; Thu, 6 Aug 1998 17:14:24 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA10114 for ; Thu, 6 Aug 1998 17:13:00 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma010091; Thu, 6 Aug 98 17:12:28 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA15718 for ; Thu, 6 Aug 1998 17:11:52 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma015361; Thu, 6 Aug 98 17:11:27 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA19376; Thu, 6 Aug 1998 17:11:59 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA14436 for ; Thu, 6 Aug 1998 15:11:56 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA10046 for ; Thu, 6 Aug 1998 17:11:53 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by almond.bmc.com via smap (V2.0) id xma009378; Thu, 6 Aug 98 17:09:26 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id SAA10198; Thu, 6 Aug 1998 18:06:21 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id SAA18463 for ; Thu, 6 Aug 1998 18:05:09 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id SAA10180 for ; Thu, 6 Aug 1998 18:05:07 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA08211 for ; Thu, 6 Aug 1998 17:05:05 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma007825; Thu, 6 Aug 98 17:04:13 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA07839 for ; Thu, 6 Aug 1998 17:03:36 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma005113; Thu, 6 Aug 98 17:01:26 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA17146 for ; Thu, 6 Aug 1998 17:01:58 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA14281 for disman@nexen.com; Thu, 6 Aug 1998 15:01:57 -0700 (PDT) Date: Thu, 6 Aug 1998 15:01:57 -0700 (PDT) From: Randy Presuhn Message-Id: <199808062201.PAA14281@dorothy.bmc.com> To: disman@nexen.com Subject: Re: I-D ACTION:draft-ietf-disman-event-mib-04.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > To: IETF-Announce: ; > Cc: disman@nexen.com > From: Internet-Drafts@ietf.org > Reply-to: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-ietf-disman-event-mib-04.txt > Date: Thu, 06 Aug 1998 09:30:24 -0400 ... > Title : Event MIB > Author(s) : B. Stewart > Filename : draft-ietf-disman-event-mib-04.txt > Pages : 34 > Date : 05-Aug-98 ... Thanks to Bob Stewart for getting this out. I have a few quick comments that have more to do with the form than the substance of the draft, but these things do have to get taken care of. 2026 The Internet Standards Process -- Revision 3. The disclaimers required by RFC 2026 clause 10.4 are absent. 2119 Key words for use in RFCs to Indicate Requirement Levels. Since the use of these terms appears to be (intended to be) consistent with RFC 2119, the appropriate reference and incantation would be helpful. 2223 Instructions to RFC Authors. The references section is not in the "current style" as required by RFC 2223 clause 8. (Lastname, F., Lastname, F. and F. Lastname), note lack of comma before "and"; some entries lack the final ".". The authors address (section 12) lack country identification (USA)and telephone country codes (+1). (See RFC 2223 clause 10.) The copyright notice required by RFC 2223 clause 11 (and RFC 2026) is missing. The following eight lines exceed the 72-character limit, and should be split appropriately: > "Reasons for failures in an attempt to send a management message. > "A locally-unique, administratively assigned name for the trigger." > is 'true' and the first sample after this entry becomes active is > "A locally-unique, administratively assigned name for the event." > This object identifier may be wildcarded by leaving sub-identifiers > eventMIBNotifications OBJECT IDENTIFIER ::= { eventMIBNotificationPrefix 0 } > inluding filling in wildcard informaation determined in processing. > For a trigger-related notification this is from mteTriggerValueID. Folks, we need to get in any comments needed on the SUBSTANCE of this draft so we can finish off this work item. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From maria@xedia.com Thu Aug 6 17:56:43 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id RAA21167 for ; Thu, 6 Aug 1998 17:56:43 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA12391 for ; Thu, 6 Aug 1998 17:55:19 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012379; Thu, 6 Aug 98 17:54:58 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA13764 for ; Thu, 6 Aug 1998 17:54:22 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma013734; Thu, 6 Aug 98 17:54:20 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA00896; Thu, 6 Aug 1998 17:54:52 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA15189 for ; Thu, 6 Aug 1998 15:54:37 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id RAA19518 for ; Thu, 6 Aug 1998 17:54:36 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by cashew.bmc.com via smap (V2.0) id xma019487; Thu, 6 Aug 98 17:54:04 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id SAA10367; Thu, 6 Aug 1998 18:51:42 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id SAA21419 for ; Thu, 6 Aug 1998 18:51:03 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id SAA10357 for ; Thu, 6 Aug 1998 18:51:02 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA12112 for ; Thu, 6 Aug 1998 17:51:01 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012105; Thu, 6 Aug 98 17:50:49 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA11636 for ; Thu, 6 Aug 1998 17:50:14 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma011511; Thu, 6 Aug 98 17:49:57 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA29531 for ; Thu, 6 Aug 1998 17:50:29 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA14602 for disman@nexen.com; Thu, 6 Aug 1998 15:50:28 -0700 (PDT) Date: Thu, 6 Aug 1998 15:50:28 -0700 (PDT) From: Randy Presuhn Message-Id: <199808062250.PAA14602@dorothy.bmc.com> To: disman@nexen.com Subject: Re: I-D ACTION:draft-ietf-disman-notif-log-mib-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > To: IETF-Announce: ; > Cc: disman@NEXEN.COM > From: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-ietf-disman-notif-log-mib-03.txt > Date: Wed, 05 Aug 1998 09:47:17 -0400 ... > Title : Notification Log MIB > Author(s) : B. Stewart > Filename : draft-ietf-disman-notif-log-mib-03.txt > Pages : 21 > Date : 04-Aug-98 ... Thanks are due Bob Stewart for getting out this draft. I urge folks to read it and give comments, and to consider carefully the implementation consequences of the security section. I have a few comments on the document's form (rather than its substance, those require more thought): 2026 The Internet Standards Process -- Revision 3. The disclaimers required by RFC 2026 clause 10.4 are absent. 2119 Key words for use in RFCs to Indicate Requirement Levels. Since the use of these terms appears to be (intended to be) consistent with RFC 2119, the appropriate reference and incantation would be helpful. 2223 Instructions to RFC Authors. The references section is not in the "current style" as required by RFC 2223 clause 8. (Lastname, F., Lastname, F. and F. Lastname); final "." missing for some entries. The author's address (section 7) lacks country identification (USA) and telephone country codes (+1) (See RFC 2223 clause 10) The copyright notice required by RFC 2223 clause 11 (and RFC 2026) is missing. The following seven lines exceed the 72-character maximum: < nlmConfig OBJECT IDENTIFIER ::= { notificationLogMIBObjects 1 } < nlmStats OBJECT IDENTIFIER ::= { notificationLogMIBObjects 2 } < nlmLog OBJECT IDENTIFIER ::= { notificationLogMIBObjects 3 } < If an application changes the limit while there are Notifications < may not include internal overhead and is free to use any internal < nlmLogIndex, for indexing variables within the logged Notification." < notificationLogMIBConformance OBJECT IDENTIFIER ::= { notificationLogMIB 3 } ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From maria@xedia.com Thu Aug 6 18:29:35 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id SAA21428 for ; Thu, 6 Aug 1998 18:29:34 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA13814 for ; Thu, 6 Aug 1998 18:28:10 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma013810; Thu, 6 Aug 98 18:28:06 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id SAA00718 for ; Thu, 6 Aug 1998 18:27:30 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma000605; Thu, 6 Aug 98 18:27:12 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id SAA08448; Thu, 6 Aug 1998 18:27:44 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA15490 for ; Thu, 6 Aug 1998 16:27:41 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA13791 for ; Thu, 6 Aug 1998 18:27:40 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by almond.bmc.com via smap (V2.0) id xma013780; Thu, 6 Aug 98 18:27:19 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id TAA10526; Thu, 6 Aug 1998 19:24:16 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id TAA23559 for ; Thu, 6 Aug 1998 19:24:09 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id TAA10516 for ; Thu, 6 Aug 1998 19:24:08 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA13672 for ; Thu, 6 Aug 1998 18:24:04 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma013652; Thu, 6 Aug 98 18:23:35 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id SAA28453 for ; Thu, 6 Aug 1998 18:22:59 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma028294; Thu, 6 Aug 98 18:22:39 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id SAA07469 for ; Thu, 6 Aug 1998 18:23:11 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA15429 for disman@nexen.com; Thu, 6 Aug 1998 16:23:10 -0700 (PDT) Date: Thu, 6 Aug 1998 16:23:10 -0700 (PDT) From: Randy Presuhn Message-Id: <199808062323.QAA15429@dorothy.bmc.com> To: disman@nexen.com Subject: Re: Internet Draft - Expression MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Wed, 05 Aug 1998 19:13:35 -0400 > To: Distributed Management WG > From: Bob Stewart > Subject: Internet Draft - Expression MIB > > Here is a new draft of the Expression MIB as submitted to become: > > draft-ietf-disman-notif-log-mib-05.txt. Thanks for getting this out. I think this was meant to be draft-ietf-disman-express-mib-05.txt Even though the i-d has not yet appeared, I have a few comments on the document's form. 2026 The Internet Standards Process -- Revision 3. The disclaimers required by RFC 2026 clause 10.4 are absent. 2119 Key words for use in RFCs to Indicate Requirement Levels. Since the use of these terms appears to be (intended to be) consistent with RFC 2119, the appropriate reference and incantation would be helpful. 2223 Instructions to RFC Authors. The references section is not in the "current style" as required by RFC 2223 clause 8. (Lastname, F., Lastname, F. and F. Lastname); final "." missing for some entries. The author's address (section 8) lacks country identification (USE) and telephone country codes (+1). (See RFC 2223 clause 10) The copyright notice required by RFC 2223 clause 11 (and RFC 2026) is missing. The following lines exceed the 72-character maximum, and should be split appropriately. < -- of the object identifier, and sets expObjectWildcard to true(1) for that < -- For example purposes we'll use some slightly far-fetched OIDs, but the < -- weirdity won't matter. The People MIB is 1.3.6.1.99.7 and the Town MIB < -- exactly. In this case that means we have to hardwire the town and only < -- the personIndex can be wildcarded. So our values for expObjectID are: < -- The value of expExpressionPrefix can be either of those two counter OIDs < -- doesn't have to work out to be the same object, but it does have to work < -- Note that the agent can not typically check such semantics and if given < -- So there will be three values in expValueTable, with those OIDs as the < "The number of times this system could not evaluate an expression < any ordering on the creation of objects related to an expression. < may use the results of another expression, it may not contain any < Rules for the resulting data type from an operation, based on the < For +, -, *, /, %, &, |, and ^ the result is promoted according to < If left hand and right hand operands are the same type, use < The following rules say what operators apply with what data types. < The + operator performs a concatenation of two OCTET STRINGs or two < The operators &, | perform bitwise operations on OCTET STRINGs. If < the OCTET STRING happens to be a DisplayString the results may be < meaningless, but the agent system does not check this as some such < The operators << and >> perform bitwise operations on OCTET STRINGs < arraySection(array, integer, integer) - selects a piece of an array < (i.e. part of an OCTET STRING or OBJECT IDENTIFIER). The integer < index. A value of 0 indicates first or last element, respectively. < If the first element is larger than the array length the result is < sum(integerObject*) - sums all availiable values of the wildcarded < return value of 0 indicates NoSuchInstance (i.e. boolean false)." < "The type of the expression value. One and only one of the value < objects in expValueTable will be instantiated to match this type. < valid Expression MIB expression syntax (S) < undefinedObjectIndex an object reference ($n) in expExpression < expResourceDeltaWildcardInstanceMaximum (E) < recursion through some chain of embedded expressions < divideByZero an attempt to divide by zero occurred (E) < expExpression Set request fails with the SNMP error code 'wrongValue'. < "The entity that configured this entry and is therefore using the < If all expObjectWildcard values for a given expression are FALSE, < This object is not instantiated if expObject is not 'deltaValue'. < "A true value indicates the expObjectDeltaDiscontinuityID of this < This object is not instantiated if expObject is not 'deltaValue'. < "The value 'timeTicks' indicates the expObjectDeltaDiscontinuityID < This object is not instantiated if expObject is not 'deltaValue'." < expObjectConditional must match the wildcarding of the rest of the < expObjectConditional is, use the lexically first instance (if any) < Note that expObjectConditional can not trivially use an object of < "A true value indicates the expObjectConditional of this row is a < wildcard object. False indicates that expObjectConditional is fully < causes the evaluation of the expression for that value. For those < expressionMIBCompliances OBJECT IDENTIFIER ::= { expressionMIBConformance 1 } < expressionMIBGroups OBJECT IDENTIFIER ::= { expressionMIBConformance 2 } < "Implementation need not allow deltas or it may implement The security considerations section is kinda cheesy, to use a technical phrase. :-) ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From maria@xedia.com Fri Aug 7 03:11:22 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id DAA25373 for ; Fri, 7 Aug 1998 03:11:21 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id DAA27807 for ; Fri, 7 Aug 1998 03:09:57 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma027803; Fri, 7 Aug 98 03:09:46 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id DAA05108 for ; Fri, 7 Aug 1998 03:09:11 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma005048; Fri, 7 Aug 98 03:08:54 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id DAA13117; Fri, 7 Aug 1998 03:09:27 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id BAA18576 for ; Fri, 7 Aug 1998 01:09:13 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id DAA06533 for ; Fri, 7 Aug 1998 03:09:11 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by cashew.bmc.com via smap (V2.0) id xma006529; Fri, 7 Aug 98 03:08:41 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id EAA12735; Fri, 7 Aug 1998 04:04:29 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id EAA26532 for ; Fri, 7 Aug 1998 04:03:53 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id EAA12725 for ; Fri, 7 Aug 1998 04:03:51 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.1/8.9.0) with ESMTP id KAA00504; Fri, 7 Aug 1998 10:03:49 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA05369; Fri, 7 Aug 1998 10:03:49 +0200 Date: Fri, 7 Aug 1998 10:03:49 +0200 Message-Id: <199808070803.KAA05369@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.bmc.com CC: disman@nexen.com In-reply-to: <199808062139.OAA13921@dorothy.bmc.com> (message from Randy Presuhn on Thu, 6 Aug 1998 14:39:39 -0700 (PDT)) Subject: Re: New REMOPS-MIB draft References: <199808062139.OAA13921@dorothy.bmc.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Randy Presuhn writes: Randy> Now that the WG last call is complete for the script MIB, and Randy> all but complete for the schedule MIB, and now that Bob Stewart Randy> has delivered his updated drafts so we'll soon be able to wrap Randy> up those MIBs, it's time to officially start the discussion on Randy> whether the disman working group should request that the Randy> approximate functionality covered by the REMOPS-MIB draft Randy> should be added to our charter. Randy> This Spring there were some discussions on the relationship of Randy> MIBs like this to the script MIB; now it's time to decide Randy> whether we as a working group want to work on it. Here's a Randy> first cut at a proposal for an addition to the WG charter: Randy> | - Special-purpose MIBs for performing specific useful remote Randy> | operations, such as ping and traceroute. Randy> Is this too broad, too specific, not worth doing, or better Randy> said in a completely different way? I would also appreciate Randy> comments on an appropriate, realistic timetable if we choose to Randy> attack this problem. Randy> Agreement to add this work item to our charter should NOT be Randy> construed as approval of the REMOPS-MIB in its current form; Randy> rather that draft would be just one input into our work. We have spend quite some time on the script MIB, which can be seen as a "standard" mechanism to call arbitrary management functions on remote systems. It allows hard-wired "scripts" and you can implement it without having to implement the capability to actually download and install new scripts. And the script MIB is designed to handle security issues. If we have all this in place, whats the value to have additional special purpose calling conventions for selected management functions on remote systems? Should we not better use (and probably improve if that is really necessary) what we have instead of re-inventing the wheel again and again? Having said this, I see great value in defining a set of "standard functions" like doing a traceroute or a simple ping in order to make it easy to use these functions in a vendor neutral way. So, yes, we should extend our charter, but we should be very careful about the wordings we use. I am not even sure that we need special-purpose *MIBs* in the traditional sense. What about the following text: : - A set of special-purpose management functions for performing : specific useful remote operations, such as ping and traceroute. This leaves it open how the WG actually defines them. Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) From maria@xedia.com Fri Aug 7 08:04:55 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id IAA27539 for ; Fri, 7 Aug 1998 08:04:54 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id IAA07026 for ; Fri, 7 Aug 1998 08:03:29 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma007022; Fri, 7 Aug 98 08:03:26 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id IAA26160 for ; Fri, 7 Aug 1998 08:02:51 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma026077; Fri, 7 Aug 98 08:02:41 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id IAA09206; Fri, 7 Aug 1998 08:03:13 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA19142 for ; Fri, 7 Aug 1998 06:03:00 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id IAA07003 for ; Fri, 7 Aug 1998 08:02:58 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by almond.bmc.com via smap (V2.0) id xma006938; Fri, 7 Aug 98 08:02:31 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id IAA13773; Fri, 7 Aug 1998 08:59:29 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id IAA15608 for ; Fri, 7 Aug 1998 08:58:32 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id IAA13763 for ; Fri, 7 Aug 1998 08:58:29 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA10256; Fri, 7 Aug 1998 08:58:24 -0400 (EDT) Message-Id: <199808071258.IAA10256@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@nexen.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-express-mib-05.txt Date: Fri, 07 Aug 1998 08:58:23 -0400 Sender: cclark@ns.cnri.reston.va.us --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 : Expression MIB Author(s) : B. Stewart Filename : draft-ietf-disman-express-mib-05.txt Pages : 38 Date : 06-Aug-98 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 used for managing expressions of MIB objects. Internet-Drafts are 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-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-express-mib-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-express-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980806112633.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-express-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-express-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980806112633.I-D@ietf.org> --OtherAccess-- --NextPart-- From maria@xedia.com Fri Aug 7 08:22:25 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id IAA27676 for ; Fri, 7 Aug 1998 08:22:25 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id IAA07768 for ; Fri, 7 Aug 1998 08:20:59 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma007756; Fri, 7 Aug 98 08:20:39 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id IAA08293 for ; Fri, 7 Aug 1998 08:20:04 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma008191; Fri, 7 Aug 98 08:19:56 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id IAA13908; Fri, 7 Aug 1998 08:20:29 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA19175 for ; Fri, 7 Aug 1998 06:20:28 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id IAA15856 for ; Fri, 7 Aug 1998 08:20:26 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by cashew.bmc.com via smap (V2.0) id xma015849; Fri, 7 Aug 98 08:20:18 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id JAA13912; Fri, 7 Aug 1998 09:17:33 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id JAA17157 for ; Fri, 7 Aug 1998 09:17:26 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id JAA17438 for ; Fri, 7 Aug 1998 09:17:24 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA11235; Fri, 7 Aug 1998 09:17:21 -0400 (EDT) Message-Id: <199808071317.JAA11235@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@nexen.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-remops-mib-01.txt Date: Fri, 07 Aug 1998 09:17:20 -0400 Sender: cclark@ns.cnri.reston.va.us --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 Remote Operations Using SMIv2 Author(s) : K. White Filename : draft-ietf-disman-remops-mib-01.txt Pages : 26 Date : 06-Aug-98 This memo defines a Management Information Base (MIB) for performing remote operations (ping and traceroute) at a remote host. When managing a network it is useful to be able to retrieve the results of either a ping or traceroute operation when performed at a remote host. Currently, there exists several enterprise defined MIBs for performing both a remote ping or traceroute operation. The purpose of this memo is to defined a standards-based solution to enable interoperibility. Internet-Drafts are 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-remops-mib-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-remops-mib-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: <19980806162415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-remops-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-remops-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980806162415.I-D@ietf.org> --OtherAccess-- --NextPart-- From maria@xedia.com Fri Aug 7 14:52:38 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA00868 for ; Fri, 7 Aug 1998 14:52:37 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA05949 for ; Fri, 7 Aug 1998 14:51:12 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma005929; Fri, 7 Aug 98 14:50:49 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA23416 for ; Fri, 7 Aug 1998 14:50:13 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma023062; Fri, 7 Aug 98 14:49:42 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA18836; Fri, 7 Aug 1998 14:49:59 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA23503 for ; Fri, 7 Aug 1998 12:49:44 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA05896 for ; Fri, 7 Aug 1998 14:49:42 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by almond.bmc.com via smap (V2.0) id xma005890; Fri, 7 Aug 98 14:49:29 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id PAA18446; Fri, 7 Aug 1998 15:41:19 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id PAA16893 for ; Fri, 7 Aug 1998 15:40:52 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id PAA18423 for ; Fri, 7 Aug 1998 15:40:46 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.1/8.9.0) with ESMTP id VAA25842; Fri, 7 Aug 1998 21:40:44 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id VAA03542; Fri, 7 Aug 1998 21:40:42 +0200 Date: Fri, 7 Aug 1998 21:40:42 +0200 Message-Id: <199808071940.VAA03542@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: internet-drafts@ietf.org CC: disman@nexen.com, levi@snmp.com Subject: draft-ietf-disman-schedule-mib-05.txt Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Please post the attached document as Internet Draft . This document is created on behalf of the Distributed Management WG. Juergen Internet-Draft Schedule MIB August 1998 Definitions of Managed Objects for Scheduling Management Operations August 7, 1998 David B. Levi SNMP Research, Inc. levi@snmp.com Juergen Schoenwaelder TU Braunschweig schoenw@ibr.cs.tu-bs.de Status of this Memo This document is an Internet-Draft. 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.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Please send comments to the Distributed Management Working Group, . Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Expires January 1999 [Page 1] Internet-Draft Schedule MIB August 1998 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 a set of managed objects that are used to schedule management operations periodically or at specified dates and times. 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. This memo does not specify a standard for the Internet community. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. 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 RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed Expires January 1999 [Page 2] Internet-Draft Schedule MIB August 1998 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 MIB defined in this memo provides scheduling of actions periodically or at specified dates and times. The actions can be used to realize on-duty / off-duty schedules or to trigger management functions in a distributed management application. Schedules can be enabled or disabled by modifying a control object. This allows pre-configured schedules which are activated or de- activated by some other management functions. The term `scheduler' is used throughout this memo to refer to the entity which implements the scheduling MIB and which invokes the actions at the specified points in time. 3.1. Periodic Schedules Periodic schedules are based on fixed time periods between the initiation of scheduled actions. Periodic schedules are defined by specifying the number of seconds between two initiations. The time needed to complete the action is usually not known by the scheduler and does therefore not influence the next scheduling point. Implementations must guarantee that action invocations will not occur before their next scheduled time. However, implementations may be forced to delay invocations in the face of local constraints (e.g., a heavy load on higher-priority tasks). An accumulation of such delays would result in a drift of the scheduling interval with respect to time, and should be avoided. Scheduled actions collecting statistical data should retrieve time Expires January 1999 [Page 3] Internet-Draft Schedule MIB August 1998 stamps from the data source and not rely on the accuracy of the periodic scheduler in order to obtain accurate statistics. 3.2. Calendar Schedules Calendar schedules trigger scheduled actions at specified days of the week and days of the month. Calendar schedules are therefore aware of the notion of months, days, weekdays, hours and minutes. It is possible to specify multiple values for each calendar item. This provides a mechanism for defining complex schedules. For example, a schedule could be defined which triggers an action every 15 minutes on a given weekday. Months, days and weekdays are specified using the objects schedMonth, schedDay and schedWeekDay of type BITS. Setting multiple bits to one in these objects causes an OR operation. For example, setting the bits monday(1) and friday(5) in schedWeekDay restricts the schedule to Mondays and Fridays. The bit fields for schedMonth, schedDay and schedWeekDay are combined using an AND operation. For example, setting the bits june(5) and july(6) in schedMonth and combining it with the bits monday(1) and friday(5) set in schedWeekDay will result in a schedule which is restricted to every Monday and Friday in the months June and July. Wildcarding of calendar items is achieved by setting all bits to one. It is possible to define calendar schedules that will never trigger an action. For example, one can define a calendar schedule which should trigger an action on February 31st. Schedules like this will simply be ignored by the scheduler. Finally, calendar schedules are always expressed in local time. A scalar, schedLocalTime is provided so that a manager can retrieve the notion of local time and the offset to GMT time. 3.3. One-shot Schedules One-shot Schedules are similar to calendar schedules. The difference between a calendar schedule and a one-shot schedule is that a one- shot schedule will automatically disable itself once an action has been invoked. Expires January 1999 [Page 4] Internet-Draft Schedule MIB August 1998 3.4. Time Transitions When a system's notion of time is changed for some reason, implementations of the Schedule MIB must schedule actions differently. One example of a change to a system's notion of time is when a daylight savings time transition occurs. There are two possible situations when a time transition occurs. First, time may be set backwards, in which case particular times will appear to occur twice within the same day. These are called 'ambiguous times'. Second, time may be set forwards, in which case particular times will appear to not occur within a day. This are called 'nonexistent times'. When an action is configured in the Schedule MIB to occur at an ambiguous time during a time transition, the action should only be invoked at the first occurence of the ambiguous time. For example, if an action is scheduled to occur at 2:00 am, and a time transition occurs at 3:00 am which sets the clock back to 2:00 am, the action should only be invoked at the first occurence of 2:00 am. When an action is configured in the Schedule MIB to occur at a nonexistent time, the action should be invoked immediately upon a time transition. If multiple actions are invoked in this way, they should be invoked in the order in which they normally would be invoked had the time transition not occured. For example, if an action (a) is scheduled at 2:05 am and another action (b) at 2:10 am, then both actions should be invoked at 3:00 am in the order (a),(b) if the time jumps forward from 2:00 am to 3:00 am. 3.5. Actions Scheduled actions are modeled by SNMP set operations on local MIB variables. Scheduled actions described in this MIB are further restricted to objects of type INTEGER. This restriction does not limit the usefulness of the MIB. Simple schedules such as on-duty / off-duty schedules for resources that have a status MIB object (e.g. ifAdminStatus) are possible. More complex actions can be realized by triggering a management script which is responsible for performing complex state transitions. A management script can also be used to perform SNMP set operations on remote SNMP engines. Expires January 1999 [Page 5] Internet-Draft Schedule MIB August 1998 4. Definitions DISMAN-SCHEDULE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Unsigned32, Counter32, experimental FROM SNMPv2-SMI TEXTUAL-CONVENTION, DateAndTime, RowStatus, StorageType, VariablePointer FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; schedMIB MODULE-IDENTITY LAST-UPDATED "9808071800Z" ORGANIZATION "IETF DISMAN Working Group" CONTACT-INFO "David B. Levi SNMP Research, Inc. 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 U.S.A. Tel: +1 423 573 1434 E-mail: levi@snmp.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 MIB which provides mechanisms to schedule SNMP set operations periodically or at specific points in time." -- XXX Replace with real registration number from IANA. Note, the -- XXX IMPORTS must be updated when the real number is assigned. -- ::= { mib-2 XXXX } ::= { experimental 6789 } Expires January 1999 [Page 6] Internet-Draft Schedule MIB August 1998 -- -- The various groups defined within this MIB definition: -- schedObjects OBJECT IDENTIFIER ::= { schedMIB 1 } schedNotifications OBJECT IDENTIFIER ::= { schedMIB 2 } schedConformance OBJECT IDENTIFIER ::= { schedMIB 3 } -- -- Textual Conventions: -- SnmpPduErrorStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC enumerates the SNMPv1 and SNMPv2 PDU error status codes as defined in RFC 1157 and RFC 1905. It also adds a pseudo error status code `noResponse' which indicates a timeout condition." SYNTAX INTEGER { noResponse(-1), noError(0), tooBig(1), noSuchName(2), badValue(3), 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) } -- -- Some scalars which provide information about the local time zone. -- schedLocalTime OBJECT-TYPE Expires January 1999 [Page 7] Internet-Draft Schedule MIB August 1998 SYNTAX DateAndTime (SIZE (11)) MAX-ACCESS read-only STATUS current DESCRIPTION "The local time used by the scheduler. Schedules which refer to calendar time will use the local time indicated by this object. An implementation MUST return all 11 bytes of the DateAndTime textual-convention so that a manager may retrieve the offset from GMT time." ::= { schedObjects 1 } -- -- The schedule table which controls the scheduler. -- schedTable OBJECT-TYPE SYNTAX SEQUENCE OF SchedEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines scheduled actions triggered by SNMP set operations." ::= { schedObjects 2 } schedEntry OBJECT-TYPE SYNTAX SchedEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular scheduled action." INDEX { schedOwner, schedName } ::= { schedTable 1 } SchedEntry ::= SEQUENCE { schedOwner SnmpAdminString, schedName SnmpAdminString, schedDescr SnmpAdminString, schedInterval Unsigned32, schedWeekDay BITS, schedMonth BITS, schedDay BITS, schedHour BITS, schedMinute BITS, schedContextName SnmpAdminString, schedVariable VariablePointer, schedValue Integer32, schedType INTEGER, Expires January 1999 [Page 8] Internet-Draft Schedule MIB August 1998 schedAdminStatus INTEGER, schedOperStatus INTEGER, schedFailures Counter32, schedLastFailure SnmpPduErrorStatus, schedLastFailed DateAndTime, schedStorageType StorageType, schedRowStatus RowStatus } schedOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The owner of this scheduling entry. The exact semantics of this string are subject to the security policy defined by the security administrator." ::= { schedEntry 1 } schedName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally-unique, administratively assigned name for this scheduling entry. This object allows a schedOwner to have multiple entries in the schedTable." ::= { schedEntry 2 } schedDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The human readable description of the purpose of this scheduling entry." DEFVAL { ''H } ::= { schedEntry 3 } schedInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds between two action invocations of a periodic scheduler. Implementations must guarantee Expires January 1999 [Page 9] Internet-Draft Schedule MIB August 1998 that action invocations will not occur before at least schedInterval seconds have passed. The scheduler must ignore all periodic schedules that have a schedInterval value of 0. A periodic schedule with a scheduling interval of 0 seconds will therefore never invoke an action. Implementations may be forced to delay invocations in the face of local constraints. A scheduled management function should therefore not rely on the accuracy provided by the scheduler implementation." DEFVAL { 0 } ::= { schedEntry 4 } schedWeekDay OBJECT-TYPE SYNTAX BITS { sunday(0), monday(1), tuesday(2), wednesday(3), thursday(4), friday(5), saturday(6) } MAX-ACCESS read-create STATUS current DESCRIPTION "The set of weekdays on which the scheduled action should take place. Setting multiple bits will include several weekdays in the set of possible weekdays for this schedule. Setting all bits will cause the scheduler to ignore the weekday." DEFVAL { {} } ::= { schedEntry 5 } schedMonth OBJECT-TYPE SYNTAX BITS { january(0), february(1), march(2), april(3), may(4), june(5), july(6), august(7), september(8), Expires January 1999 [Page 10] Internet-Draft Schedule MIB August 1998 october(9), november(10), december(11) } MAX-ACCESS read-create STATUS current DESCRIPTION "The set of months during which the scheduled action should take place. Setting multiple bits will include several months in the set of possible months for this schedule. Setting all bits will cause the scheduler to ignore the month." DEFVAL { {} } ::= { schedEntry 6 } schedDay OBJECT-TYPE SYNTAX BITS { d1(0), d2(1), d3(2), d4(3), d5(4), d6(5), d7(6), d8(7), d9(8), d10(9), d11(10), d12(11), d13(12), d14(13), d15(14), d16(15), d17(16), d18(17), d19(18), d20(19), d21(20), d22(21), d23(22), d24(23), d25(24), d26(25), d27(26), d28(27), d29(28), d30(29), d31(30), r1(31), r2(32), r3(33), r4(34), r5(35), r6(36), r7(37), r8(38), r9(39), r10(40), r11(41), r12(42), r13(43), r14(44), r15(45), r16(46), r17(47), r18(48), r19(49), r20(50), r21(51), r22(52), r23(53), r24(54), r25(55), r26(56), r27(57), r28(58), r29(59), r30(60), r31(61) } MAX-ACCESS read-create STATUS current DESCRIPTION "The set of days in a month on which a scheduled action should take place. There are two sets of bits one can use to define the day within a month: Enumerations starting with the letter 'd' indicate a day in a month relative to the first day of a month. The first day of the month can therefore be specified by setting the bit d1(0) and d31(30) means the last day of a month with 31 days. Enumerations starting with the letter 'r' indicate a day in a month in reverse order, relative to the last Expires January 1999 [Page 11] Internet-Draft Schedule MIB August 1998 day of a month. The last day in the month can therefore be specified by setting the bit r1(31) and r31(61) means the first day of a month with 31 days. Setting multiple bits will include several days in the set of possible days for this schedule. Setting all bits will cause the scheduler to ignore the day within a month. Setting all bits starting with the letter 'd' or the letter 'r' will also cause the scheduler to ignore the day within a month." DEFVAL { {} } ::= { schedEntry 7 } schedHour OBJECT-TYPE SYNTAX BITS { h0(0), h1(1), h2(2), h3(3), h4(4), h5(5), h6(6), h7(7), h8(8), h9(9), h10(10), h11(11), h12(12), h13(13), h14(14), h15(15), h16(16), h17(17), h18(18), h19(19), h20(20), h21(21), h22(22), h23(23) } MAX-ACCESS read-create STATUS current DESCRIPTION "The set of hours within a day during which the scheduled action should take place." DEFVAL { {} } ::= { schedEntry 8 } schedMinute OBJECT-TYPE SYNTAX BITS { m0(0), m1(1), m2(2), m3(3), m4(4), m5(5), m6(6), m7(7), m8(8), m9(9), m10(10), m11(11), m12(12), m13(13), m14(14), m15(15), m16(16), m17(17), m18(18), m19(19), m20(20), m21(21), m22(22), m23(23), m24(24), m25(25), m26(26), m27(27), m28(28), m29(29), m30(30), m31(31), m32(32), m33(33), m34(34), m35(35), m36(36), m37(37), m38(38), m39(39), m40(40), m41(41), m42(42), m43(43), m44(44), m45(45), m46(46), m47(47), m48(48), m49(49), m50(50), m51(51), m52(52), m53(53), m54(54), m55(55), m56(56), m57(57), m58(58), m59(59) } MAX-ACCESS read-create STATUS current DESCRIPTION Expires January 1999 [Page 12] Internet-Draft Schedule MIB August 1998 "The set of minutes within an hour when the scheduled action should take place." DEFVAL { {} } ::= { schedEntry 9 } schedContextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The context which contains the local MIB variable pointed to by schedVariable." ::= { schedEntry 10 } schedVariable OBJECT-TYPE SYNTAX VariablePointer MAX-ACCESS read-create STATUS current DESCRIPTION "An object identifier pointing to a local MIB variable which resolves to an ASN.1 primitive type of INTEGER." ::= { schedEntry 11 } schedValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The value which is written to the MIB object pointed to by schedVariable when the scheduler invokes an action. The implementation shall enforce the use of access control rules when performing the set operation on schedVariable. This is accomplished by calling the isAccessAllowed abstract service interface as defined in RFC 2271." ::= { schedEntry 12 } schedType OBJECT-TYPE SYNTAX INTEGER { periodic(1), calendar(2), oneshot(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of this schedule. The value periodic(1) indicates that this entry specifies a periodic schedule. A periodic Expires January 1999 [Page 13] Internet-Draft Schedule MIB August 1998 schedule is defined by the value of schedInterval. The values of schedWeekDay, schedMonth, schedDay, schedHour and schedMinute are ignored. The value calendar(2) indicates that this entry describes a calendar schedule. A calendar schedule is defined by the values of schedWeekDay, schedMonth, schedDay, schedHour and schedMinute. The value of schedInterval is ignored. A calendar schedule will trigger on all local times that satisfy the bits set in schedWeekDay, schedMonth, schedDay, schedHour and schedMinute. The value oneshot(3) indicates that this entry describes a one-shot schedule. A one-shot schedule is similar to a calendar schedule with the additional feature that it disables itself by changing in the `finished' schedOperStatus once the schedule triggers an action. Changing a schedule's type is equivalent to deleting the old-type schedule and creating a new-type one." DEFVAL { periodic } ::= { schedEntry 13 } schedAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired state of the schedule." DEFVAL { disabled } ::= { schedEntry 14 } schedOperStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2), finished(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of this schedule. The state enabled(1) indicates this entry is active and that the scheduler will invoke actions at appropriate times. The Expires January 1999 [Page 14] Internet-Draft Schedule MIB August 1998 disabled(2) state indicates that this entry is currently inactive and ignored by the scheduler. The finished(3) state indicates that the schedule has ended. Schedules in the finished(3) state are ignored by the scheduler. A one-shot schedule enters the finished(3) state when it deactivates itself." ::= { schedEntry 15 } schedFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This variable counts the number of failures while invoking the scheduled action." ::= { schedEntry 16 } schedLastFailure OBJECT-TYPE SYNTAX SnmpPduErrorStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The most recent error that occured during the invocation of a scheduled action. The value noError(0) is returned if no errors have occurred yet." DEFVAL { noError } ::= { schedEntry 17 } schedLastFailed OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when the most recent failure occured. The value '0000000000000000'H is returned if no failure occured since the last re-initialization of the scheduler." DEFVAL { '0000000000000000'H } ::= { schedEntry 18 } schedStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether this scheduled action is kept in volatile storage and lost upon reboot or if this row is backed up by non-volatile or permanent storage. Expires January 1999 [Page 15] Internet-Draft Schedule MIB August 1998 Conceptual rows having the value `permanent' must allow write access to the columnar objects schedDescr, schedInterval, schedContextName, schedVariable, schedValue, and schedAdminStatus. If an implementation supports the schedCalendarGroup, write access must be also allowed to the columnar objects schedWeekDay, schedMonth, schedDay, schedHour, schedMinute." DEFVAL { volatile } ::= { schedEntry 19 } schedRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this scheduled action. A control that allows entries to be added and removed from this table. The miminum number of objects that need to be set during row creation before a row can be set to `active' are schedContextName, schedVariable and schedValue." ::= { schedEntry 20 } -- -- Notifications that are emitted to indicate failures. The definition -- of schedTraps makes notification registrations reversible. -- schedTraps OBJECT IDENTIFIER ::= { schedNotifications 0 } schedActionFailure NOTIFICATION-TYPE OBJECTS { schedLastFailure, schedLastFailed } STATUS current DESCRIPTION "This notification is generated whenever the invocation of a scheduled action fails." ::= { schedTraps 1 } -- conformance information schedCompliances OBJECT IDENTIFIER ::= { schedConformance 1 } schedGroups OBJECT IDENTIFIER ::= { schedConformance 2 } -- compliance statements schedCompliance MODULE-COMPLIANCE STATUS current Expires January 1999 [Page 16] Internet-Draft Schedule MIB August 1998 DESCRIPTION "The compliance statement for SNMP entities which implement the scheduling MIB." MODULE -- this module MANDATORY-GROUPS { schedGroup, schedNotificationsGroup } GROUP schedCalendarGroup DESCRIPTION "The schedCalendarGroup is mandatory only for those implementations that support calendar based schedules." OBJECT schedType DESCRIPTION "The values calendar(2) or oneshot(3) are not valid for implementations that do not implement the schedCalendarGroup. Such an implementation must return inconsistentValue error responses for attempts to set schedAdminStatus to calendar(2) or oneshot(3)." ::= { schedCompliances 1 } schedGroup OBJECT-GROUP OBJECTS { schedDescr, schedInterval, schedContextName, schedVariable, schedValue, schedType, schedAdminStatus, schedOperStatus, schedFailures, schedLastFailure, schedLastFailed, schedStorageType, schedRowStatus } STATUS current DESCRIPTION "A collection of objects providing scheduling capabilities." ::= { schedGroups 1 } schedCalendarGroup OBJECT-GROUP OBJECTS { schedLocalTime, schedWeekDay, schedMonth, schedDay, Expires January 1999 [Page 17] Internet-Draft Schedule MIB August 1998 schedHour, schedMinute } STATUS current DESCRIPTION "A collection of objects providing calendar based schedules." ::= { schedGroups 2 } schedNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { schedActionFailure } STATUS current DESCRIPTION "The notifications emitted by the scheduler." ::= { schedGroups 3 } END Expires January 1999 [Page 18] Internet-Draft Schedule MIB August 1998 5. Usage Examples This section presents some examples how the scheduling MIB can be used to schedule scripts with the Script MIB [17] or to realize on- duty/off-duty schedules by modifying status objects of other MIB modules. 5.1. Starting a script to ping devices every 20 minutes It is assumed that the schedule entry is owned by schedOwner = "joe" and its name is schedName = "ping". The instance identifier for the scheduling entry is therefore 3.106.111.101.4.112.105.110.103. It is further assumed that the smLaunchTable entry is owned by smLaunchOwner = "joe" and its name is smLaunchName = "ping-devs". The complete object identifier for the smLaunchStart object is therefore smLaunchStart.3.106.111.101.9.112.105.110.103.45.100.101.118.115. The script lives in the context identified by the string "engine1". The configuration of the scheduler entry which presses the launch button every 20 minutes would look as follows: schedInterval.3.106.111.101.4.112.105.110.103 = 1200 schedValue.3.106.111.101.4.112.105.110.103 = 0 schedContextName.3.106.111.101.4.112.105.110.103 = "engine1" schedVariable.3.106.111.101.4.112.105.110.103 = smLaunchStart.3.106.111.101.9.112.105.110.103.45.100.101.118.115 schedType.3.106.111.101.4.112.105.110.103 = periodic(1) schedAdminStatus.3.106.111.101.4.112.105.110.103 = enabled(1) schedStorageType.3.106.111.101.4.112.105.110.103 = nonVolatile(3) schedRowStatus.3.106.111.101.4.112.105.110.103 = active(1) All the remaining columns in the schedTable represent status information and are not shown here. 5.2. Starting a script at the next Friday the 13th It is assumed that the schedule entry is owned by schedOwner = "joe" and its name is schedName = "13th". The instance identifier for the scheduling entry is therefore 3.106.111.101.4.49.51.116.104. It is further assumed that the smLaunchTable entry is owned by smLaunchOwner = "joe" and its name is smLaunchName = "ghost". The Expires January 1999 [Page 19] Internet-Draft Schedule MIB August 1998 complete object identifier for the smLaunchStart object is therefore smLaunchStart.3.106.111.101.5.103.104.111.115.116. The script lives in the context identified by the string "engine1". The configuration of the scheduler entry which presses the launch button on every Friday 13th at midnight would look as follows: schedWeekDay.3.106.111.101.4.49.51.116.104 = { friday } schedMonth.3.106.111.101.4.49.51.116.104 = { january, february, march, april, may, june, july, august, september, october, november, december } schedDay.3.106.111.101.4.49.51.116.104 = { d13 } schedHour.3.106.111.101.4.49.51.116.104 = { h0 } schedMinute.3.106.111.101.4.49.51.116.104 = { m0 } schedValue.3.106.111.101.4.49.51.116.104 = 0 schedContextName.3.106.111.101.4.49.51.116.104 = "engine1" schedVariable.3.106.111.101.4.49.51.116.104 = smLaunchStart.3.106.111.101.5.103.104.111.115.116 schedType.3.106.111.101.4.49.51.116.104 = oneshot(3) schedAdminStatus.3.106.111.101.4.49.51.116.104 = enabled(2) schedStorageType.3.106.111.101.4.49.51.116.104 = nonVolatile(3) schedRowStatus.3.106.111.101.4.49.51.116.104 = active(1) All the remaining columns in the schedTable represent status information and are not shown here. 5.3. Turning an interface off during weekends This example assumes that a network interface should be taken down during weekends. The interface table (ifTable) of the IF-MIB [18] is assumed to exist in the context identified by an empty string and the index of the interface is ifIndex = 6. The scheduling entry which brings the interface down on every Friday evening at 20:30 (8:30 pm) is owned by schedOwner = "bob" and its name is schedName = "if-off". The instance identifier for the scheduling entry is therefore 3.98.111.98.6.105.102.45.111.102.102. schedWeekDay.3.98.111.98.6.105.102.45.111.102.102 = { friday } schedMonth.3.98.111.98.6.105.102.45.111.102.102 = { january, february, march, april, may, june, july, august, september, october, november, december } Expires January 1999 [Page 20] Internet-Draft Schedule MIB August 1998 schedDay.3.98.111.98.6.105.102.45.111.102.102 = { d1, d2, d3, d4, d5, d6, d7, d8, d9, d10, d11, d12, d13, d14, d15, d16, d17, d18, d19, d20, d21, d22, d23, d24, d25, d26, d27, d28, d29, d30, d31 } schedHour.3.98.111.98.6.105.102.45.111.102.102 = { h20 } schedMinute.3.98.111.98.6.105.102.45.111.102.102 = { m30 } schedValue.3.98.111.98.6.105.102.45.111.102.102 = down(2) schedContextName.3.98.111.98.6.105.102.45.111.102.102 = "" schedVariable.3.98.111.98.6.105.102.45.111.102.102 = ifAdminStatus.6 schedType.3.98.111.98.6.105.102.45.111.102.102 = calendar(2) schedAdminStatus.3.98.111.98.6.105.102.45.111.102.102 = enabled(1) schedStorageType.3.98.111.98.6.105.102.45.111.102.102 = nonVolatile(3) schedRowStatus.3.98.111.98.6.105.102.45.111.102.102 = active(1) The scheduling entry which brings the interface up on every Monday morning at 5:30 is owned by schedOwner = "bob" and its name is schedName = "if-on". The instance identifier for the scheduling entry is therefore 3.98.111.98.5.105.102.45.111.110. The entry in the schedTable which brings the interface up again on every Monday morning at 5:30 looks as follows: schedWeekDay.3.98.111.98.5.105.102.45.111.110 = { monday } schedMonth.3.98.111.98.5.105.102.45.111.110 = { january, february, march, april, may, june, july, august, september, october, november, december } schedDay.3.98.111.98.5.105.102.45.111.110 = { d1, d2, d3, d4, d5, d6, d7, d8, d9, d10, d11, d12, d13, d14, d15, d16, d17, d18, d19, d20, d21, d22, d23, d24, d25, d26, d27, d28, d29, d30, d31 } schedHour.3.98.111.98.5.105.102.45.111.110 = { h5 } schedMinute.3.98.111.98.5.105.102.45.111.110 = { m30 } schedValue.3.98.111.98.5.105.102.45.111.110 = up(1) schedContextName.3.98.111.98.5.105.102.45.111.110 = "" schedVariable.3.98.111.98.5.105.102.45.111.110 = ifAdminStatus.6 schedType.3.98.111.98.5.105.102.45.111.110 = calendar(2) schedAdminStatus.3.98.111.98.5.105.102.45.111.110 = enabled(1) schedStorageType.3.98.111.98.5.105.102.45.111.110 = nonVolatile(3) Expires January 1999 [Page 21] Internet-Draft Schedule MIB August 1998 schedRowStatus.3.98.111.98.5.105.102.45.111.110 = active(1) A similar configuration could be used to control other schedules. For example, one could change the "if-on" and "if-off" schedules to enable and disable the periodic scheduler defined in the first example. 6. Security Considerations Scheduled SNMP set operations must use the security credentials that were present when the corresponding row in the scheduling entry was created. An implementation must therefore record and maintain the credentials for every scheduling entry. An implementation must ensure that access control rules are applied when doing the set operation. This is accomplished by calling the isAccessAllowed abstract service interface defined in RFC 2271 [1]: statusInformation = -- success or errorIndication isAccessAllowed( IN securityModel -- Security Model in use IN securityName -- principal who wants to access IN securityLevel -- Level of Security IN viewType -- read, write, or notify view IN contextName -- context containing variableName IN variableName -- OID for the managed object ) The securityModel, securityName and securityLevel parameters are set to the values that were recorded when the scheduling entry was created. The viewType parameter must select the write view and the contextName and variableName parameters are taken from the schedContextName and schedVariableName values of the scheduling entry. This MIB limits scheduled actions to objects in the local MIB. This avoids security problems with the delegation of access rights. However, it might be possible for a user of this MIB to own some schedules that might trigger far in the future. This can cause security risks if the security administrator did not properly update the access control lists when a user is withdrawn from an SNMP engine. Therefore, entries in the schedTable SHOULD be cleaned up whenever a user is removed from an SNMP engine. To facilitate the provisioning of access control by a security administrator using the View-Based Access Control Model (VACM) Expires January 1999 [Page 22] Internet-Draft Schedule MIB August 1998 defined in RFC 2275 [15] 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. 7. 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. 8. Acknowledgments This document was produced by the IETF Distributed Management (DISMAN) working group. Expires January 1999 [Page 23] Internet-Draft Schedule MIB August 1998 9. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998 [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991 [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol Expires January 1999 [Page 24] Internet-Draft Schedule MIB August 1998 (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, January 1998 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., Cisco Systems, Inc., January 1998 [16] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [17] Levi, D., and J. Schoenwaelder, "Definitions of Managed Objects for the Delegation of Management Scripts", Internet-Draft , SNMP Research, Inc., TU Braunschweig, May 1998. [18] McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, Cisco Systems, FTP Software, November 1997. Expires January 1999 [Page 25] Internet-Draft Schedule MIB August 1998 10. Editors' Addresses David B. Levi Email: levi@snmp.com SNMP Research, Inc. Tel: +1 423 573 1434 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 U.S.A. Juergen Schoenwaelder Email: schoenw@ibr.cs.tu-bs.de TU Braunschweig Tel: +49 531 391-3283 Bueltenweg 74/75 38106 Braunschweig Germany 11. Full Copyright Statement Copyright (C) The Internet Society (1998). 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 January 1999 [Page 26] Internet-Draft Schedule MIB August 1998 12. Revision History This section should be removed once this document gets published as an RFC. 12.1. Changes from o Clarifications about drifts between initiations of action in a periodic scheduler. o Made the registration of the notification reversible. o Changed the syntax of schedInterval from TimeInterval to Unsigned32. The maximum resolution is now seconds instead of hundreds of a second. o The conformance statement makes objects for the calendar-based scheduler optional. o Minor changes to make the MIB compile with smicng. 12.2. Changes from o Updated the section about the SNMP management framework and added references to SNMPv3. o Replaced Utf8String with SnmpAdminString. o Added Intellectual Property section. o Changed some wordings to make the text more readable. 12.3. Changes from o Fixes some typos. o Changed the semantics of "no bits set" and added DEFVALs which default to nothing scheduled. Expires January 1999 [Page 27] Internet-Draft Schedule MIB August 1998 o Added reference to BCP-11. o Added the schedContextName object to indicate the context of the variable being set by the scheduler. o Added three examples to demonstrate the usage of the scheduling MIB. o Created a new TC SnmpPduErrorStatus which contains SNMP PDU error status codes plus `noResponse'. o Added the new boilerplate and the references that go along with it. o Removed the transitional states `enabling' and `disabling' from the schedOperStatus object. o Defined the set of objects that must be writable if the storage type of a row is permanent. o List the objects that have to get values assigned during row creation in order to set a row to `active'. o Added text which describes how the isAccessAllowed abstract service interface is called for access control. o Added Randy's text which explains the indexing structure without refering to a DISMAN framework. o Replaced schedIndex with schedName. This allows semantic meaningful references to scheduling entries. 12.4. Changes from o Changed the MIB module name to DISMAN-SCHEDULE-MIB. o Fixed the example to make the indexing consistent with the new version of the Script MIB. o Removed the IMPLIED keyword and updated the examples. o Moved the change logs to the end of the document. Expires January 1999 [Page 28] Internet-Draft Schedule MIB August 1998 12.5. Changes from o Added the key words boilerplate from RFC 2119. o Replaced "DISMAN application" with distributed management application. o Replaced schedMIBTraps with schedTraps. o Reworded the last sentence in the second paragraph of the security considerations to use SHOULD as defined in RFC 2119. o Exchanged monday and friday in the example. o Added a new section about time transitions. o Added the schedLocalTime object which provides access to the local time and the local timezone (offset from GMT). Add text to define that calendar schedules are always in local time. o Added the DEFVAL { 0 } to schedInterval and added text which describes that periodic schedules with a schedInterval of 0 seconds must be ignored. o Added schedLastFailed to the schedActionFailure notification. o Replaced the phrase "launch button" with more precise terminology. o Changed schedAdminStatus and schedOperStatus to have only the states enabled/disabled. Added a new schedType object which defines whether we have a periodic, calendar or one-shot schedule. Added a new schedOperStatus state finished which is used when a one-shot schedule ends. Changed the first example to schedule an event on the next friday 13th using a one-shot schedule and updated all examples. o Defined the term scheduler in the overview section. o Added text to the section describing calendar schedules in order to better describe how it works. o Added bits to schedDay which allow to specify days relative to the end of the month. Expires January 1999 [Page 29] Internet-Draft Schedule MIB August 1998 Table of Contents 1 Abstract ..................................................... 2 2 The SNMP Management Framework ................................ 2 3 Overview ..................................................... 3 3.1 Periodic Schedules ......................................... 3 3.2 Calendar Schedules ......................................... 4 3.3 One-shot Schedules ......................................... 4 3.4 Time Transitions ........................................... 5 3.5 Actions .................................................... 5 4 Definitions .................................................. 6 5 Usage Examples ............................................... 19 5.1 Starting a script to ping devices every 20 minutes ......... 19 5.2 Starting a script at the next Friday the 13th .............. 19 5.3 Turning an interface off during weekends ................... 20 6 Security Considerations ...................................... 22 7 Intellectual Property ........................................ 23 8 Acknowledgments .............................................. 23 9 References ................................................... 24 10 Editors' Addresses .......................................... 26 11 Full Copyright Statement .................................... 26 12 Revision History ............................................ 27 12.1 Changes from .......... 27 12.2 Changes from .......... 27 12.3 Changes from .......... 27 12.4 Changes from .......... 28 12.5 Changes from .......... 29 Expires January 1999 [Page 30] From maria@xedia.com Fri Aug 7 16:16:44 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA01543 for ; Fri, 7 Aug 1998 16:16:42 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA10350 for ; Fri, 7 Aug 1998 16:15:15 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma010326; Fri, 7 Aug 98 16:14:43 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA10221 for ; Fri, 7 Aug 1998 16:14:08 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma009551; Fri, 7 Aug 98 16:13:35 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA14184; Fri, 7 Aug 1998 16:14:07 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA04194 for ; Fri, 7 Aug 1998 14:14:04 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id QAA13758 for ; Fri, 7 Aug 1998 16:14:02 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by cashew.bmc.com via smap (V2.0) id xma013716; Fri, 7 Aug 98 16:13:29 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id RAA19497; Fri, 7 Aug 1998 17:10:43 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id RAA23463 for ; Fri, 7 Aug 1998 17:10:08 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id RAA20756 for ; Fri, 7 Aug 1998 17:09:01 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA10013 for ; Fri, 7 Aug 1998 16:09:00 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma009995; Fri, 7 Aug 98 16:08:33 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA04750 for ; Fri, 7 Aug 1998 16:07:57 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma004525; Fri, 7 Aug 98 16:07:38 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA12095 for ; Fri, 7 Aug 1998 16:08:11 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA03968 for disman@nexen.com; Fri, 7 Aug 1998 14:08:10 -0700 (PDT) Date: Fri, 7 Aug 1998 14:08:10 -0700 (PDT) From: Randy Presuhn Message-Id: <199808072108.OAA03968@dorothy.bmc.com> To: disman@nexen.com Subject: Presentations at disman meeting Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - If you wish to give a presentation at the upcoming meeting of the disman working group, please read the attached message from Steve Coya and let me know the topic and time needed. That information will help me allocate time for the session. Currently, NO ONE has been allocated a specific amount of time, nor do I think anyone has made a DEFINITE commitment to give a presentation. I'd really like to hear what Juergen has to say on their scripting language for their script MIB implementation, and I believe Ken White should present the case for the REMOPS work and his specific proposal. Juergen, Ken, others: let me know if you can give presentations. If someone could really dig into the AgentX issues (security name of operation invokers, isAccessAllowed service), I'm sure Bob Natale would appreciate "right of first refusal" on such a presentation; if such disman-relevant issues overflow their AgentX time slot, we can take up the slack, within reason. In fairness to all presenters, I'd prefer to have this information by the end of next week. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- > Date: Fri, 7 Aug 1998 16:30:16 -0400 > Subject: Chicago IETF Presentations > From: scoya@ietf.org > To: wgchairs@ietf.org, bofchairs@ietf.org > > > Greetings, > > Are all your agendas ready? ;-) > > > In order to repeat the rapid preparations of the WEB and CD versions of > the IETF proceedings, I am writing to ask for two things: > > 1. Slide/Overhead file formats > > Please be sure all your presenters know that we prefer receiving > Powerpoint or PDF files. If a presentor can only provide Postscript, > that's fine.... but we may convert it to PDF. > > PLEASE PLEASE give us ONE (1) image per sheet. In the old days we > appreciated folks providing 6 images per page, but that was when we only > produced hardcopy proceedings. It is much easier for us to deal with one > per page, and getting six per page made reading them on the WEB/CD almost > impossible. > > > 2. Lists of Presentations > > I am asking each WG and BOF chair to send a message detailing the > presentations whose slides are to be included in the proceedings. We know > which groups met, so we know what minutes to look for (and whom to poke > when the don't make it in on time :-) But we have no idea if 1, 2 or 30 > presentations were given. Knowing what sets of slides to expect will help > us track what's in (and yes, it'll give us something else to poke you > about), but it will insure that we have everything that was expected. > > > > NO - do not send the list now. > > > You don't know who will or will not show > up, if there are any last minute presentations, or even if you want them > included in the proceeding. Yes, there are some like that... especially > those who promised tech topics but ended up showing marketing slides. > > > Note that Dixie is no longer our Proceedings Editor. But the address for > minutes and slide presentations remains minutes@ietf.org > > > Feel free to contact me if there are any questions, suggestions, or > comments (just don't do it just before the IETF meeting :-) > > Thanks in advance. > > > Steve > > > From maria@xedia.com Fri Aug 7 16:33:04 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA01669 for ; Fri, 7 Aug 1998 16:33:04 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA12467 for ; Fri, 7 Aug 1998 16:31:38 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012459; Fri, 7 Aug 98 16:31:12 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA25219 for ; Fri, 7 Aug 1998 16:30:34 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma024757; Fri, 7 Aug 98 16:30:08 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA19017; Fri, 7 Aug 1998 16:30:41 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA07080 for ; Fri, 7 Aug 1998 14:30:39 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA12428 for ; Fri, 7 Aug 1998 16:30:37 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by almond.bmc.com via smap (V2.0) id xma012409; Fri, 7 Aug 98 16:30:18 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id RAA19711; Fri, 7 Aug 1998 17:27:50 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id RAA24709 for ; Fri, 7 Aug 1998 17:27:34 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id RAA19701 for ; Fri, 7 Aug 1998 17:27:33 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA12279 for ; Fri, 7 Aug 1998 16:27:32 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma011839; Fri, 7 Aug 98 16:25:40 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA20603 for ; Fri, 7 Aug 1998 16:25:04 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020175; Fri, 7 Aug 98 16:24:34 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA17311 for ; Fri, 7 Aug 1998 16:25:07 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA04889 for disman@nexen.com; Fri, 7 Aug 1998 14:25:06 -0700 (PDT) Date: Fri, 7 Aug 1998 14:25:06 -0700 (PDT) From: Randy Presuhn Message-Id: <199808072125.OAA04889@dorothy.bmc.com> To: disman@nexen.com Subject: Re: New REMOPS-MIB draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Fri, 7 Aug 1998 10:03:49 +0200 > From: Juergen Schoenwaelder > To: rpresuhn@dorothy.bmc.com > CC: disman@nexen.com > Subject: Re: New REMOPS-MIB draft > References: <199808062139.OAA13921@dorothy.bmc.com> ... > Randy> whether we as a working group want to work on it. Here's a > Randy> first cut at a proposal for an addition to the WG charter: > > Randy> | - Special-purpose MIBs for performing specific useful remote > Randy> | operations, such as ping and traceroute. ... > Having said this, I see great value in defining a set of "standard > functions" like doing a traceroute or a simple ping in order to make > it easy to use these functions in a vendor neutral way. So, yes, we > should extend our charter, but we should be very careful about the > wordings we use. I am not even sure that we need special-purpose > *MIBs* in the traditional sense. What about the following text: > > : - A set of special-purpose management functions for performing > : specific useful remote operations, such as ping and traceroute. > > This leaves it open how the WG actually defines them. ... I agree with Juergen's rationale and with the new wording proposed. Folks, are there any objections to requesting that the following work item be added to the charter of the disman working group? | - A set of special-purpose management functions for performing | specific useful remote operations, such as ping and traceroute. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From maria@xedia.com Sat Aug 8 06:20:41 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id GAA01200 for ; Sat, 8 Aug 1998 06:20:41 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id GAA01228 for ; Sat, 8 Aug 1998 06:19:14 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma001224; Sat, 8 Aug 98 06:18:55 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id GAA17255 for ; Sat, 8 Aug 1998 06:18:19 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma017245; Sat, 8 Aug 98 06:18:09 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id GAA21684; Sat, 8 Aug 1998 06:18:20 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA08756 for ; Sat, 8 Aug 1998 04:18:05 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id GAA12321 for ; Sat, 8 Aug 1998 06:18:03 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by cashew.bmc.com via smap (V2.0) id xma012318; Sat, 8 Aug 98 06:17:47 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id HAA22348; Sat, 8 Aug 1998 07:13:45 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id HAA16961; Sat, 8 Aug 1998 07:11:15 -0400 (EDT) From: DirecteMart.com@golfer.net Received: from 206.13.28.11 (ppp-207-214-148-124.snrf01.pacbell.net [207.214.148.124]) by guelah.nexen.com (8.8.5/8.7.3) with SMTP id HAA28825; Sat, 8 Aug 1998 07:11:11 -0400 (EDT) Date: Sat, 8 Aug 1998 07:11:11 -0400 (EDT) Message-Id: <199808081111.HAA28825@guelah.nexen.com> To: DirecteMart.com@golfer.net Subject: e-Merchant Credit Card Processing Start accepting orders from your site worldwide in 2-3 days. - Affordable, complete, automated, turn-key, e-merchant "shopping cart" system links to your existing pages anywhere in the world - No bank qualifying required - Designed for Internet merchants who have been turned down or cannot get a merchant account for any reason. - Sophisticated routine security measures to minimize fraud for more information: http://DirecteMart.com/visa-mc.html BREAKING INTERNET COMMERCE NEWS 5 August 1998: Visa and Mastercard will become the dominant means by which consumers make purchases over the Internet during the next five years, according to a new study of electronic payment systems.This means that the e-commerce merchants could handle a $10 billion-plus Internet commercial market by 2001, said a report by SRI Consulting, a research firm in Menlo Park, Calif. The use of so-called smart cards and electronic currencies will "fair poorly," the researchers predict. INCREASE YOUR SALES WORLDWIDE http://DirecteMart.com/visa-mc.html 1-800-700-4439 (US only) No need to obtain your own merchant account No bank qualifying Low start-up cost Same affordable rates regardless of sales volume Accept credit card orders worldwide No advance security deposit No equipment or software to buy or lease No long-term obligation No physical presence in the US required Set-up is quick and easy Competitive, cost-effective rates and pricing Sophisticated, complete e-commerce system included Easily links to your existing pages No need to move your site No limit to the number of products Transactions in U.S. dollars Payment for proceeds by check or direct deposit State-of-the-art-privacy and security with industry encryption standards Up-to-the-minute, routine security measures to minimize fraud Complete Sales Agreement available for your review No hidden costs ~ no surprises 100% satisfaction, money-back guarantee Established US Internet firm with many years' experience in traditional and mail-order credit card processing. for more info: http://DirecteMart.com/visa-mc.html DirecteMart.com c/o Internet Credit Card Merchant Services 2777 Yulupa Avenue, Suite 133 Santa Rosa, CA 95405 USA 1-800-700-44439 From maria@xedia.com Mon Aug 10 13:28:40 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA26875 for ; Mon, 10 Aug 1998 13:28:40 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA05121; Mon, 10 Aug 1998 13:27:07 -0500 (CDT) Received: from dorothy.peer.com(192.146.153.65) by almond.bmc.com via smap (V2.0) id xma004874; Mon, 10 Aug 98 13:25:47 -0500 Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA19473 for ; Mon, 10 Aug 1998 11:25:33 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA04801 for ; Mon, 10 Aug 1998 13:25:32 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by almond.bmc.com via smap (V2.0) id xma004678; Mon, 10 Aug 98 13:24:50 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id OAA04902; Mon, 10 Aug 1998 14:21:19 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id OAA20104 for ; Mon, 10 Aug 1998 14:18:15 -0400 (EDT) From: BzyBees@lycos.com Received: from dai-nichi.co.jp (dai-nichi.co.jp [210.143.96.183]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id OAA06395 for ; Mon, 10 Aug 1998 14:18:13 -0400 (EDT) Received: from 210.143.96.183 (sdn-ts-012nccharP02.dialsprint.net [168.191.71.197]) by dai-nichi.co.jp (8.8.8/3.6Wbeta7) with SMTP id DAA27511; Tue, 11 Aug 1998 03:11:25 +0900 Message-Id: <199808101811.DAA27511@dai-nichi.co.jp> Date: Mon, 10 Aug 98 14:06:33 EST To: 1you124@ANYwhere.com.bmc.com Subject: WORLDS' GREATEST ........ World's Greatest Business Opportunity! ......... You be the judge. No Competition No Selling Not MLM $1 - $5,000 per week from home, within the next 30 days! Complete Training & Support Live Conference Calls Daily! Leads! Leads! Leads! and Much More! If your a serious minded individual that is tired of hype and NEEDS to make several thousand dollars with in the next 30 - 60 days, then we need to talk. I am making several thousand dollars per week and YOU CAN TOO! Either myself or one of my associates will contact you about our turnkey, proprietary system that is so easy and simple to duplicate. IT WORKS LIKE A CHARM! P.S. You owe it to yourself and your family to take a serious look CLICK LINK BELOW AND ENTER YOUR INFO TO MAKE CONTACT ================================== Click Here ======>>>more info <<<======= Click Here Put the word "SUCCEED" in the subject field plus the information below and click send. ------------------------------------------------------ Please include the following: Without this information you will not be contacted ------------------------------------------------------ Name <<<<====Important (remember to include) Home or Work Phone number <<<<====Important (remember to include) The best time to contact you <<<<====Important (remember to include) ============================================================= To remove from mailing list click link below: Click Here ====>>> more info <<<==== Click Here Put the words "Remove now" in the Subject Field and Click Send. From maria@xedia.com Tue Aug 11 12:15:58 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA07869 for ; Tue, 11 Aug 1998 12:15:57 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA25229 for ; Tue, 11 Aug 1998 12:14:23 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma025215; Tue, 11 Aug 98 12:14:12 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA12405 for ; Tue, 11 Aug 1998 12:13:35 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma012200; Tue, 11 Aug 98 12:13:08 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA27390; Tue, 11 Aug 1998 12:13:42 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA07988 for ; Tue, 11 Aug 1998 10:13:24 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA25182 for ; Tue, 11 Aug 1998 12:13:21 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by almond.bmc.com via smap (V2.0) id xma025168; Tue, 11 Aug 98 12:13:08 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id NAA24581; Tue, 11 Aug 1998 13:09:48 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id NAA03566 for ; Tue, 11 Aug 1998 13:07:42 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id NAA04153 for ; Tue, 11 Aug 1998 13:07:37 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA24625 for ; Tue, 11 Aug 1998 12:07:26 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024614; Tue, 11 Aug 98 12:07:05 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA07943 for ; Tue, 11 Aug 1998 12:06:29 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma007797; Tue, 11 Aug 98 12:06:11 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA25128 for ; Tue, 11 Aug 1998 12:06:43 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA07693 for disman@nexen.com; Tue, 11 Aug 1998 10:06:25 -0700 (PDT) Date: Tue, 11 Aug 1998 10:06:25 -0700 (PDT) From: Randy Presuhn Message-Id: <199808111706.KAA07693@dorothy.bmc.com> To: disman@nexen.com Subject: Fwd: Comments on Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - Here are Bob Moore's review comments on the script MIB. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- > Date: Mon, 10 Aug 1998 16:34:20 -0400 > Subject: Comments on > From: remoore@us.ibm.com > To: rpresuhn@bmc.com, levi@snmp.com, schoenw@ibr.cs.tu-bs.de > Cc: Harald.Alvestrand@maxware.no, wijnen@vnet.ibm.com > > Hi, > > Here are my comments on the -05 version of the Script MIB. > Most of the comments are editorial; I've flagged the few > technical comments with the word "TECHNICAL". The two MIB > modules compile without errors with SMICng. > > 1. Section 1 + References: you need to add the SHALL / SHOULD > paragraph and the reference to RFC 2119. > > 2. page 4, fourth bullet: this paragraph doesn't really help > me understand the boundaries of the concept "management > scripting language." Maybe some examples of the > characteristics referred to in the second sentence would > help. > > 3. Section 3: you need to add an entry here for the term > "launch button." As it is, this term first occurs in an > object DESCRIPTION on p. 26. > > 4. Section 4.1, list item 3: repeat the text from the object > DESCRIPTION saying that this value is one of the arcs below > { 1 3 6 1 4 1 }. Also, the current text in smLangVendor > says "should"; is there any reason not to make this a > "SHALL"? > > 5. Section 4.3, first paragraph: the last sentence of the > paragraph would read better as "A script invoker must > understand the format and semantics of both the arguments > and the results of the scripts that it invokes." > > 6. Section 5.4: you need to incorporate the term "launch > button" into the model text here. > > 7. DESCRIPTION for smLangVersion object (p.14): state the > significance of the zero-length string. (Is it reserved > for "don't know," or can it also be used for "doesn't have > a version number"?) > > 8. TECHNICAL: smScriptSource object (p. 19): the restriction > on setting this object (only if the value of > smScriptOperStatus is 'disabled') seems overly cumbersome. > Suppose, for example, the user of a management application > makes a typo when entering the URL for the script source. > After the entry is created and enabled, and after > smScriptAdminStatus has been set to 'enabled', the agent > attempts to retrieve the script from the specified URL, > and gets an error that causes the value of smScriptOperStatus > to be something like 'noSuchScript', 'accessDenied', or > 'protocolFailure'. It would be nice if the management > application could send a set operation at this point to > correct the typo in the value of smScriptSource, but this > isn't allowed because smScriptOperStatus has the wrong value. > > Unless you can identify other problems that it would cause, > it seems reasonable for you to expand the list of values > of smScriptOperStatus under which a set operation to > smScriptSource is allowed. > > 9. DESCRIPTION for smScriptSource (p. 19): in the fourth > paragraph, is the phrase "...a named file on the system > running the Script MIB..." really correct? Can't a file > URL point equally well to a file on a different system for > which I have a mapped network drive? > > Also, two typos: > > - paragraph 4, "usues"-->"uses" > - second list item, > "... a download of the script source the ..."--> > "... a download of the script source from the ..." > > 10. DESCRIPTION for smScriptSource (p. 20): the last > paragraph would be clearer if it read: "All launch > table entries that refer to this script entry shall have > an smLaunchOperStatus value of 'disabled' when the value > of this object is not 'enabled'." > > 11. DESCRIPTION for smScriptStorageType (p. 22): should the > last sentence end "...which shall be read-only", rather > than merely "... should ..."? > > 12. TECHNICAL: smCodeText object (p. 24): it's never > specified clearly exactly what this object contains. If > it's source code, how is the data encoded - ASCII? UTF8? > And how are line ends represented? Is each line of the > code supposed to be a separate "fragment"? (I don't > think so, since section 4.2 characterizes fragments as > useful for transferring a script without running into > SNMP message size limitations.) > > More generally, must it be source code at all? Why not > Java byte codes? > > I understand that you can't pin down all the details of > what goes into this object, since that's a function of > the language. But you need to say more than you do now. > > 13. smLaunchOwner DESCRIPTION (p.25): you need to say what > the zero-length string means here. > > 14. TECHNICAL: smLaunchArgument, smRunArgument, smRunResult > objects (pp. 26, 33, & 35): I realize it's a debatable > point, but management application developers like to see > *some* size bound on objects like these, even if there is > no inherent bound in the semantics of the object. SNMP > maximum message sizes also call for an upper bound on > the size of individual objects. Consider adding > a bound such as SIZE (0..255) to these objects. > > 15. smLaunchLifeTime, smLaunchExpireTime, smRunLifeTime, > smRunExpireTime: add a UNITS clause to these objects. > > 16. DESCRIPTION for smLaunchStart (p. 28): typo in check 2: > > "The values contents of ..."-->"The values of ..." > > 17. DESCRIPTION for smLaunchControl (p. 30): not sure of > the significance of the last sentence "Setting this > object to nop(4) will always succeed and has no effect." > This implies (but does not quite say) that setting the > object to some other value may fail. If this is the > case, you need to say which values can fail, and why. > > 18. DESCRIPTION for smLaunchStorageType (p. 31): should the > last sentence end "...which shall be read-only", rather > than merely "... should ..."? > > 19. DESCRIPTION for smRunLifeTime (p. 33): the last > paragraph states that the value of this object "does not > change" while a script is suspended. Can the value *be* > changed (via a set operation) while a script is > suspended? > > 20. DESCRIPTION for smRunResult (p. 35): when this object > contains "a descriptive error message" (upon abnormal > termination of a script), how is the text of the > message encoded? > > 21. Comment text (p. 37): The statement "The definition of > smTraps makes notification registrations reversible" is > cryptic. You should either clarify it or remove it. > > 22. TECHNICAL: smScriptAbort notification (p. 37): you > should add two objects to this notification: > > - smRunEndTime > - smRunResult (for the "descriptive error message"). > > 23. Section 7.1, list item 2 (p. 41): "... the language > that should be used to execute the scipt." (The typo > "scipt" appears a couple of times in the Usage Examples.) > It sounds wrong to characterize the language as being > used to *execute* a script. How about "... the language > in which the script was written"? > > 24. Section 7.2, first line (p. 42): It would be more > accurate to say "... performed by a manager to cause a > distributed manager to pull a script ...." > > 25. Section 7.3, first line (p. 42): typo: > > "... by send SNMP set-requests."--> > "... by sending SNMP set-requests." > > 26. Section 7.7, last sentence (p. 45): two typos: > > "strategie"-->"strategy" > "looses"-->"loses" > > 27. Section 9 (p. 48): two typos: > > "... (IANA) is responsible to maintain ..."--> > "... (IANA) is responsible for maintaining..." > > "... the distribution MIB modules ..."--> > "... the distribution of MIB modules ..." > > 28. TECHNICAL: ianaLangJavaVM object identity (p. 55): > I don't understand the reference to the Java virtual > machine. I could understand an entry for Java > source code, and another for Java byte codes. But > I don't know what the object identity that's there > now is trying to say. You should either put in > separate entries for Java source and Java byte codes, > or at the very least have one entry that clearly says > one or the other. > > 29. All the REFERENCE clauses in the ianaLanguages > module: Personally I have no problem with these, but > I'll point out that they all violate the rules for > REFERENCE clauses currently in the SMIv2. > > > > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > From maria@xedia.com Wed Aug 12 13:43:40 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA20100 for ; Wed, 12 Aug 1998 13:43:39 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA18108 for ; Wed, 12 Aug 1998 13:42:04 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma018088; Wed, 12 Aug 98 13:41:38 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA12259 for ; Wed, 12 Aug 1998 13:40:57 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma011969; Wed, 12 Aug 98 13:40:29 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA21418; Wed, 12 Aug 1998 13:41:03 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA05348 for ; Wed, 12 Aug 1998 11:40:45 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA18053 for ; Wed, 12 Aug 1998 13:40:34 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by almond.bmc.com via smap (V2.0) id xma018020; Wed, 12 Aug 98 13:40:04 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id OAA00602; Wed, 12 Aug 1998 14:37:18 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id OAA15877 for ; Wed, 12 Aug 1998 14:33:29 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id OAA00465 for ; Wed, 12 Aug 1998 14:33:28 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA00808; Wed, 12 Aug 1998 14:33:24 -0400 (EDT) Message-Id: <199808121833.OAA00808@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@nexen.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-schedule-mib-05.txt Date: Wed, 12 Aug 1998 14:33:24 -0400 Sender: cclark@ns.cnri.reston.va.us --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-05.txt Pages : 30 Date : 11-Aug-98 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 a set of managed objects that are used to schedule management operations periodically or at specified dates and times. 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. This memo does not specify a standard for the Internet community. Internet-Drafts are 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-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-schedule-mib-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-schedule-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980811142511.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-schedule-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-schedule-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980811142511.I-D@ietf.org> --OtherAccess-- --NextPart-- From maria@xedia.com Fri Aug 14 10:07:42 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id KAA09730 for ; Fri, 14 Aug 1998 10:07:42 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA04080 for ; Fri, 14 Aug 1998 10:06:02 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma004033; Fri, 14 Aug 98 10:05:41 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA23630 for ; Fri, 14 Aug 1998 10:05:03 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma023215; Fri, 14 Aug 98 10:04:32 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA13932; Fri, 14 Aug 1998 10:05:06 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA15293 for ; Fri, 14 Aug 1998 08:04:36 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id KAA22499 for ; Fri, 14 Aug 1998 10:04:31 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by cashew.bmc.com via smap (V2.0) id xma022489; Fri, 14 Aug 98 10:04:18 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id LAA16290; Fri, 14 Aug 1998 11:01:41 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id KAA22492; Fri, 14 Aug 1998 10:57:52 -0400 (EDT) From: dsteele@vcoutlet.com Received: from vcoutlet.com (icihs1.icih.net [208.218.252.100]) by nexen.nexen.com (8.8.5/8.7.3) with SMTP id KAA16149; Fri, 14 Aug 1998 10:57:51 -0400 (EDT) Date: Fri, 14 Aug 1998 10:57:51 -0400 (EDT) Message-Id: <199808141457.KAA16149@nexen.nexen.com> To: dsteele@vcoutlet.com Subject: Videoconferencing Hi, I would first like to thank you for taking the time to read this message regarding HTTP://www.vcoutlet.com . If you are in the videoconferencing market or are planning to be this may be one of the most important messages you will read for a while. At VCoutlet we are offering all of the major brands of videoconferencing products at the lowest price possible. How do we do it? Not a single pushy salesman, very little overhead, the best products and great customer support. When you order from HTTP://www.vcoutlet.com your order is shipped directly to you. Does this sound appealing? well visit our web site and see how much more we have to offer. Once again thank you for your time, we know it is important to you because it is important to us too! ___________________________________________________________ This Message was Composed using Extractor Pro '98 Bulk E- Mail Software. If you wish to be removed from this advertiser's future mailings, please reply with the subject "Remove" and this software will automatically block you from their future mailings. From maria@xedia.com Fri Aug 14 10:15:54 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id KAA09799 for ; Fri, 14 Aug 1998 10:15:54 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA05756 for ; Fri, 14 Aug 1998 10:14:14 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma005738; Fri, 14 Aug 98 10:13:45 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA00789 for ; Fri, 14 Aug 1998 10:13:08 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma000368; Fri, 14 Aug 98 10:12:40 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA16866; Fri, 14 Aug 1998 10:13:16 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA15832 for ; Fri, 14 Aug 1998 08:13:10 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA05668 for ; Fri, 14 Aug 1998 10:13:08 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by almond.bmc.com via smap (V2.0) id xma005547; Fri, 14 Aug 98 10:12:24 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id LAA16580; Fri, 14 Aug 1998 11:09:40 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id LAA22921 for ; Fri, 14 Aug 1998 11:09:29 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id LAA16570 for ; Fri, 14 Aug 1998 11:09:23 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA04869 for ; Fri, 14 Aug 1998 10:09:21 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma004717; Fri, 14 Aug 98 10:08:49 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA26355 for ; Fri, 14 Aug 1998 10:08:10 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma025874; Fri, 14 Aug 98 10:07:35 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA14946 for ; Fri, 14 Aug 1998 10:08:10 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA15380 for disman@nexen.com; Fri, 14 Aug 1998 08:07:40 -0700 (PDT) Date: Fri, 14 Aug 1998 08:07:40 -0700 (PDT) From: Randy Presuhn Message-Id: <199808141507.IAA15380@dorothy.bmc.com> To: disman@nexen.com Subject: Re: I-D ACTION:draft-ietf-disman-schedule-mib-05.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > To: IETF-Announce: ; > Cc: disman@nexen.com > From: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-ietf-disman-schedule-mib-05.txt > Date: Wed, 12 Aug 1998 14:33:24 -0400 ... > Title : Definitions of Managed Objects for > Scheduling Management Operations > Author(s) : D. Levi, J. Schoenwaelder > Filename : draft-ietf-disman-schedule-mib-05.txt > Pages : 30 > Date : 11-Aug-98 ... This version is supposed to accomodate the comments received during our working group last call which ended last week. Are there any objections to sending it forward to our area directors and the IESG? ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From maria@xedia.com Fri Aug 14 10:43:39 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id KAA10021 for ; Fri, 14 Aug 1998 10:43:39 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA09635 for ; Fri, 14 Aug 1998 10:41:59 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma009597; Fri, 14 Aug 98 10:41:26 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA24714 for ; Fri, 14 Aug 1998 10:40:48 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma024252; Fri, 14 Aug 98 10:40:14 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA25708; Fri, 14 Aug 1998 10:40:33 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA17592 for ; Fri, 14 Aug 1998 08:40:21 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id KAA25138 for ; Fri, 14 Aug 1998 10:40:20 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by cashew.bmc.com via smap (V2.0) id xma025082; Fri, 14 Aug 98 10:39:44 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id LAA17427; Fri, 14 Aug 1998 11:36:01 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id LAA23805 for ; Fri, 14 Aug 1998 11:35:47 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id LAA27956 for ; Fri, 14 Aug 1998 11:35:29 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA08424 for ; Fri, 14 Aug 1998 10:35:26 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma008168; Fri, 14 Aug 98 10:34:32 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA18490 for ; Fri, 14 Aug 1998 10:33:54 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma018201; Fri, 14 Aug 98 10:33:35 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA23927; Fri, 14 Aug 1998 10:34:11 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA17386; Fri, 14 Aug 1998 08:34:05 -0700 (PDT) Date: Fri, 14 Aug 1998 08:34:05 -0700 (PDT) From: Randy Presuhn Message-Id: <199808141534.IAA17386@dorothy.bmc.com> To: disman@nexen.com Subject: dealing with spam providers Cc: hostmaster@icihs1.icih.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - Any suggestions for dealing the providers who have neither a "postmaster" nor an "abuse" address? ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- > From MAILMAX-MAIL-DAEMON@208.218.253.92 Fri Aug 14 08:28:16 PDT 1998 > Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA17156 > for ; Fri, 14 Aug 1998 08:27:51 -0700 (PDT) > Received: (from uucp@localhost) > by cashew.bmc.com (8.8.8/8.8.8) id KAA24338 > for ; Fri, 14 Aug 1998 10:27:49 -0500 (CDT) > Message-Id: <199808141527.KAA24338@cashew.bmc.com> > Received: from icih.net(208.218.253.92) > by cashew.bmc.com via smap (V2.0) > id xma024298; Fri, 14 Aug 98 10:27:20 -0500 > Date: Fri, 14 Aug 1998 10:28:39 -0500 CDT > To: rpresuhn@dorothy.bmc.com > From: "MailMAX Error Responder" > Subject: Undeliverable Mail > Status: R > > Sorry rpresuhn@dorothy.bmc.com, > Your message to: postmaster@icihs1.icih.net was not delivered. > > > MailMAX encountered a permanent failure when trying to connect to the remote host. We will NOT try to deliver your outgoing message again. > The Error was: > 911 Could not resolve Host domain for user: postmaster@icihs1.icih.net > > *** This message was automatically generated by the MailMAX Error Responder *** > > -- 8< -- 8< -- [ Original Message As Follows ] -- >8 -- >8 -- > Received: from almond.bmc.com (mail-gw1.bmc.com[198.64.253.22])by ICIHS1(MailMax 2.029) with ESMTP id 0 for rpresuhn@dorothy.bmc.com; Fri, 14 Aug 1998 10:28:23 -0500 CDT > Received: (from uucp@localhost) > by almond.bmc.com (8.8.8/8.8.8) id KAA07093 > for ; Fri, 14 Aug 1998 10:26:42 -0500 (CDT) > Received: from firewall.bmc.com(192.245.162.250) > by almond.bmc.com via smap (V2.0) > id xma007085; Fri, 14 Aug 98 10:26:34 -0500 > Received: (from uucp@localhost) > by dresden.bmc.com (8.8.5/8.8.6) id KAA11756 > for ; Fri, 14 Aug 1998 10:25:55 -0500 (CDT) > Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) > id xma011477; Fri, 14 Aug 98 10:25:34 -0500 > Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) > by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA21504; > Fri, 14 Aug 1998 10:26:08 -0500 (CDT) > Received: (from rpresuhn@localhost) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA17084; > Fri, 14 Aug 1998 08:25:38 -0700 (PDT) > Date: Fri, 14 Aug 1998 08:25:38 -0700 (PDT) > From: Randy Presuhn > Message-Id: <199808141525.IAA17084@dorothy.bmc.com> > To: abuse@icih.net, postmaster@icihs1.icih.net > Subject: Abuse of IETF disman list > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Hi - > > Someone is spamming the IETF distributed management working > group's mailing list, , apparently > by way of your domain. The working group charter is at > http://www.ietf.org/html.charters/disman-charter.html; > a sample of the offensive posting is attached. > As chair of that working group, I request that you take > appropriate action to end this abuse. > > ----------------------------------------------------------------------- > Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com > Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive > Fax: +1 408 616-3101 Sunnyvale, California 94086 USA > ----------------------------------------------------------------------- > In accordance with the BMC Communications Systems Use and Security > Policy, I explicitly state that although my affiliation with BMC may be > apparent, implied, or provided, my opinions are not necessarily those > of BMC Software and that all external representations on behalf of > BMC must first be cleared with a member of "the top management team." > ----------------------------------------------------------------------- > > > From maria@xedia.com Fri Aug 14 08:05:07 PDT 1998 > > Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) > > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA15293 > > for ; Fri, 14 Aug 1998 08:04:36 -0700 (PDT) > > Received: (from uucp@localhost) > > by cashew.bmc.com (8.8.8/8.8.8) id KAA22499 > > for ; Fri, 14 Aug 1998 10:04:31 -0500 (CDT) > > Received: from nexen.nexen.com(204.249.96.18) > > by cashew.bmc.com via smap (V2.0) > > id xma022489; Fri, 14 Aug 98 10:04:18 -0500 > > Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id LAA16290; Fri, 14 Aug 1998 11:01:41 -0400 (EDT) > > Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id KAA22492; Fri, 14 Aug 1998 10:57:52 -0400 (EDT) > > From: dsteele@vcoutlet.com > > Received: from vcoutlet.com (icihs1.icih.net [208.218.252.100]) by nexen.nexen.com (8.8.5/8.7.3) with SMTP id KAA16149; Fri, 14 Aug 1998 10:57:51 -0400 (EDT) > > Date: Fri, 14 Aug 1998 10:57:51 -0400 (EDT) > > Message-Id: <199808141457.KAA16149@nexen.nexen.com> > > To: dsteele@vcoutlet.com > > Subject: Videoconferencing > > Status: R > > > > Hi, I would first like to thank you for taking the time to read this message regarding HTTP://www.vcoutlet.com . If you are in the videoconferencing market or are planning to be this may be one of the most important messages you will read for a while. At VCoutlet we are offering all of the major brands of videoconferencing products at the lowest price possible. How do we do it? Not a single pushy salesman, very little overhead, the best products and great customer support. When you order from HTTP://www.vcoutlet.com your order is shipped directly to you. Does this sound appealing? well visit our web site and see how much more we have to offer. > > > > Once again thank you for your time, we know it is important to you because it is important to us too! > > > > ___________________________________________________________ > > This Message was Composed using Extractor Pro '98 Bulk E- Mail Software. If > > you wish to be removed from this advertiser's future mailings, please reply > > with the subject "Remove" and this software will automatically block you > > from their future mailings. > > > > > > > > -- 8< -- 8< -- [ Original Message End ] -- >8 -- >8 -- > > From maria@xedia.com Fri Aug 14 11:01:01 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id LAA10169 for ; Fri, 14 Aug 1998 11:01:01 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA11197 for ; Fri, 14 Aug 1998 10:59:22 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma011186; Fri, 14 Aug 98 10:59:09 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA10552 for ; Fri, 14 Aug 1998 10:58:31 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma010231; Fri, 14 Aug 98 10:58:11 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA01466; Fri, 14 Aug 1998 10:58:46 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA18402 for ; Fri, 14 Aug 1998 08:58:39 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA11096 for ; Fri, 14 Aug 1998 10:58:38 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by almond.bmc.com via smap (V2.0) id xma010868; Fri, 14 Aug 98 10:57:40 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id LAA18077; Fri, 14 Aug 1998 11:55:07 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id LAA25056 for ; Fri, 14 Aug 1998 11:55:00 -0400 (EDT) Received: from sjsinc.com (sunthing.sjsinc.com [38.163.158.252]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id LAA28091 for ; Fri, 14 Aug 1998 11:54:54 -0400 (EDT) Received: by sjsinc.com Mailer: sendmail (Take-a-guess/Take-a-guess) Protocol: Id: LAA19739; Fri, 14 Aug 1998 11:54:20 -0400 (EDT) For: Date: Fri, 14 Aug 1998 11:54:20 -0400 (EDT) From: Stefan Jon Silverman Message-Id: <199808141554.LAA19739@sjsinc.com> To: rpresuhn@dorothy.bmc.com Subject: Re: dealing with spam providers Cc: disman@nexen.com > From: Randy Presuhn > > Any suggestions for dealing the providers who have neither a "postmaster" > nor an "abuse" address? > Use dig or nslookup to get the Start-of-authority record for the ISP's domain and send mail to the responsible party. Look in the InterNIC's database to find out who the technical, zone, and administrative contacts are. If they are not valid e-mail address send mail to hostmaster@internic.net. Also lookup the first three octets of the IP address range in the arin database to find out whose wires their traffic is running on. All of this info is just below... (ttyp1@sunthing) sjs> dig icih.net soa ; <<>> DiG 2.0 <<>> icih.net soa ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd ra; Ques: 1, Ans: 1, Auth: 1, Addit: 1 ;; QUESTIONS: ;; icih.net, type = SOA, class = IN ;; ANSWERS: icih.net. 86400 SOA icihs1.icih.net. hostmaster.icihs1.icih.net. ( 1998072301 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 691200 ; expire (8 days) 86400 ) ; minimum (1 day) ;; AUTHORITY RECORDS: icih.net. 86400 NS icihs1.icih.net. ;; ADDITIONAL RECORDS: icihs1.icih.net. 86400 A 208.218.252.100 ;; Total query time: 207 msec ;; FROM: sunthing.sjsinc.com to SERVER: default -- 127.0.0.1 ;; WHEN: Fri Aug 14 11:49:04 1998 ;; MSG SIZE sent: 26 rcvd: 179 (ttyp1@sunthing) sjs> whois icih.net Registrant: ICE CUBE IN HELL, L.L.C. (ICIH-DOM) 440 Benmar, Suite 3300 B Houston, TX 77060 Domain Name: ICIH.NET Administrative Contact, Technical Contact, Zone Contact: ICIH DNS ADMIN (ID149-ORG) dns@ICIH.NET 281-405-0772 Fax- 281-539-2147 Billing Contact: ICIH DNS ADMIN (ID149-ORG) dns@ICIH.NET 281-405-0772 Fax- 281-539-2147 Record last updated on 29-Mar-98. Record created on 29-Mar-98. Database last updated on 14-Aug-98 04:39:22 EDT. Domain servers in listed order: DNS1.ICIH.NET 208.218.252.200 DNS2.ICIH.NET 208.218.252.250 The InterNIC Registration Services database contains ONLY non-military and non-US Government Domains and contacts. Other associated whois servers: American Registry for Internet Numbers - whois.arin.net European IP Address Allocations - whois.ripe.net Asia Pacific IP Address Allocations - whois.apnic.net US Military - whois.nic.mil US Government - whois.nic.gov (ttyp1@sunthing) sjs> whonet 208.218.252 UUNET Technologies, Inc. (NETBLK-UUNET1996B) 3060 Williams Drive, Suite 601 Fairfax, Virginia 22031 Netname: UUNET1996B Netblock: 208.192.0.0 - 208.243.255.255 Maintainer: UU Coordinator: Uunet, AlterNet - Technical Support (OA12-ARIN) help@UUNET.UU.NET +1 (800) 900-0241 Domain System inverse mapping provided by: AUTH03.NS.UU.NET 198.6.1.83 AUTH50.NS.UU.NET 198.6.1.161 ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE Record last updated on 07-May-98. Database last updated on 13-Aug-98 16:14:03 EDT. The ARIN Registration Services Host contains ONLY Internet Network Information: Networks, ASN's, and related POC's. Please use the whois server at rs.internic.net for DOMAIN related Information and nic.ddn.mil for MILNET Information. And from all of this info, I would probably complain to UUnet, they do have an abuse mail address and have been known to act very promptly to stamp out this kind of abuse... Hope this helps... Regards, b c++'ing u, %-) sjs PS: I am my own employer, therefore: "all opinions are twice spoken for;" and they do, in fact, scare the hell out of said employer!!! ------------------------------------------------------------------------------- Stefan Jon Silverman - President SJS Associates, N.A., Inc. Suite 15-B Distributed Systems 698 West End Avenue Architecture, Implementation & Security New York, New York 10025 Phone: 212 662 9450 E-mail: sjs@sjsinc.com Fax: 212 662 9461 Text-Page: sjs-page@sjsinc.com Cell: 917 929 1668 ------------------------------------------------------------------------------- Weebles wobble, but they don't fall down!!! ------------------------------------------------------------------------------- From maria@xedia.com Fri Aug 14 11:11:15 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id LAA10252 for ; Fri, 14 Aug 1998 11:11:14 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA12763 for ; Fri, 14 Aug 1998 11:09:35 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012550; Fri, 14 Aug 98 11:08:36 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA19367 for ; Fri, 14 Aug 1998 11:07:56 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma019157; Fri, 14 Aug 98 11:07:44 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA04504; Fri, 14 Aug 1998 11:08:20 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA18675 for ; Fri, 14 Aug 1998 09:08:02 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id LAA26931 for ; Fri, 14 Aug 1998 11:08:00 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by cashew.bmc.com via smap (V2.0) id xma026919; Fri, 14 Aug 98 11:07:51 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id MAA18483; Fri, 14 Aug 1998 12:05:23 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id MAA25888 for ; Fri, 14 Aug 1998 12:04:51 -0400 (EDT) Received: from ctron-dnm.ctron.com (ctron-dnm.cabletron.com [199.92.133.126]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id MAA18473 for ; Fri, 14 Aug 1998 12:04:50 -0400 (EDT) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id MAA02028; Fri, 14 Aug 1998 12:04:53 -0400 (EDT) Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma002024; Fri, 14 Aug 98 12:04:48 -0400 Received: from dur-mail.ctron.com (dur-mail [134.141.69.20]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id MAA29242; Fri, 14 Aug 1998 12:04:43 -0400 (EDT) Received: from cabletron.com (gimli.ctron.com [134.141.64.24]) by dur-mail.ctron.com (8.8.7/8.8.7) with ESMTP id MAA19628; Fri, 14 Aug 1998 12:06:24 -0400 (EDT) Sender: dbh@cabletron.com Message-ID: <35D45F29.9F1E935F@cabletron.com> Date: Fri, 14 Aug 1998 12:00:41 -0400 From: David Harrington Organization: Cabletron Systems, Inc X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Randy Presuhn CC: disman@nexen.com, iesg@ietf.org Subject: Re: dealing with spam providers References: <199808141534.IAA17386@dorothy.bmc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > > Hi - > > Any suggestions for dealing the providers who have neither a "postmaster" > nor an "abuse" address? > Keep the offending email and send it weekly or monthly to your congressmen, so they can understand the scope of the problem for working mailing lists, asking for some needed relief from spammers. Maybe we should establish an IETF WG mailing list spam collection that we could send from the IETF to Congress, to make them understand the impact to the IETF and the ultimate effect spam has on being able to develop standards for the Internet. dbh -- ----------------------------------------------------- #include David Harrington dbh@cabletron.com Spectrum Network Management Platform Core Group Cabletron Systems Inc. ----------------------------------------------------- From maria@xedia.com Tue Aug 18 16:45:37 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA08088 for ; Tue, 18 Aug 1998 16:45:36 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA04526 for ; Tue, 18 Aug 1998 16:43:48 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma004512; Tue, 18 Aug 98 16:43:37 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA20348 for ; Tue, 18 Aug 1998 16:42:59 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020215; Tue, 18 Aug 98 16:42:49 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA13636; Tue, 18 Aug 1998 16:43:22 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA03564 for ; Tue, 18 Aug 1998 14:43:08 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id QAA16158 for ; Tue, 18 Aug 1998 16:43:07 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by cashew.bmc.com via smap (V2.0) id xma016132; Tue, 18 Aug 98 16:43:00 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id RAA02396; Tue, 18 Aug 1998 17:40:07 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id RAA23371 for ; Tue, 18 Aug 1998 17:35:14 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id RAA02220 for ; Tue, 18 Aug 1998 17:35:13 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA02798 for ; Tue, 18 Aug 1998 16:35:09 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma002306; Tue, 18 Aug 98 16:33:26 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA10846 for ; Tue, 18 Aug 1998 16:32:47 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma010537; Tue, 18 Aug 98 16:32:29 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA23483; Tue, 18 Aug 1998 15:47:46 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA03231; Tue, 18 Aug 1998 13:47:16 -0700 (PDT) Date: Tue, 18 Aug 1998 13:47:16 -0700 (PDT) From: Randy Presuhn Message-Id: <199808182047.NAA03231@dorothy.bmc.com> To: WIJNEN@VNET.IBM.COM Subject: Re: WG Last Call: schedule MIB Cc: Harald.Alvestrand@maxware.no, disman@nexen.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Bert - has appeared as an I-D. This revision was issued to address comments raised during the working group last call. Last week I asked the mailing list whether there were any objections to forwarding this to our A-Ds for IESG processing. No objections have been raised. Since the proposed WG last call period has ended, no one has requested an extension of the WG last call period, an updated document has been made available, and there appear to be no further issues, I'm handing it over to you now for processing. Have fun! ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From maria@xedia.com Wed Aug 19 10:27:14 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id KAA16529 for ; Wed, 19 Aug 1998 10:26:56 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA17100 for ; Wed, 19 Aug 1998 10:25:01 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma017066; Wed, 19 Aug 98 10:24:29 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA26113 for ; Wed, 19 Aug 1998 10:23:41 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma025019; Wed, 19 Aug 98 10:22:25 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA03671; Wed, 19 Aug 1998 10:21:53 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA06379 for ; Wed, 19 Aug 1998 08:21:33 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA16768 for ; Wed, 19 Aug 1998 10:21:17 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by almond.bmc.com via smap (V2.0) id xma016755; Wed, 19 Aug 98 10:21:12 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id LAA23362; Wed, 19 Aug 1998 11:16:48 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id LAA11148 for ; Wed, 19 Aug 1998 11:15:39 -0400 (EDT) Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id LAA02930 for ; Wed, 19 Aug 1998 11:15:38 -0400 (EDT) Received: from relay3.server.ibm.com (relay3.server.ibm.com [9.14.2.100]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id LAA71542; Wed, 19 Aug 1998 11:03:42 -0400 Received: from US.IBM.COM (d04lms02.raleigh.ibm.com [9.37.164.194]) by relay3.server.ibm.com (8.8.7/8.8.7) with SMTP id LAA24982; Wed, 19 Aug 1998 11:15:14 -0400 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU008 id 5040200018376073; Wed, 19 Aug 1998 11:26:08 -0400 From: Robert Moore To: Cc: , , , , Subject: Comment on Message-ID: <5040200018376073000002L032*@MHS> Date: Wed, 19 Aug 1998 11:26:08 -0400 MIME-Version: 1.0 Content-Type: text/plain I took a quick pass through . All of my comments on -04 were dealt with satisfactorily. I do have one question, however, on some new text that did not result from my review of the document. In the new text in section 3.4 describing what happens during time transitions, should any / all of the "should"s really be "shall"s? There's an obvious trade-off here between ease of agent implementation versus predictability of agent behavior. If the WG / IESG want to come down at the "should" end of the scale, that's fine. But speaking now as a WG member, I'd like this to be a conscious decision, not just the result of the words the editor happened to choose. If you want my opinion, I'd say that scheduled actions SHALL be done exactly once (for each scheduled occurrence during a time transition), and SHALL be done in the correct order, and they SHOULD be invoked at the times indicated in the document. Randy, Bert, and Harald, I think it's up to you to decide how to handle this question, as "belonging" to the WG or to the IESG. I don't think this should in any way hold up progression of the document, but that's because I think we should be able to decide quickly what we want the document to say. If the consensus is for all SHOULD's (which is what the document says now), I'm willing to go along with that. It's very easy for document editors (including me!) to include the SHALL / SHOULD paragraph from RFC 2119 in our documents. But it's *really* hard to make sure we actually do use these terms, every time, in the way that RFC 2119 specifies. I don't know what to do about this, other than to raise questions like the one I've raised here. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com From maria@xedia.com Wed Aug 19 11:53:53 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id LAA17226 for ; Wed, 19 Aug 1998 11:53:53 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA24122 for ; Wed, 19 Aug 1998 11:52:02 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024113; Wed, 19 Aug 98 11:51:35 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA10093 for ; Wed, 19 Aug 1998 11:50:56 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma009743; Wed, 19 Aug 98 11:50:29 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA02678; Wed, 19 Aug 1998 11:51:05 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA06988 for ; Wed, 19 Aug 1998 09:50:47 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id LAA07913 for ; Wed, 19 Aug 1998 11:50:45 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by cashew.bmc.com via smap (V2.0) id xma007870; Wed, 19 Aug 98 11:50:16 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id MAA25512; Wed, 19 Aug 1998 12:46:45 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id MAA13339 for ; Wed, 19 Aug 1998 12:46:03 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id MAA03303 for ; Wed, 19 Aug 1998 12:45:52 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA23786 for ; Wed, 19 Aug 1998 11:45:47 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma023758; Wed, 19 Aug 98 11:45:29 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA04819 for ; Wed, 19 Aug 1998 11:44:50 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma004720; Wed, 19 Aug 98 11:44:45 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA00423 for ; Wed, 19 Aug 1998 11:45:22 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA06943 for disman@nexen.com; Wed, 19 Aug 1998 09:45:16 -0700 (PDT) Date: Wed, 19 Aug 1998 09:45:16 -0700 (PDT) From: Randy Presuhn Message-Id: <199808191645.JAA06943@dorothy.bmc.com> To: disman@nexen.com Subject: Re: Comment on Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Wed, 19 Aug 1998 11:26:08 -0400 > Subject: Comment on > From: remoore@us.ibm.com > To: disman@nexen.com > Cc: wijnen@vnet.ibm.com, Harald.Alvestrand@maxware.no, schoenw@ibr.cs.tu-bs.de, > levi@snmp.com, rpresuhn@bmc.com ... > In the new text in section 3.4 describing what happens during time > transitions, should any / all of the "should"s really be "shall"s? > There's an obvious trade-off here between ease of agent implementation > versus predictability of agent behavior. If the WG / IESG want to > come down at the "should" end of the scale, that's fine. But speaking > now as a WG member, I'd like this to be a conscious decision, not just > the result of the words the editor happened to choose. > > If you want my opinion, I'd say that scheduled actions SHALL be done > exactly once (for each scheduled occurrence during a time transition), > and SHALL be done in the correct order, and they SHOULD be invoked > at the times indicated in the document. This seems reasonable to me, but I'm willing to be persuaded. Since this DOES have consequences for interoperability, I think that using the SHALL wording is the best way to go. If there are other opinions, please voice them now! > Randy, Bert, and Harald, I think it's up to you to decide how to > handle this question, as "belonging" to the WG or to the IESG. I don't > think this should in any way hold up progression of the document, but > that's because I think we should be able to decide quickly what we > want the document to say. If the consensus is for all SHOULD's (which > is what the document says now), I'm willing to go along with that. ... ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From maria@xedia.com Fri Aug 21 20:33:52 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id UAA14539 for ; Fri, 21 Aug 1998 20:33:52 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id UAA10393 for ; Fri, 21 Aug 1998 20:31:57 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma010375; Fri, 21 Aug 98 20:31:32 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id UAA18855 for ; Fri, 21 Aug 1998 20:30:53 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma018705; Fri, 21 Aug 98 20:30:37 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id UAA01359; Fri, 21 Aug 1998 20:31:13 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id SAA10111 for ; Fri, 21 Aug 1998 18:31:12 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id UAA10291 for ; Fri, 21 Aug 1998 20:31:10 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by almond.bmc.com via smap (V2.0) id xma010112; Fri, 21 Aug 98 20:30:09 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id VAA29477; Fri, 21 Aug 1998 21:27:32 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id VAA02802 for ; Fri, 21 Aug 1998 21:24:24 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id VAA29329 for ; Fri, 21 Aug 1998 21:24:23 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id UAA08881 for ; Fri, 21 Aug 1998 20:24:21 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma008741; Fri, 21 Aug 98 20:23:32 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id UAA13273 for ; Fri, 21 Aug 1998 20:22:51 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma012942; Fri, 21 Aug 98 20:22:21 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id UAA00198 for ; Fri, 21 Aug 1998 20:22:57 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA10046 for disman@nexen.com; Fri, 21 Aug 1998 18:22:57 -0700 (PDT) Date: Fri, 21 Aug 1998 18:22:57 -0700 (PDT) From: Randy Presuhn Message-Id: <199808220122.SAA10046@dorothy.bmc.com> To: disman@nexen.com Subject: Updated disman agenda Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - I've had two requests for time for technical presentations. Here's the revised agenda. Disman working group 42nd IETF meeting in Chicago Thursday, August 27 at 0900-1130 1. Adminstrative matters 1.1 selection of minute-taker See http://www.ietf.org/instructions/minutes.html 1.2 circulation of signup sheet 1.3 Review of Agenda 1.4 Allocation of time 2. Status of Current work 2.1 Script MIB: IESG review, IETF Last Call after Chicago 2.2 Schedule MIB: IESG review, IETF Last Call after Chicago 2.3 Notification/Log MIB 2.4 Event MIB 2.5 Expression MIB 2.6 Framework 3. Review of Interactions with other working groups 3.1 SNMPv3 issues (forwarded from SNMPv3 WG meeting on Monday) 3.2 AgentX issues (forwarded from AgentX WG meeting on Wednesday) 4. Charter updates See http://www.ietf.org/html.charters/disman-charter.html 4.1 completed items 4.2 changes to target dates 4.3 Possibile additions to charter: 4.3.1 Remote Operations MIB (suggest discussion deferred until after presentation 5.2) 4.3.2 "Script MIB Extensibility" http://www.ibr.cs.tu-bs.de/projects/jasmin/smx.ps 5. Technical Presentations See http://www.ietf.org/instructions/slides.html 5.1 implementation reports David Levi 5.2 remote operations MIB Ken White 6. Wrap-up 6.1 reminders to minute-takers and presenters 6.2 retrieval of sign-up sheet ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From maria@xedia.com Mon Aug 24 23:43:11 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id XAA02039 for ; Mon, 24 Aug 1998 23:43:10 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id XAA02906 for ; Mon, 24 Aug 1998 23:41:09 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma002543; Mon, 24 Aug 98 23:39:37 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id XAA08765 for ; Mon, 24 Aug 1998 23:38:53 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma008030; Mon, 24 Aug 98 23:38:11 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id XAA11928; Mon, 24 Aug 1998 23:38:00 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id VAA16916 for ; Mon, 24 Aug 1998 21:37:45 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id XAA04453 for ; Mon, 24 Aug 1998 23:37:39 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by cashew.bmc.com via smap (V2.0) id xmaa04443; Mon, 24 Aug 98 23:37:28 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id AAA07740; Tue, 25 Aug 1998 00:32:28 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id AAA18803 for ; Tue, 25 Aug 1998 00:29:22 -0400 (EDT) Received: from lexicon.ins.com (lexicon.ins.com [199.0.193.11]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id AAA28419 for ; Tue, 25 Aug 1998 00:29:20 -0400 (EDT) Received: from localhost (stevew@localhost) by lexicon.ins.com (8.8.8/8.8.8) with SMTP id VAA14783 for ; Mon, 24 Aug 1998 21:29:13 -0700 (PDT) Date: Mon, 24 Aug 1998 21:29:13 -0700 (PDT) From: Steve Waldbusser To: disman@nexen.com Subject: New Framework Document Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Here's a new version I sent to the internet drafts publisher. Steve Internet Draft Distributed Management Framework Aug, 1998 Distributed Management Framework August 23, 1998 Authors: Andy Bierman Cisco Systems abierman@cisco.com Maria Greene Ascom Nexion greene@nexen.com Bob Stewart Cisco Systems bstewart@cisco.com Steve Waldbusser International Network Services (INS) waldbusser@ins.com 1. Status of this Memo This document is an Internet-Draft. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Disman Team Expires Feb, 1999 [Page 1] Internet Draft Distributed Management Framework Aug, 1998 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract This memo defines a distributed management architecture for use with the SNMP network management architecture. This memo does not specify a standard for the Internet community. Disman Team Expires Feb, 1999 [Page 2] Internet Draft Distributed Management Framework Aug, 1998 3. Overview Distributed Management is the delegation of control from one management station to another. While the SNMP Network Management Framework does not specifically address distributed management, this function is desired and has been implemented and deployed in the internet using proprietary architectures. It is desired that there be a standard upon which to promote interoperability, as well as a common framework upon which various systems can be built. The goals of distributed management are: o Scalability through Distribution In order to build network management systems that have the power to manage very large networks, it is important to reduce bottlenecks in the management system. Therefore, a distributed systems approach is often helpful when building large management systems. A distributed approach is often very effective at reducing load on the central management station, and may be effective at reducing the load that the central management station places on backbone networks. However, a distributed approach usually has no benefit in reducing load on remote networks and has no benefit in reducing load on management agents. Further, in a distributed data collection architecture, if all data collected is eventually forwarded to the central management station (without aggregation or compression), then no benefit in backbone load or central management station load should be expected (except perhaps to time- shift this load to a time of excess capacity, at the expense of a lack of timeliness of data. o Disconnected or Low-Bandwidth Operation There are sometimes conditions when a management station will not be in constant contact with all portions of the managed network. This is sometimes by design in an attempt to lower communications costs (especially when communicating over a WAN or dialup link), or by accident as network failures affect the communications between the management station and portions of the managed network. For this reason, a distributed management station will be configured to perform network management functions, even when communication with the management station may not be Disman Team Expires Feb, 1999 [Page 3] Internet Draft Distributed Management Framework Aug, 1998 possible or efficient. The distributed management station may then attempt to notify the management station when an exceptional condition occurs. Thus, even in circumstances where communication with the distributed management station is not continuous, network management operations may run continuously, communicating with the management station conveniently and efficiently, on an as-needed basis. o Mirroring organization boundaries and processes Business organizations are typically set up in a hierarchical fashion. Multiple people in the hierarchy have different roles, responsibilites, and authority. The network management system often has to be configured to match this organization. Distributed network managers can be set up in a hierarchy that matches the roles of various people in the organization. o Promotes a modular system architecture A modular system architecture allows flexibility and re- usability of network management components. This also enables a multi-vendor approach to building management systems. A distributed network management system with well-defined interfaces creates this modular scheme. This document defines an architectural framework for standards-based distributed management 4. Relationship to the SNMP Management Framework A distributed network management station is a management station that receives requests from another manager and executes those requests by performing management operations on agents or other managers. Note that these requests may take a long time to execute, and may be registered indefinitely. This framework uses the services of the SNMP Management Framework. 4.1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. Disman Team Expires Feb, 1999 [Page 4] Internet Draft Distributed Management Framework Aug, 1998 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 RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. 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. Disman Team Expires Feb, 1999 [Page 5] Internet Draft Distributed Management Framework Aug, 1998 5. Distributed Management Framework The distributed management framework consists of applications and services. A distributed management application performs some management function, often by monitoring and controlling managed elements. These applications perform functions such as threshold polling, historical data polling, or discovery. The specifications and communications protocols of some of these applications will be defined by standards, while others will be enterprise specific. Distributed management services are a collection of services that make up the run-time environment for the distributed management application. These services are crucial to ensuring the usability, scalability, and efficiency of the distributed management applications that depend on them. Some of these services are mandatory, while others are optional. Further, even the mandatory services allow varying depths of support, as described further, below. Each of these services is made available through a MIB interface. The purpose of these services is to provide true enterprise management that allows distributed management functions to be used on an enterprise-wide basis without undue amounts of administrative difficulty. These services also make a set of applications more efficient because the service can perform functions or store information once for all applications on the local system. Further, less work is required to be put into writing the application because some of the core functions are performed elsewhere. 5.1. Known Systems The Known Systems service provides a list of all systems which the distributed management system knows about and is prepared to perform management operations upon. This list may be populated by a continuously-running auto-discovery process, it may be populated with SNMP SET requests, or it may be a static list dictated by the system. Disman Team Expires Feb, 1999 [Page 6] Internet Draft Distributed Management Framework Aug, 1998 This service also stores type and attribute information for each of the known systems. The purpose of this service is to allow a management application to be executed on a list of systems so that true enterprise management is possible rather than more ad-hoc management functions. Further, the targets of management applications can be configured separately from the applications to reduce administrative burden as the list of known systems changes. An example of a known systems list is a list of all systems at a site discovered by the autodiscovery module, along with various addressing, type, and attribute information for each. 5.2. Management Domains The Management Domains service provides a list of known systems which is a subset of the entire list of known systems. The subset is defined by a rule, or filter, which selects only the known systems that match or those that don't match certain criteria. These domains are multiple, potentially overlapping, sets of devices based on (human) organizational boundaries that define the extents over which management operations should be performed. The purpose of this service is to allow a management application to be executed on a list of known systems within a particular domain. Further, as the domains change over time, the application will automatically be kept up to date and will only monitor the correct systems. An example of a management domain is the subset of all known systems that is on the engineering LAN. 5.3. Management Operations Targets The Management Operations Targets service provides a list of known systems in a set of domains that match certain criteria that indicate that it makes sense to perform a particular management function on them. Disman Team Expires Feb, 1999 [Page 7] Internet Draft Distributed Management Framework Aug, 1998 The purpose of this service is to direct management operations to be performance only on those systems where that operation would make sense. Because this is described as a filter, there are no static configuration requirements that would be unacceptable in a dynamically changing network environment. An example of a management operation target list is the subset of all known routers on the engineering LAN. 5.4. Credential Delegation The Credential Delegation Service allows credentials of a network management user to be delegated to a distributed management application so that it can perform secure operations on behalf of that user. Fundamental to this distributed management architecture is the notion that distributed management operations must not run with the credentials of the distributed manager. To do so would require that the authorization of these credentials (or subsets of this authorization) would need to be apportioned to users of that distributed manager in a pre-defined and secure way. This would require the creation of a access control architecture mirroring the SNMP View-Based Access Control architecture that would control what subsets of authority are available to what users. The existing View-Based Access Control mechanism was not designed for this task and is not appropriate. Further, it would require that the distributed manager be configured in a way that was consistent with the access control policy embodied in the managed systems. This would be extremely problematic because: 1. This would require a massive amount of configuration to be replicated on the distributed manager 2. If any part of this configuration on the distributed manager is inconsistent with that on the managed systems, a security hole could be exposed. Because it is assumed that the distributed manager adds no credentials to management operations, when a manager wishes to configure a distributed manager to perform secure transactions on its behalf, it must download to the distributed manager the appropriate credentials to be placed in secure SNMP messages, identifying them as the manager. A credential contains at Disman Team Expires Feb, 1999 [Page 8] Internet Draft Distributed Management Framework Aug, 1998 least the securityModel, securityName, securityLevel, authentication and privacy keys, and an indication of which management targets the credential should be used for. 5.4.1. Definitions ----------- --------------- -------------- | | | | | | | Manager |---------->| Distributed |------------->| Management | | | Disman | Manager | Target | Target | | | User | | User | | | | | | Identity | | | | | | | | ----------- --------------- -------------- 1. Disman User - The user whose credentials are used to configure the distributed manager for an operation and to download credentials for that operation. There is no relationship implied between the disman user and the user(s) who's credentials are installed (in other words, "joe" can install credentials for "ops-center-east" as well as "joe"). 2. Target User Identity - The user identity used in SNMP messages between the distributed manager and management targets. 3. Credential - The set of secrets that are transferred to the distributed manager giving it the authority to act as an identity. 4. Owner - The disman user who sets up a distributed management function, including the credentials for the function. 5. Invoker - The user who invokes a previously setup distributed management function. The owner may choose to allow others to invoke a function, potentially allowing that function to operate with the owner's credentials (of course the owner would want to tightly constrain what the function was configured to perform). 6. Invokation Identity - The identity of the credentials a function is operating with. These may be of the owner, of the invoker, or possibly the union of both Disman Team Expires Feb, 1999 [Page 9] Internet Draft Distributed Management Framework Aug, 1998 credentials. Because multiple Disman Users will have access to a Distributed Manager, the Credential Delegation Service will be responsible for ensuring that credentials are only used by authorized users. The Credential Delegation Service will include: 1. Credential Store - a MIB in which to transfer and store credentials 2. MIB prototype - a prototype MIB fragment that will be added to disman functions that wish to use the Credential Store 3. Access Control Policy - a policy for configuration of the VACM MIB for use with the Credential Delegation Service. This will limit access to the credential store. 5.5. Delegation Control The Delegation Control Service provides functions that limit the resource usage of a distributed management application that has had control delegated to it. Network management applications are often responsible for adding stress on the network and causing problems. Examples are excessive polling load on slow-speed networks or on router CPUs. This problem will become even more dangerous when network management functions are delegated to distributed management stations. Policies need to be configured that limit average and burst polling, notification, and broadcast rates. These rates may be defined for the sending system as a whole, per end node, or per management application on the sending system. It is also important to have a "Deadman's switch" so that delegated applications will not continue indefinitely if their "sponsor" has forgotten about them. Disman Team Expires Feb, 1999 [Page 10] Internet Draft Distributed Management Framework Aug, 1998 5.6. Scheduling The Scheduling Service allows the execution of distributed management applications to be controlled so that they run at a particular time, periodically, or based on the occurance of another event. 5.7. Reliable Notification The Reliable Notification Service provides services that ensure that notifications are received correctly. For example, all the information that describes an event may not fit within a single PDU, so an eventID varbind is defined that associates multiple PDU's as describing the same event. It is also necessary to know if the entire notification has been received or if more PDU's are still outstanding. Further, a receiving management station must be given more information so that it can distinguish duplicated inform PDU's because events are not idempotent. No rule makes it mandatory for the requestID to be unique for all PDUs sent from a system. In addition, a logging mechanism provides for retrieval of notifications after a communications failure. 5.8. Notification Destinations The Notification Destination Service provides services for configuring destinations for notifications. When management functions are delegated and MLMs are given the autonomy to generate notifications, they need to be configured as to where the notifications should be sent. Additionally, retry counts and numbers need to be configured. Average and burst notification rates need to be defined. 6. Acknowledgments This document was produced by the IETF Distributed Network Management Working Group. Disman Team Expires Feb, 1999 [Page 11] Internet Draft Distributed Management Framework Aug, 1998 7. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998 [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991 [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. Disman Team Expires Feb, 1999 [Page 12] Internet Draft Distributed Management Framework Aug, 1998 [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, January 1998 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., Cisco Systems, Inc., January 1998 Disman Team Expires Feb, 1999 [Page 13] Internet Draft Distributed Management Framework Aug, 1998 Table of Contents 1 Status of this Memo ................................... 1 2 Abstract .............................................. 2 3 Overview .............................................. 3 4 Relationship to the SNMP Management Framework ......... 4 4.1 The SNMP Management Framework ....................... 4 5 Distributed Management Framework ...................... 6 5.1 Known Systems ....................................... 6 5.2 Management Domains .................................. 7 5.3 Management Operations Targets ....................... 7 5.4 Credential Delegation ............................... 8 5.4.1 Definitions ....................................... 9 5.5 Delegation Control .................................. 10 5.6 Scheduling .......................................... 11 5.7 Reliable Notification ............................... 11 5.8 Notification Destinations ........................... 11 6 Acknowledgments ....................................... 11 7 References ............................................ 12 Disman Team Expires Feb, 1999 [Page 14] From maria@xedia.com Tue Aug 25 13:05:25 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA08642 for ; Tue, 25 Aug 1998 13:05:25 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA02194 for ; Tue, 25 Aug 1998 13:03:21 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma029172; Tue, 25 Aug 98 12:52:36 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA17794 for ; Tue, 25 Aug 1998 12:51:55 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma017494; Tue, 25 Aug 98 12:51:41 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA23502; Tue, 25 Aug 1998 12:52:16 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA21001 for ; Tue, 25 Aug 1998 10:51:57 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA28957 for ; Tue, 25 Aug 1998 12:51:54 -0500 (CDT) Received: from nexen.nexen.com(204.249.96.18) by almond.bmc.com via smap (V2.0) id xma028687; Tue, 25 Aug 98 12:50:57 -0500 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id NAA24163; Tue, 25 Aug 1998 13:48:10 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id NAA19927 for ; Tue, 25 Aug 1998 13:47:03 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id NAA02164 for ; Tue, 25 Aug 1998 13:47:01 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.1/8.9.0) with ESMTP id TAA19430; Tue, 25 Aug 1998 19:46:59 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id TAA04496; Tue, 25 Aug 1998 19:46:58 +0200 Date: Tue, 25 Aug 1998 19:46:58 +0200 Message-Id: <199808251746.TAA04496@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.bmc.com CC: disman@nexen.com Subject: branch in the experimental subtree Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII We would like to make our prototype implementation of the Script MIB accessible over the Internet so that you can throw packets at it. For this purpose, we would need an OID where we can register the Script MIB until we get the official number. I think we should allocate a branch below experimental (1.3.6.1.3). Does anyone know the procedure to allocate a number in this branch? Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289)