From owner-disman@dorothy.peer.com Thu Feb 3 11:07:54 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21430 for ; Thu, 3 Feb 2000 11:07:47 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA22006; Thu, 3 Feb 2000 10:06:32 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA04685 for disman-list; Thu, 3 Feb 2000 07:52:24 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA04680 for ; Thu, 3 Feb 2000 07:52:19 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id JAA16567 for ; Thu, 3 Feb 2000 09:52:41 -0600 (CST) Received: from seymour47.SNMP.COM (seymour47.snmp.com [192.147.142.47]) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) with ESMTP id KAA25242; Thu, 3 Feb 2000 10:52:25 -0500 (EST) From: Alan Luchuk Received: (from luchuk@localhost) by seymour47.SNMP.COM (8.9.3/snmpclient.mc-990423) id KAA23899; Thu, 3 Feb 2000 10:52:25 -0500 (EST) Date: Thu, 3 Feb 2000 10:52:25 -0500 (EST) Message-Id: <200002031552.KAA23899@seymour47.SNMP.COM> To: disman@dorothy.peer.com Subject: Re: DISMAN-SCHEDULE-MIB Cc: luchuk@snmp.com Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Hello all, >Juergen Schoenwaelder wrote: > >> >>>>> Thippanna Hongal writes: >> >> >> I have some question regarding daylight sayings non existent time. >> >> If an calendar schedule is scheduled to shoot every minute, and if >> >> the time is changed from 2 PM to 3 PM, Do I need to schedule 60 >> >> times the schedule at 3 PM or it is triggered only once ?. >> >> Shall we add a sentence which makes that clearer? What about adding >> the following sentence directly below the last paragraph of section >> 3.4 in RFC 2591: >> >> This rule applies to all events scheduled for nonexistent >> time, regardless whether the scheduled events originate from >> one or multiple rows in the schedTable. >> >> Would that help? >> > >I do not see any confusion over the explanation in RFC regarding the >non-existent time. > >My question is a specific case of one schedule and one table. > >I have a single row and which does calendar schedule for 60 times in hour. >For 2hrs of non existant time >I have to do SNMP SET for 60 * 2 times at the end of 3 PM. This might lead >to net congestion. If a user creates a single calendar-scheduled event that can trigger every "n" minutes, that user is really trying to create a periodic event. Presumably the reason for doing this using calendar scheduling instead of periodic scheduling is to (hopefully) make sure there is no cumulative drift of the interval from the intended minute. That is, one might imagine that an event scheduled as a 300 second interval might drift from running on every 5th-minute (like minute 5, 10, 15, etc., after the hour). But a event, calendar-scheduled to trigger on every 5th minute, should *not* cumulatively drift from minute 5, 10, 15, etc., after the hour. Assuming the real intent of calendar-scheduling an event to trigger every "n" minutes is really to achieve a reduced-drift periodic event. If all events like this *are* triggered immediately after the missing hour, then the period between all of these triggers would be wrong. It would seem the right thing to do is to *not* trigger these events *at all* after the missing hour. That way, the periodicity would be maintained. My personal preference would be to add Juergen's statement above and move on. But I see the utility of being able to trigger a periodic event that never drifts from the intended minute after the hour. As a first-cut suggestion, maybe the algorithm should be something like: - If a calendar-scheduled event is scheduled to occur ONCE during the missing hour, then periodicity is _not_ important, so trigger the event immediately after the missing hour; otherwise - If a calendar-scheduled event is scheduled to occur MULTIPLE TIMES during the missing hour, then periodicity _is_ important, so do _not_ trigger the event immediately after the missing hour. >At this time I would like to add another implementation feature. > >If a schedule fails to do its intended operation for certain number of time >then schedOperStatus is set to DISABLED. I see the utility of this, and can align with it. >While considering the number of times , I consider the interval between the >schedules too. I am unclear about the utility of this. I am also unclear about the algorithm that is used to decide when to disable the event. Regards, --Alan ----------------------------------------------------------------------------- Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 U.S.A. http://www.snmp.com/ ----------------------------------------------------------------------------- Note: Our area code changed to 865 from 423 in November. If you have trouble reaching us via area code 865, please try the old area code (423) and let us know. Both area codes should work until April. From owner-disman@dorothy.peer.com Fri Feb 4 04:09:36 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21048 for ; Fri, 4 Feb 2000 04:09:36 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id DAA20739; Fri, 4 Feb 2000 03:09:25 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id BAA22886 for disman-list; Fri, 4 Feb 2000 01:07:02 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id BAA22881 for ; Fri, 4 Feb 2000 01:06:57 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id DAA20411 for ; Fri, 4 Feb 2000 03:07:29 -0600 (CST) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.117.200.23]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id EAA210830; Fri, 4 Feb 2000 04:06:14 -0500 Received: from BLDVMA.boulder.ibm.com (bldvma.boulder.ibm.com [9.99.64.30]) by northrelay03.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id EAA101140; Fri, 4 Feb 2000 04:07:24 -0500 Message-Id: <200002040907.EAA101140@northrelay03.pok.ibm.com> Received: by BLDVMA.boulder.ibm.com (IBM VM SMTP Level 310) via spool with SMTP id 4180 ; Fri, 04 Feb 2000 02:08:13 MST Date: Fri, 4 Feb 00 10:07:27 CET From: "Bert Wijnen" To: wkenneth@us.ibm.com, schoenw@ibr.cs.tu-bs.de cc: David.Partain@ericsson.com, disman@dorothy.peer.com Subject: changes of draft-ops-endpoint-mib-05.txt Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Ref: Your note of Thu, 3 Feb 2000 21:12:08 -0500 Subject: Re: changes of draft-ops-endpoint-mib-05.txt Ken WHite asked in a private email: > > 1. Can the endpoint MIB be published quick enough so as not to delay > REMOPS? > > I would like to hear Bert's opinion and based on this poll the > DISMAN list > I think it can. However, it needs to go through a 3-week IETF Last Call, which it seems we can start coming Monday. If the Last call does not generate major objections, then I can try to get endpoint MIB on IESG agenda for 9 Mar. The REMOPS MIB also still needs to go through IETF Last Call, but that one only needs 2 weeks (after we get IESG MIB review closed) If we can issue that one next monday, then it could be on IESG agenda either on 24 Feb or on 9 March. So for timing, I would say they can progress close enuf together to make the changes and use the endpoint MIB TCs. Bert From owner-disman@dorothy.peer.com Fri Feb 4 21:28:51 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15470 for ; Fri, 4 Feb 2000 21:28:49 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id UAA19651; Fri, 4 Feb 2000 20:28:16 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA27305 for disman-list; Fri, 4 Feb 2000 18:27:10 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id SAA27300 for ; Fri, 4 Feb 2000 18:26:47 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id UAA19563 for ; Fri, 4 Feb 2000 20:27:19 -0600 (CST) Received: (ramk@localhost) by itech-view2.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id SAA21472; Fri, 4 Feb 2000 18:26:35 -0800 (PST) From: Ram Kavasseri Message-Id: <200002050226.SAA21472@itech-view2.cisco.com> Subject: draft-ietf-disman-express-mib-11.txt To: internet-drafts@ietf.org Date: Fri, 4 Feb 2000 18:26:35 -0800 (PST) Cc: disman@dorothy.peer.com X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Please accept draft-ietf-disman-express-mib-11.txt for posting as an internet draft. It contains text-changes to the last paragraph of Section 3.1 "Usage". Thank you, Ram Kavasseri Internet Draft Distributed Management Expression MIB 4 February 2000 Distributed Management Expression MIB 4 February 2000 draft-ietf-disman-express-mib-11.txt Bob Stewart Cisco Systems, Inc. Ramanathan R. Kavasseri Cisco Systems, Inc. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Please send comments to the Distributed Management Working Group, . Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Expires 4 August 2000 [Page 1] Internet Draft Distributed Management Expression MIB 4 February 2000 1. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing expressions of MIB objects. The results of these expressions become MIB objects usable like any other MIB object, such as for the test condition for declaring an event. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. Expires 4 August 2000 [Page 2] Internet Draft Distributed Management Expression MIB 4 February 2000 o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. Expires 4 August 2000 [Page 3] Internet Draft Distributed Management Expression MIB 4 February 2000 3. Overview 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 may be used like any other MIB objects. These custom- defined objects are thus usable anywhere any other MIB object can be used. For example, they can be used by a management application directly or referenced from another MIB, such as the Event MIB [MIBEventMIB]. They can even be used by the Expression MIB itself, forming expressions of expressions. The Expression MIB is instrumentation for a 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 severely limited environment. Nevertheless, due to dependencies from the Event MIB [RFCEventMIB] and the need to support as low-end a system as possible, the Expression MIB can be somewhat stripped down for lower-power, lower-resource implementations, as described in the Subsets section, below. Implementation of the Expression MIB in an managed system 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 implementation must be possible within typical managed systems with some constraints on system resources. 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. An example of a use of the Expression MIB would be to provide custom objects for the Event MIB [RFCEventMIB]. A complex expression can evaluate to a rate of flow or a boolean and thus be subject to testing Expires 4 August 2000 [Page 4] Internet Draft Distributed Management Expression MIB 4 February 2000 as an event trigger, resulting in an SNMP notification. Without these capabilities such monitoring would be 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. 3.2. Persistance Although like most MIBs this one has no explicit controls for the persistance of the values set in configuring an expression, a robust, polite implementation would certainly not force its managing applications to reconfigure it whenever it resets. Again, as with most MIBs, it is implementation specific how a system provides and manages such persistance. To speculate, one could imagine, for example, that persistance depended on the context in which the expression was configured, or perhaps system-specific characteristics of the expression's owner. Or perhaps everything in a MIB such as this one, which is clearly aimed at persistant configuration, is automatically part of a system's other persistant configuration. 3.3. Operation Most of the operation of the MIB is described or implied in the object definitions but a few highlights bear mentioning here. 3.3.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 Expires 4 August 2000 [Page 5] Internet Draft Distributed Management Expression MIB 4 February 2000 a difference the result is a boolean indicating whether or not the object changed value since the last sample. 3.3.2. Wildcards Wildcards 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. Otherwise, any successful evaluation of the wildcarded expression would be the result of the accidental matching of the wildcarded portion of the object identifiers in the expression. Such an evaluation will likely produce results which are not meaningful. The expression can be evaluated only for those instances where all the objects in the expression are available with the same value for the wildcarded portion of the instance. 3.3.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 method (delta or absolute) used to evaluate the expression. If there are no delta or change values in an expression, the evaluation occurs on demand, i.e. when a requester attempts to read the value of the expression. In this case all requesters get a freshly calculated value. For expressions with delta or change values, evaluation goes on Expires 4 August 2000 [Page 6] Internet Draft Distributed Management Expression MIB 4 February 2000 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. It may be possible that a delta expression which was evaluated successfully for one sample period may not be successfully evaluated in the next sample period. This may, for example, be due to missing instances for some or all of the objects in the expression. In such cases, the value from the previous sample period (with the successful evaluation) must not be carried forward to the next sample period (with the failed evaluation). 3.3.4. Value Identification Values resulting from expression evaluation are identified with a combination of the object identifier (OID) for the data type from expValueTable (such as expValueCounter32Val), the expression name, and an OID fragment. The OID fragment is not an entire OID beginning with iso.dod.org (1.3.6). Rather it begins with 0.0. The remainder is either another 0 when there is no wildcarding or the instance that satisfied the wildcard if there is wildcarding. 3.4. Subsets To pare down the Expression MIBs complexity and use of resources an implementor can leave out various parts. 3.4.1. No Wildcards Leaving out wildcarding significantly reduces the complexity of retrieving values to evaluate expressions and the processing required to do so. Such an implementation would allow expressions made up of individual MIB objects but would not be suitable for expressions applied across large tables as each instance in the table would require a separate expression definition. Furthermore it would not be suitable for tables with arbitrary, dynamic instances, as expressions definitions could not predict what instance values to use. An implementation without wildcards might be useful for a self-managing Expires 4 August 2000 [Page 7] Internet Draft Distributed Management Expression MIB 4 February 2000 system with small tables or few dynamic instances, or one that can do calculations only for a few key objects. 3.4.2. No Deltas Leaving out delta processing significantly reduces state that must be kept and the burden of ongoing processing even when no one is looking at the results. Unfortunately it also makes expressions on counters unusable, as counters have meaning only as deltas. An implementation without deltas might be useful for a severly limited, self-managing system that has no need for expressions or events on counters. Although conceivable, such systems would be rare. 3.5. 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.5.1. Resource The resource section has objects to manage resource usage by wildcarded delta expressions, a potential major consumer of CPU and memory. 3.5.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, Expires 4 August 2000 [Page 8] Internet Draft Distributed Management Expression MIB 4 February 2000 sample type, discontinuity indicator, and such. 3.5.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 the object identifier that filled in a wildcard. 3.6. Examples The examples refer to tables and objects defined below in the MIB itself. They may well make more sense after reading those definitions. 3.6.1. Wildcarding 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: Expires 4 August 2000 [Page 9] Internet Draft Distributed Management Expression MIB 4 February 2000 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 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 managed system 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. Expires 4 August 2000 [Page 10] Internet Draft Distributed Management Expression MIB 4 February 2000 3.6.2. Calculation and Conditional The following formula for line utilization of a half-duplex link is adapted from [PracPersp]. utilization = (ifInOctets + ifOutOctets) * 800 / seconds / ifSpeed The expression results in the percentage line utilization per second. The total octets are multipled by 8 to get bits and 100 to scale up the percentage as an integer. The following Expression MIB object values implement this as an expression for all ifIndexes that directly represent actual hardware. Since the octet counters are Counter32 values, they must be delta sampled to be meaningful. The sample period is 6 seconds but for accuracy and independence is calculated as a delta of sysUpTime. The expObjectTable entry for ifInOctets has an expObjectConditional that checks for being a hardware interface. Only one object in the expression needs that check associated, since it applies to the whole expression. Since ifConnectorPresent is a TruthValue with values of 1 or 2 rather than 0 and non-zero, it must also be in an expression rather than used directly for the conditional. The interface-specific discontinuity indicator is supplied only for ifInOctets since invalidating that sample will invalidate an attempt at evaluation, effectively invalidating ifOutOctets as well (correctly, because it has the same indicator). For notational clarity, in the rest of this document, a string in quotes as part of the object instance indicates the value that would actually be one subidentifier per byte. The objects all belong to owner "me". Also for clarity OIDs are expressed as the object descriptor and instance. In fact they must be supplied numerically, with all subidentifiers in place before the part for the particular object and instance. What the user must set in expExpressionTable: expExpression.2."me".4."hard" = "$1==1" expExpressionValueType.2."me".4."hard" = unsigned32 expExpressionRowStatus.2."me"4."hard" = 'active' expExpression.2."me".4."util" = "($1+$2)*800/$4/$3" Expires 4 August 2000 [Page 11] Internet Draft Distributed Management Expression MIB 4 February 2000 expExpressionValueType.2."me".4."util" = integer32 expExpressionDeltaInterval.2."me".4."util" = 6 expExpressionRowStatus.2."me"4."util" = 'active' What the user must set in expObjectTable: expObjectID.2."me".4."hard".1 = ifConnectorPresent expObjectWildcard.2."me".4."hard".1 = 'true' expObjectSampleType.2."me".4."hard".1 = 'absoluteValue' expObjectRowStatus.2."me".4."hard".1 = 'active' expObjectID.2."me".4."util".1 = ifInOctets expObjectWildcard.2."me".4."util".1 = 'true' expObjectSampleType.2."me".4."util".1 = 'deltaValue' expObjectConditional.2."me".4."util".1 = expValueUnsigned32Val.4."hard".0.0 expObjectConditionalWildcard.2."me".4."util".1 = 'true' expObjectDiscontinuityID.2."me".4."util".1 = ifCounterDiscontinuityTime expObjectDiscontinuityIDWildcard.2."me".4."util".1 = 'true' expObjectRowStatus.2."me".4."util".1 = 'active' expObjectID.2."me".4."util".2 = ifOutOctets expObjectWildcard.2."me".4."util".2 = 'true' expObjectSampleType.2."me".4."util".2 = 'deltaValue' expObjectRowStatus.2."me".4."util".2 = 'active' expObjectID.2."me".4."util".3 = ifSpeed expObjectWildcard.2."me".4."util".3 = 'true' expObjectSampleType.2."me".4."util".3 = 'absoluteValue' expObjectRowStatus.2."me".4."util".3 = 'active' expObjectID.2."me".4."util".4 = sysUpTime.0 expObjectWildcard.2."me".4."util".4 = 'false' expObjectSampleType.2."me".4."util".4 = 'deltaValue' expObjectRowStatus.2."me".4."util".4 = 'active' These settings will result in populating one column of expValueTable: expValueInteger32Val.2."me".4."util".0.0.? The subidentifier represented by "?" above represents one subidentifier that takes on a value of ifIndex and identifies a row for each ifIndex value where ifConnectorPresent is 'true' and the interface was present for two samples to provide a delta. Expires 4 August 2000 [Page 12] Internet Draft Distributed Management Expression MIB 4 February 2000 This value could in turn be used as an event threshold [RFCEventMIB] to watch for overutilization of all hardware network connections. Expires 4 August 2000 [Page 13] Internet Draft Distributed Management Expression MIB 4 February 2000 4. Definitions DISMAN-EXPRESSION-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Gauge32, Unsigned32, Counter32, Counter64, IpAddress, TimeTicks, mib-2 FROM SNMPv2-SMI RowStatus, TruthValue, TimeStamp FROM SNMPv2-TC sysUpTime FROM SNMPv2-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; dismanExpressionMIB MODULE-IDENTITY LAST-UPDATED "9910220000Z" ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 527 2446 Email: ramk@cisco.com" DESCRIPTION "The MIB module for defining expressions of MIB objects for management purposes." -- Revision History REVISION "9910220000Z" -- 22 October 1999 DESCRIPTION "This is the initial version of this MIB. Published as RFC xxxxx" ::= { mib-2 xx } -- final assignment by IANA at publication time dismanExpressionMIBObjects OBJECT IDENTIFIER ::= { dismanExpressionMIB 1 } expResource OBJECT IDENTIFIER ::= { dismanExpressionMIBObjects 1 } expDefine OBJECT IDENTIFIER ::= { dismanExpressionMIBObjects 2 } expValue OBJECT IDENTIFIER ::= { dismanExpressionMIBObjects 3 } -- -- Resource Control -- Expires 4 August 2000 [Page 14] Internet Draft Distributed Management Expression MIB 4 February 2000 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. For larger delta sampling intervals the system samples less often and suffers less overhead. This object provides a way to enforce such lower overhead for all expressions created after it is set. The value -1 indicates that expResourceDeltaMinimum is irrelevant as the system will not accept 'deltaValue' as a value for expObjectSampleType. Unless explicitly resource limited, a system's value for this object should be 1, allowing as small as a 1 second interval for ongoing delta sampling. Changing this value will not invalidate an existing setting of expObjectSampleType." ::= { expResource 1 } expResourceDeltaWildcardInstanceMaximum OBJECT-TYPE SYNTAX Unsigned32 UNITS "instances" MAX-ACCESS read-write STATUS current DESCRIPTION "For every instance of a deltaValue object, one dynamic instance entry is needed for holding the instance value from the previous sample, i.e. to maintain state. This object limits maximum number of dynamic instance entries this system will support for wildcarded delta objects in expressions. For a given delta expression, the number of dynamic 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. Expires 4 August 2000 [Page 15] Internet Draft Distributed Management Expression MIB 4 February 2000 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. An attempt to allocate beyond the limit results in expErrorCode being tooManyWildcardValues for that evaluation attempt." ::= { 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 managed 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 } -- Expires 4 August 2000 [Page 16] Internet Draft Distributed Management Expression MIB 4 February 2000 -- 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 expExpressionRowStatus. 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 and expErrorTable. 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. These security credentials are the parameters necessary as inputs to isAccessAllowed from the Architecture for Expires 4 August 2000 [Page 17] Internet Draft Distributed Management Expression MIB 4 February 2000 Describing SNMP Management Frameworks. When obtaining the objects that make up the expression, the system must (conceptually) use isAccessAllowed to ensure that it does not violate security. The evaluation of the 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 { expExpressionOwner, expExpressionName } ::= { expExpressionTable 1 } ExpExpressionEntry ::= SEQUENCE { expExpressionOwner SnmpAdminString, expExpressionName SnmpAdminString, expExpression OCTET STRING, expExpressionValueType INTEGER, expExpressionComment SnmpAdminString, expExpressionDeltaInterval Integer32, expExpressionPrefix OBJECT IDENTIFIER, expExpressionErrors Counter32, expExpressionEntryStatus RowStatus } expExpressionOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The owner of this entry. The exact semantics of this string are subject to the security policy defined by the security administrator." ::= { expExpressionEntry 1 } expExpressionName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the expression. This is locally unique, within the scope of an expExpressionOwner." ::= { expExpressionEntry 2 } expExpression OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..1024)) Expires 4 August 2000 [Page 18] Internet Draft Distributed Management Expression MIB 4 February 2000 MAX-ACCESS read-create 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 must not be recursive, that is although an expression may use the results of another expression, it must not contain any variable that is directly or indirectly a result of its own evaluation. The managed system must check for recursive expressions. 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 string oid The default type for a positive integer is int unless it is too Expires 4 August 2000 [Page 19] Internet Draft Distributed Management Expression MIB 4 February 2000 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 No additional leading or trailing subidentifiers are automatically added to an OID constant. The constant is taken as expressed. 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 one-dimensioned 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 operator: Expires 4 August 2000 [Page 20] Internet Draft Distributed Management Expression MIB 4 February 2000 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 >= work with TimeTicks. The operators &, |, and ^ work with IpAddress. The operators << and >> 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 systems do not have this information. Expires 4 August 2000 [Page 21] Internet Draft Distributed Management Expression MIB 4 February 2000 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 average maximum minimum sum exists The following function definitions indicate their parameters 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 (one-dimensioned) 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 Expires 4 August 2000 [Page 22] Internet Draft Distributed Management Expression MIB 4 February 2000 and returns the one-dimensioned arrayindex where the match began. A return value of 0 indicates no match (i.e. boolean false). oidBegins/Ends/Contains(oid, oid) - looks for the second OID (which can be an OID constant) in the first and returns the the one-dimensioned index where the match began. A return value of 0 indicates no match (i.e. boolean false). average/maximum/minimum(integer) - calculates the average, minimum, or maximum value of the integer valued object over multiple sample times. If the object disappears for any sample period, the accumlation and the resulting value object cease to exist until the object reappears at which point the calculation starts over. sum(integerObject*) - sums all available 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 3 } expExpressionValueType OBJECT-TYPE SYNTAX INTEGER { counter32(1), unsigned32(2), timeTicks(3), integer32(4), ipAddress(5), octetString(6), objectId(7), counter64(8) } MAX-ACCESS read-create 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 4 } expExpressionComment OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current Expires 4 August 2000 [Page 23] Internet Draft Distributed Management Expression MIB 4 February 2000 DESCRIPTION "A comment to explain the use or meaning of the expression." DEFVAL { ''H } ::= { expExpressionEntry 5 } expExpressionDeltaInterval OBJECT-TYPE SYNTAX Integer32 (0..86400) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Sampling interval for objects in this expression with expObjectSampleType 'deltaValue'. This object 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. So, for example, to avoid the higher level getting the same sample twice, the lower level should sample at least twice as fast as the higher Expires 4 August 2000 [Page 24] Internet Draft Distributed Management Expression MIB 4 February 2000 level does." DEFVAL { 0 } ::= { expExpressionEntry 6 } 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 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 7 } 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. An example of an inaccessible object is when the object is excluded from the view of the user whose security credentials are used in the expression evaluation. In such cases, it is a legitimate condition that causes the corresponding expression value not to be instantiated." ::= { expExpressionEntry 8 } Expires 4 August 2000 [Page 25] Internet Draft Distributed Management Expression MIB 4 February 2000 expExpressionEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation and deletion of entries." ::= { expExpressionEntry 9 } -- -- Expression Error Table -- expErrorTable OBJECT-TYPE SYNTAX SEQUENCE OF ExpErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of expression errors." ::= { expDefine 2 } expErrorEntry OBJECT-TYPE SYNTAX ExpErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about errors in processing an expression. Entries appear in this table only when there is a matching expExpressionEntry and then only when there has been an error for that expression as reflected by the error codes defined for expErrorCode." INDEX { expExpressionOwner, expExpressionName } ::= { expErrorTable 1 } ExpErrorEntry ::= SEQUENCE { expErrorTime TimeStamp, expErrorIndex Integer32, expErrorCode INTEGER, expErrorInstance OBJECT IDENTIFIER } expErrorTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only Expires 4 August 2000 [Page 26] Internet Draft Distributed Management Expression MIB 4 February 2000 STATUS current DESCRIPTION "The value of sysUpTime the last time an error caused a failure to evaluate this expression." ::= { expErrorEntry 1 } expErrorIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The one-dimensioned character array index into expExpression for where the error occurred. The value zero indicates irrelevance." ::= { expErrorEntry 2 } expErrorCode 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) Expires 4 August 2000 [Page 27] Internet Draft Distributed Management Expression MIB 4 February 2000 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 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 evaluation for a Get* operation return the SNMP error code 'genErr' except for 'tooManyWildcardValues' and 'resourceUnavailable' which return the SNMP error code 'resourceUnavailable'." ::= { expErrorEntry 3 } expErrorInstance 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." ::= { expErrorEntry 4 } Expires 4 August 2000 [Page 28] Internet Draft Distributed Management Expression MIB 4 February 2000 -- -- 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 3 } expObjectEntry OBJECT-TYPE SYNTAX ExpObjectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about an object. An application uses expObjectEntryStatus 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 { expExpressionOwner, expExpressionName, expObjectIndex } ::= { expObjectTable 1 } ExpObjectEntry ::= SEQUENCE { expObjectIndex Unsigned32, expObjectID OBJECT IDENTIFIER, expObjectIDWildcard TruthValue, expObjectSampleType INTEGER, expObjectDeltaDiscontinuityID OBJECT IDENTIFIER, expObjectDiscontinuityIDWildcard TruthValue, Expires 4 August 2000 [Page 29] Internet Draft Distributed Management Expression MIB 4 February 2000 expObjectDiscontinuityIDType INTEGER, expObjectConditional OBJECT IDENTIFIER, expObjectConditionalWildcard TruthValue, expObjectEntryStatus 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 } 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, Expires 4 August 2000 [Page 30] Internet Draft Distributed Management Expression MIB 4 February 2000 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 } sysUpTimeInstance OBJECT IDENTIFIER ::= { sysUpTime 0 } expObjectDeltaDiscontinuityID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION Expires 4 August 2000 [Page 31] Internet Draft Distributed Management Expression MIB 4 February 2000 "The OBJECT IDENTIFIER (OID) of a TimeTicks, TimeStamp, or DateAndTime object that indicates a discontinuity in the value at expObjectID. This object is instantiated only if expObjectSampleType is 'deltaValue' or 'changedValue'. 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 { sysUpTimeInstance } ::= { 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 instantiated only if expObjectSampleType is 'deltaValue' or 'changedValue'. NOTE: The simplest implementations of this MIB may not allow wildcards." DEFVAL { false } ::= { expObjectEntry 6 } expObjectDiscontinuityIDType OBJECT-TYPE SYNTAX INTEGER { timeTicks(1), timeStamp(2), dateAndTime(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value 'timeTicks' indicates the expObjectDeltaDiscontinuityID of this row is of syntax TimeTicks. The value 'timeStamp' indicates syntax TimeStamp. The value 'dateAndTime indicates syntax Expires 4 August 2000 [Page 32] Internet Draft Distributed Management Expression MIB 4 February 2000 DateAndTime. This object is instantiated only if expObjectSampleType is 'deltaValue' or 'changedValue'." DEFVAL { timeTicks } ::= { expObjectEntry 7 } zeroDotZero OBJECT IDENTIFIER ::= { 0 0 } 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 Expires 4 August 2000 [Page 33] Internet Draft Distributed Management Expression MIB 4 February 2000 "A true value indicates the expObjectConditional of this row is a wildcard object. False indicates that expObjectConditional is fully instanced. NOTE: The simplest implementations of this MIB may not allow wildcards." DEFVAL { false } ::= { expObjectEntry 9 } expObjectEntryStatus 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 expObjectEntryStatus 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' or 'changedValue', reading a value from the table causes the evaluation of the expression for that value. For those that contain a 'deltaValue' or 'changedValue' the value read is as of the last sampling Expires 4 August 2000 [Page 34] Internet Draft Distributed Management Expression MIB 4 February 2000 interval. 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, when creating a new row in this table, the managed system must record the security credentials of the requester. These security credentials are the parameters necessary as inputs to isAccessAllowed from [RFC2571]. When obtaining the objects that make up the expression, the system must (conceptually) use isAccessAllowed to ensure that it does not violate security. The evaluation of that expression takes place under the security credentials of the creator of its expExpressionEntry. To maintain security of MIB information, expression evaluation must take place using security credentials for the implied Gets of the objects in the expression as inputs (conceptually) to isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. These are the security credentials of the creator of the corresponding expExpressionEntry." INDEX { expExpressionOwner, 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 Expires 4 August 2000 [Page 35] Internet Draft Distributed Management Expression MIB 4 February 2000 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, 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 'unsigned32'." ::= { expValueEntry 3 } expValueTimeTicksVal OBJECT-TYPE SYNTAX TimeTicks 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'." Expires 4 August 2000 [Page 36] Internet Draft Distributed Management Expression MIB 4 February 2000 ::= { 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)) 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 -- dismanExpressionMIBConformance OBJECT IDENTIFIER ::= { dismanExpressionMIB 3 } dismanExpressionMIBCompliances OBJECT IDENTIFIER ::= { dismanExpressionMIBConformance 1 } dismanExpressionMIBGroups OBJECT IDENTIFIER ::= { dismanExpressionMIBConformance 2 } -- Compliance Expires 4 August 2000 [Page 37] Internet Draft Distributed Management Expression MIB 4 February 2000 dismanExpressionMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Expression MIB." MODULE -- this module MANDATORY-GROUPS { dismanExpressionResourceGroup, dismanExpressionDefinitionGroup, dismanExpressionValueGroup } OBJECT expResourceDeltaMinimum 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 disallow deltas calculation or change detection." OBJECT expObjectIDWildcard WRITE-SYNTAX INTEGER { false(2) } DESCRIPTION "Implementation may allow wildcards." OBJECT expObjectDiscontinuityIDWildcard WRITE-SYNTAX INTEGER { false(2) } DESCRIPTION "Implementation need not allow wildcards." OBJECT expObjectConditionalWildcard WRITE-SYNTAX INTEGER { false(2) } DESCRIPTION "Implementation need not allow deltas wildcards." ::= { dismanExpressionMIBCompliances 1 } -- Units of Conformance dismanExpressionResourceGroup OBJECT-GROUP OBJECTS { Expires 4 August 2000 [Page 38] Internet Draft Distributed Management Expression MIB 4 February 2000 expResourceDeltaMinimum, expResourceDeltaWildcardInstanceMaximum, expResourceDeltaWildcardInstances, expResourceDeltaWildcardInstancesHigh, expResourceDeltaWildcardInstanceResourceLacks } STATUS current DESCRIPTION "Expression definition resource management." ::= { dismanExpressionMIBGroups 1 } dismanExpressionDefinitionGroup OBJECT-GROUP OBJECTS { expExpression, expExpressionValueType, expExpressionComment, expExpressionDeltaInterval, expExpressionPrefix, expExpressionErrors, expExpressionEntryStatus, expErrorTime, expErrorIndex, expErrorCode, expErrorInstance, expObjectID, expObjectIDWildcard, expObjectSampleType, expObjectDeltaDiscontinuityID, expObjectDiscontinuityIDWildcard, expObjectDiscontinuityIDType, expObjectConditional, expObjectConditionalWildcard, expObjectEntryStatus } STATUS current DESCRIPTION "Expression definition." ::= { dismanExpressionMIBGroups 2 } dismanExpressionValueGroup OBJECT-GROUP OBJECTS { expValueCounter32Val, expValueUnsigned32Val, Expires 4 August 2000 [Page 39] Internet Draft Distributed Management Expression MIB 4 February 2000 expValueTimeTicksVal, expValueInteger32Val, expValueIpAddressVal, expValueOctetStringVal, expValueOidVal, expValueCounter64Val } STATUS current DESCRIPTION "Expression value." ::= { dismanExpressionMIBGroups 3 } END Expires 4 August 2000 [Page 40] Internet Draft Distributed Management Expression MIB 4 February 2000 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Expires 4 August 2000 [Page 41] Internet Draft Distributed Management Expression MIB 4 February 2000 6. 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 4 August 2000 [Page 42] Internet Draft Distributed Management Expression MIB 4 February 2000 7. References [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Expires 4 August 2000 [Page 43] Internet Draft Distributed Management Expression MIB 4 February 2000 Protocol (SNMPv3)", RFC 2574, April 1999 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999 [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and version 2 of the Internet-standard Network Management Framework", RFC 1903, January 1996. [RFCEventMIB] Stewart, B., "Event MIB", RFC ????, ?Month? 1999. [PracPersp] Leinwand, A. and K. Fang, "Network Management: A Practical Perspective", Addison-Wesley Publishing Company, Inc., 1993. Expires 4 August 2000 [Page 44] Internet Draft Distributed Management Expression MIB 4 February 2000 8. Security Considerations Expression MIB security involves two perspectives: protection of expressions from tampering or unauthorized use of resources, and protection of the objects used to calculate the expressions. Security of expression definitions and results depends on the expression owner (expExpressionOwner). With view-based access control [RFC2575] a network manager can control who has what level of access to what expressions. Access control for the objects within the expression depends on the security credentials of the expression creator. These are the security credentials used to get the objects necessary to evaluate the expression. They are the security credentials that were used to set the expExpressionRowStatus object for that expression to 'active', as recorded by the managed system. This means that the results of an expression could potentially be made available to someone who does not have access to the raw data that went into them. This could be either legitimate or a security violation, depending on the specific situation and security policy. To facilitate the provisioning of access control by a security administrator for this MIB itself using the View-Based Access Control Model (VACM) defined in RFC 2575 [RFC2575] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index". Such an initial index has a syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. All entries in related tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the "column" subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. More elaborate configurations are possible. Expires 4 August 2000 [Page 45] Internet Draft Distributed Management Expression MIB 4 February 2000 9. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. 10. Editor's Address Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Phone: +1 408 527 2446 Email: ramk@cisco.com Expires 4 August 2000 [Page 46] Internet Draft Distributed Management Expression MIB 4 February 2000 11. Full Copyright Statement Copyright (C) The Internet Society (1999). 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 4 August 2000 [Page 47] Internet Draft Distributed Management Expression MIB 4 February 2000 Table of Contents 1 Abstract ........................................................ 2 2 The SNMP Management Framework ................................... 2 3 Overview ........................................................ 4 3.1 Usage ......................................................... 4 3.2 Persistance ................................................... 5 3.3 Operation ..................................................... 5 3.3.1 Sampling .................................................... 5 3.3.2 Wildcards ................................................... 6 3.3.3 Evaluation .................................................. 6 3.3.4 Value Identification ........................................ 7 3.4 Subsets ....................................................... 7 3.4.1 No Wildcards ................................................ 7 3.4.2 No Deltas ................................................... 8 3.5 Structure ..................................................... 8 3.5.1 Resource .................................................... 8 3.5.2 Definition .................................................. 8 3.5.3 Value ....................................................... 9 3.6 Examples ...................................................... 9 3.6.1 Wildcarding ................................................. 9 3.6.2 Calculation and Conditional ................................. 11 4 Definitions ..................................................... 14 5 Intellectual Property ........................................... 41 6 Acknowledgements ................................................ 42 7 References ...................................................... 43 8 Security Considerations ......................................... 45 9 Author's Address ................................................ 46 10 Editor's Address ............................................... 46 11 Full Copyright Statement ....................................... 47 Expires 4 August 2000 [Page 48] From owner-disman@dorothy.peer.com Fri Feb 4 21:28:52 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15472 for ; Fri, 4 Feb 2000 21:28:51 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id UAA19650; Fri, 4 Feb 2000 20:28:16 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA27294 for disman-list; Fri, 4 Feb 2000 18:24:29 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id SAA27287 for ; Fri, 4 Feb 2000 18:24:08 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id UAA19274 for ; Fri, 4 Feb 2000 20:24:19 -0600 (CST) Received: (ramk@localhost) by itech-view2.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id SAA21135; Fri, 4 Feb 2000 18:23:41 -0800 (PST) From: Ram Kavasseri Message-Id: <200002050223.SAA21135@itech-view2.cisco.com> Subject: draft-ietf-disman-notif-log-mib-15.txt To: internet-drafts@ietf.org Date: Fri, 4 Feb 2000 18:23:41 -0800 (PST) Cc: disman@dorothy.peer.com X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Please accept draft-ietf-disman-notif-log-mib-15.txt for posting as an internet draft. It contains the following changes: 1. Edits to the DESCRIPTION of nlmConfigGlobalEntryLimit and nlmLogContextEngineID. 2. updates to the REVISION clause of the MIB. Thank you, Ram Kavasseri Internet Draft Notification Log MIB 4 February 2000 Notification Log MIB 4 February 2000 draft-ietf-disman-notif-log-mib-15.txt Bob Stewart Cisco Systems, Inc. Ramanathan R. Kavasseri Cisco Systems, Inc. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Please send comments to the Distributed Management Working Group, . Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Expires 4 August 2000 [Page 1] Internet Draft Notification Log MIB 4 February 2000 1. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging SNMP Notifications. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. Expires 4 August 2000 [Page 2] Internet Draft Notification Log MIB 4 February 2000 A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. 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 [RFC1905] 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 verify that they have not missed important Notifications. 3.1. Environment The overall environmental concerns for the MIB are: o SNMP Engines and Contexts o Security Expires 4 August 2000 [Page 3] Internet Draft Notification Log MIB 4 February 2000 3.1.1. SNMP Engines and Contexts There are two distinct information flows from multiple notification originators that one may log. The first is the notifications that are received (from one or more SNMP engines) for logging as SNMP informs and traps. The other comprises notifications delivered to an SNMP engine at the interface to the notification originator (using a notification mechanism other than SNMP informs or traps). The latter information flow (using a notification mechanism other than SNMP informs or traps) MUST be modeled as the SNMP engine (which maintains the log) sending a notification to itself. The remainder of this section discusses the handling of the former information flow - notifications (received in the form of SNMP informs or traps) from multiple SNMP engines. As described in the SNMP architecture [RFC2571], a given system may support multiple SNMP engines operating independently of one another, each with its own SNMP engine identification. Furthermore, within the purview 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. To provide the necessary source information for a logged Notification, the MIB includes objects to record that Notification's source SNMP engine ID and management context name. 3.1.2. Security Security for Notifications is awkward since access control for the objects in the Notification can be checked only where the Notification is created. Thus such checking is possible only for locally-generated Notifications, and even then only when security credentials are available. For the purpose of this discussion, "security credentials" means the input values for the abstract service interface function isAccessAllowed [RFC2571] and using those credentials means conceptually using that function to see that those credentials allow access to the MIB objects in question, operating as for a Notification Originator in [RFC2573]. The Notification Log MIB has the notion of a "named log." By using hierarchically structured log names and view-based access control [RFC2575] a network administrator can provide different access for different users. When an application creates a named log the security Expires 4 August 2000 [Page 4] Internet Draft Notification Log MIB 4 February 2000 credentials of the creator stay associated with that log. Hierarchically structured names encode groupings of names within the name string, starting from the left so that they work well with instance-level, view-based access control [RFC2575], for example: ops ops-admin ops-oper ops-oper-senior ops-oper-junior Network security managers designing such a naming policy SHOULD use punctuation (as in the example) to avoid the problem of a lower level name inadvertently running together with the next higher level name. A managed system with fewer resources MAY disallow the creation of named logs, providing only the default, null-named log. Such a log has no implicit security credentials for Notification object access control and Notifications are put into it with no further checking. When putting locally-generated Notifications into a named log, the managed system MUST use the security credentials associated with that log and MUST apply the same access control rules as described for a Notification Originator in [RFC2573]. The managed system SHOULD NOT apply access control when adding remotely- generated Notifications into either a named log or the default, null- named log. In those cases the security of the information in the log SHOULD be left to the normal, overall access control for the log itself. The Notification Log MIB allows applications to set the maximum number of Notifications that can be logged, using nlmConfigGlobalEntryLimit. Similarly, an application can set the maximum age using nlmConfigGlobalAgeOut, after which older Notifications MAY be timed out. Please be aware that contention between multiple applications trying to set these objects to different values MAY affect the reliability and completeness of data seen by each application, i.e. it is possible that one application may change the value of either of these objects, resulting in some Notifications being deleted before the other applications have had a chance to see them. This could be used to orchestrate a denial-of-service attack. Methods for countering such an attack are for further study. 3.2. Structure The MIB has the following sections: Expires 4 August 2000 [Page 5] Internet Draft Notification Log MIB 4 February 2000 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. This section also contains a table to specify what logs exist and how they operate. Deciding which Notifications are to be logged depends on filters defined in the the snmpNotifyFilterTable in the standard SNMP Notification MIB [RFC2573] identified by the initial index (snmpNotifyFilterName) from that table. 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 and resource problems. 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 4 August 2000 [Page 6] Internet Draft Notification Log MIB 4 February 2000 3.3. Example Following is an example configuration of a named log for logging only linkUp and linkDown Notifications. In nlmConfigLogTable: nlmConfigLogFilterName.5."links" = "link-status" nlmConfigLogEntryLimit.5."links" = 0 nlmConfigLogAdminStatus.5."links" = enabled nlmConfigLogOperStatus.5."links" = operational nlmConfigLogStorageType.5."links" = nonVolatile nlmConfigLogEntryStatus.5."links" = active Note that snmpTraps is: iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.5 Or numerically: 1.3.6.1.6.3.1.1.5 And linkDown is snmpTraps.3 and linkUp is snmpTraps.4. So to allow the two Notifications in snmpNotifyFilterTable: snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.3 = ''H snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.3 = include snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.3 = nonVolatile snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.3 = active snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.4 = ''H snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.4 = include snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.4 = nonVolatile snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.4 = active Expires 4 August 2000 [Page 7] Internet Draft Notification Log MIB 4 February 2000 4. Definitions NOTIFICATION-LOG-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, TimeTicks, Counter32, Counter64, IpAddress, Opaque, mib-2 FROM SNMPv2-SMI TimeStamp, DateAndTime, StorageType, RowStatus FROM SNMPv2-TC SnmpAdminString, SnmpEngineID FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; notificationLogMIB MODULE-IDENTITY LAST-UPDATED "200002040000Z" -- 4 February 2000 ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 527 2446 Email: ramk@cisco.com" DESCRIPTION "The MIB module for logging SNMP Notifications, that is, Traps and Informs." -- Revision History REVISION "200002040000Z" -- 4 February 2000 DESCRIPTION "Updated the DESCRIPTION of nlmConfigGlobalEntryLimit and nlmLogContextEngineID." REVISION "9910220000Z" -- 22 October 1999 DESCRIPTION "This is the initial version of this MIB. Published as RFC xxxxx" ::= { mib-2 xx } -- final assignment by IANA at publication time notificationLogMIBObjects OBJECT IDENTIFIER ::= { notificationLogMIB 1 } nlmConfig OBJECT IDENTIFIER ::= { notificationLogMIBObjects 1 } nlmStats OBJECT IDENTIFIER ::= { notificationLogMIBObjects 2 } nlmLog OBJECT IDENTIFIER ::= { notificationLogMIBObjects 3 } -- -- Configuration Section Expires 4 August 2000 [Page 8] Internet Draft Notification Log MIB 4 February 2000 -- nlmConfigGlobalEntryLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of notification entries that may be held in nlmLogTable for all nlmLogNames added together. A particular setting does not guarantee that much data can be held. If an application changes the limit while there are Notifications in the log, the oldest Notifications MUST be discarded to bring the log down to the new limit - thus the value of nlmConfigGlobalEntryLimit MUST take precedence over the values of nlmConfigGlobalAgeOut and nlmConfigLogEntryLimit, even if the Notification being discarded has been present for fewer minutes than the value of nlmConfigGlobalAgeOut, or if the named log has fewer entries than that specified in nlmConfigLogEntryLimit. A value of 0 means no limit. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { 0 } ::= { nlmConfig 1 } nlmConfigGlobalAgeOut OBJECT-TYPE SYNTAX Unsigned32 UNITS "minutes" MAX-ACCESS read-write STATUS current DESCRIPTION "The number of minutes a Notification SHOULD be kept in a log before it is automatically removed. If an application changes the value of nlmConfigGlobalAgeOut, Notifications older than the new time MAY be discarded to meet the new time. A value of 0 means no age out. Please be aware that contention between multiple managers Expires 4 August 2000 [Page 9] Internet Draft Notification Log MIB 4 February 2000 trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { 1440 } -- 24 hours ::= { nlmConfig 2 } -- -- Basic Log Configuration Table -- nlmConfigLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmConfigLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of logging control entries." ::= { nlmConfig 3 } nlmConfigLogEntry OBJECT-TYPE SYNTAX NlmConfigLogEntry MAX-ACCESS not-accessible STATUS current 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 nlmConfigLogEntryStatus." INDEX { nlmLogName } ::= { nlmConfigLogTable 1 } NlmConfigLogEntry ::= SEQUENCE { nlmLogName SnmpAdminString, nlmConfigLogFilterName SnmpAdminString, nlmConfigLogEntryLimit Unsigned32, nlmConfigLogAdminStatus INTEGER, nlmConfigLogOperStatus INTEGER, nlmConfigLogStorageType StorageType, nlmConfigLogEntryStatus RowStatus } nlmLogName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the log. Expires 4 August 2000 [Page 10] Internet Draft Notification Log MIB 4 February 2000 An implementation may allow multiple named logs, up to some implementation-specific limit (which may be none). A zero-length log name is reserved for creation and deletion by the managed system, and MUST be used as the default log name by systems that do not support named logs." ::= { nlmConfigLogEntry 1 } nlmConfigLogFilterName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "A value of snmpNotifyFilterProfileName as used as an index into the snmpNotifyFilterTable in the SNMP Notification MIB, specifying the locally or remotely originated Notifications to be filtered out and not logged in this log. A zero-length value or a name that does not identify an existing entry in snmpNotifyFilterTable indicate no Notifications are to be logged in this log." DEFVAL { ''H } ::= { nlmConfigLogEntry 2 } nlmConfigLogEntryLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of notification entries that can be held in nlmLogTable for this named log. A particular setting does not guarantee that that much data can be held. 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. A value of 0 indicates no limit. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { 0 } ::= { nlmConfigLogEntry 3 } nlmConfigLogAdminStatus OBJECT-TYPE Expires 4 August 2000 [Page 11] Internet Draft Notification Log MIB 4 February 2000 SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Control to enable or disable the log without otherwise disturbing the log's entry. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { enabled } ::= { nlmConfigLogEntry 4 } nlmConfigLogOperStatus OBJECT-TYPE SYNTAX INTEGER { disabled(1), operational(2), noFilter(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of this log: disabled administratively disabled operational administratively enabled and working noFilter administratively enabled but either nlmConfigLogFilterName is zero length or does not name an existing entry in snmpNotifyFilterTable" ::= { nlmConfigLogEntry 5 } nlmConfigLogStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type of this conceptual row." ::= { nlmConfigLogEntry 6 } nlmConfigLogEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Control for creating and deleting entries. Entries may be modified while active. Expires 4 August 2000 [Page 12] Internet Draft Notification Log MIB 4 February 2000 For non-null-named logs, the managed system records the security credentials from the request that sets nlmConfigLogStatus to 'active' and uses that identity to apply access control to the objects in the Notification to decide if that Notification may be logged." ::= { nlmConfigLogEntry 7 } -- -- Statistics Section -- nlmStatsGlobalNotificationsLogged OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Notifications put into the nlmLogTable. This counts a Notification once for each log entry, so a Notification put into multiple logs is counted multiple times." ::= { nlmStats 1 } nlmStatsGlobalNotificationsBumped OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of log entries discarded to make room for a new entry due to lack of resources or the value of nlmConfigGlobalEntryLimit or nlmConfigLogEntryLimit. This does not include entries discarded due to the value of nlmConfigGlobalAgeOut." ::= { nlmStats 2 } -- -- Log Statistics Table -- nlmStatsLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmStatsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Notification log statistics entries." ::= { nlmStats 3 } Expires 4 August 2000 [Page 13] Internet Draft Notification Log MIB 4 February 2000 nlmStatsLogEntry OBJECT-TYPE SYNTAX NlmStatsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log statistics entry." AUGMENTS { nlmConfigLogEntry } ::= { nlmStatsLogTable 1 } NlmStatsLogEntry ::= SEQUENCE { nlmStatsLogNotificationsLogged Counter32, nlmStatsLogNotificationsBumped Counter32 } nlmStatsLogNotificationsLogged OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Notifications put in this named log." ::= { nlmStatsLogEntry 1 } nlmStatsLogNotificationsBumped OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of log entries discarded from this named log to make room for a new entry due to lack of resources or the value of nlmConfigGlobalEntryLimit or nlmConfigLogEntryLimit. This does not include entries discarded due to the value of nlmConfigGlobalAgeOut." ::= { nlmStatsLogEntry 2 } -- -- Log Section -- -- -- Log Table -- Expires 4 August 2000 [Page 14] Internet Draft Notification Log MIB 4 February 2000 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. Note that keeping entries across initializations of the management system leads to some confusion with counters and TimeStamps, since both of those are based on sysUpTime, which resets on management initialization. In this situation, counters apply only after the reset and nlmLogTime for entries made before the reset SHOULD be set to 0." ::= { nlmLog 1 } nlmLogEntry OBJECT-TYPE SYNTAX NlmLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log entry. Entries appear in this table when Notifications occur and pass filtering by nlmConfigLogFilterName and access control. They are removed to make way for new entries due to lack of resources or the values of nlmConfigGlobalEntryLimit, nlmConfigGlobalAgeOut, or nlmConfigLogEntryLimit. If adding an entry would exceed nlmConfigGlobalEntryLimit or system resources in general, the oldest entry in any log SHOULD be removed to make room for the new one. If adding an entry would exceed nlmConfigLogEntryLimit the oldest entry in that log SHOULD be removed to make room for the new one. Before the managed system puts a locally-generated Notification into a non-null-named log it assures that the creator of the log has access to the information in the Notification. If not it does not log that Notification in that log." INDEX { nlmLogName, nlmLogIndex } ::= { nlmLogTable 1 } Expires 4 August 2000 [Page 15] Internet Draft Notification Log MIB 4 February 2000 NlmLogEntry ::= SEQUENCE { nlmLogIndex Unsigned32, nlmLogTime TimeStamp, nlmLogDateAndTime DateAndTime, nlmLogEngineID SnmpEngineID, nlmLogEngineAddress IpAddress, nlmLogContextEngineID SnmpEngineID, nlmLogContextName SnmpAdminString, 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 within the named log. When it reaches the maximum value, an extremely unlikely event, the agent wraps the value back to 1." ::= { nlmLogEntry 1 } nlmLogTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the entry was placed in the log. If the entry occurred before the most recent management system initialization this object value MUST be set to zero." ::= { nlmLogEntry 2 } nlmLogDateAndTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The local date and time when the entry was logged, instantiated only by systems that have date and time capability." ::= { nlmLogEntry 3 } nlmLogEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current Expires 4 August 2000 [Page 16] Internet Draft Notification Log MIB 4 February 2000 DESCRIPTION "The identification of the SNMP engine at which the Notification originated. If the log can contain Notifications from only one engine or the Trap is in SNMPv1 format, this object is not instantiated." ::= { nlmLogEntry 4 } nlmLogEngineAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP Address of the SNMP engine from which the Notification was received. This is used to identify the source of an SNMPv1 trap, since an nlmLogEngineId cannot be extracted from the SNMPv1 trap pdu. This object MUST always be instantiated, even if the log can contain Notifications from only one engine. Please be aware that the nlmLogEngineAddress may not uniquely identify the SNMP engine from which the Notification was received. For example, if an SNMP engine uses DHCP or NAT to obtain ip addresses, the address it uses may be shared with other network devices, and hence will not uniquely identify the SNMP engine." ::= { nlmLogEntry 5 } nlmLogContextEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current DESCRIPTION "The contextEngineID within an administrative domain (indicated by nlmEngineID) that uniquely identifies an SNMP entity that may realize an instance of a context with a particular contextName. If the Trap is from an SNMPv1 system, this object SHOULD NOT be instantiated." ::= { nlmLogEntry 6 } nlmLogContextName OBJECT-TYPE SYNTAX SnmpAdminString Expires 4 August 2000 [Page 17] Internet Draft Notification Log MIB 4 February 2000 MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the SNMP MIB context from which the Notification came. For SNMPv1 Traps this is the community string from the Trap. If the Notification's source SNMP engine is known not to support multiple contexts, this object MAY not be instantiated." ::= { nlmLogEntry 7 } nlmLogNotificationID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The NOTIFICATION-TYPE object identifer of the Notification that occurred." ::= { nlmLogEntry 8 } -- -- 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 } 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 { nlmLogName, nlmLogIndex, nlmLogVariableIndex } ::= { nlmLogVariableTable 1 } NlmLogVariableEntry ::= SEQUENCE { nlmLogVariableIndex Unsigned32, Expires 4 August 2000 [Page 18] Internet Draft Notification Log MIB 4 February 2000 nlmLogVariableID OBJECT IDENTIFIER, nlmLogVariableValueType INTEGER, nlmLogVariableCounter32Val Counter32, nlmLogVariableUnsigned32Val Unsigned32, nlmLogVariableTimeTicksVal TimeTicks, nlmLogVariableInteger32Val Integer32, nlmLogVariableOctetStringVal OCTET STRING, nlmLogVariableIpAddressVal IpAddress, nlmLogVariableOidVal OBJECT IDENTIFIER, nlmLogVariableCounter64Val Counter64, nlmLogVariableOpaqueVal Opaque } 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), unsigned32(2), timeTicks(3), integer32(4), ipAddress(5), octetString(6), objectId(7), counter64(8), opaque(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the value. One and only one of the value objects that follow must be instantiated, based on this type." ::= { nlmLogVariableEntry 3 } nlmLogVariableCounter32Val OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Expires 4 August 2000 [Page 19] Internet Draft Notification Log MIB 4 February 2000 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 'unsigned32'." ::= { 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 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 } Expires 4 August 2000 [Page 20] Internet Draft Notification Log MIB 4 February 2000 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 } nlmLogVariableOpaqueVal OBJECT-TYPE SYNTAX Opaque MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'opaque'." ::= { nlmLogVariableEntry 12 } -- -- 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 MANDATORY-GROUPS { Expires 4 August 2000 [Page 21] Internet Draft Notification Log MIB 4 February 2000 notificationLogConfigGroup, notificationLogStatsGroup, notificationLogLogGroup } OBJECT nlmConfigGlobalEntryLimit SYNTAX Unsigned32 (0..4294967295) MIN-ACCESS read-only DESCRIPTION "Implementations may choose a limit and not allow it to be changed or may enforce an upper or lower bound on the limit." OBJECT nlmConfigLogEntryLimit SYNTAX Unsigned32 (0..4294967295) MIN-ACCESS read-only DESCRIPTION "Implementations may choose a limit and not allow it to be changed or may enforce an upper or lower bound on the limit." OBJECT nlmConfigLogEntryStatus MIN-ACCESS read-only DESCRIPTION "Implementations may disallow the creation of named logs." GROUP notificationLogDateGroup DESCRIPTION "This group is mandatory on systems that keep wall clock date and time and should not be implemented on systems that do not have a wall clock date." ::= { notificationLogMIBCompliances 1 } -- Units of Conformance notificationLogConfigGroup OBJECT-GROUP OBJECTS { nlmConfigGlobalEntryLimit, nlmConfigGlobalAgeOut, nlmConfigLogFilterName, nlmConfigLogEntryLimit, nlmConfigLogAdminStatus, nlmConfigLogOperStatus, nlmConfigLogStorageType, Expires 4 August 2000 [Page 22] Internet Draft Notification Log MIB 4 February 2000 nlmConfigLogEntryStatus } STATUS current DESCRIPTION "Notification log configuration management." ::= { notificationLogMIBGroups 1 } notificationLogStatsGroup OBJECT-GROUP OBJECTS { nlmStatsGlobalNotificationsLogged, nlmStatsGlobalNotificationsBumped, nlmStatsLogNotificationsLogged, nlmStatsLogNotificationsBumped } STATUS current DESCRIPTION "Notification log statistics." ::= { notificationLogMIBGroups 2 } notificationLogLogGroup OBJECT-GROUP OBJECTS { nlmLogTime, nlmLogEngineID, nlmLogEngineAddress, nlmLogContextEngineID, nlmLogContextName, nlmLogNotificationID, nlmLogVariableID, nlmLogVariableValueType, nlmLogVariableCounter32Val, nlmLogVariableUnsigned32Val, nlmLogVariableTimeTicksVal, nlmLogVariableInteger32Val, nlmLogVariableOctetStringVal, nlmLogVariableIpAddressVal, nlmLogVariableOidVal, nlmLogVariableCounter64Val, nlmLogVariableOpaqueVal } STATUS current DESCRIPTION "Notification log data." ::= { notificationLogMIBGroups 3 } Expires 4 August 2000 [Page 23] Internet Draft Notification Log MIB 4 February 2000 notificationLogDateGroup OBJECT-GROUP OBJECTS { nlmLogDateAndTime } STATUS current DESCRIPTION "Conditionally mandatory notification log data." ::= { notificationLogMIBGroups 4 } END Expires 4 August 2000 [Page 24] Internet Draft Notification Log MIB 4 February 2000 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Expires 4 August 2000 [Page 25] Internet Draft Notification Log MIB 4 February 2000 6. References [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Expires 4 August 2000 [Page 26] Internet Draft Notification Log MIB 4 February 2000 Protocol (SNMPv3)", RFC 2574, April 1999 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999 [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and version 2 of the Internet-standard Network Management Framework", RFC 1903, January 1996. Expires 4 August 2000 [Page 27] Internet Draft Notification Log MIB 4 February 2000 7. Security Considerations Security issues are discussed in Section 3.1.2. 8. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Phone: +1 408 527 2446 Email: ramk@cisco.com Expires 4 August 2000 [Page 28] Internet Draft Notification Log MIB 4 February 2000 9. Full Copyright Statement Copyright (C) The Internet Society (1999). 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 4 August 2000 [Page 29] Internet Draft Notification Log MIB 4 February 2000 Table of Contents 1 Abstract ........................................................ 2 2 The SNMP Management Framework ................................... 2 3 Overview ........................................................ 3 3.1 Environment ................................................... 3 3.1.1 SNMP Engines and Contexts ................................... 4 3.1.2 Security .................................................... 4 3.2 Structure ..................................................... 5 3.2.1 Configuration ............................................... 6 3.2.2 Statistics .................................................. 6 3.2.3 Log ......................................................... 6 3.3 Example ....................................................... 7 4 Definitions ..................................................... 8 5 Intellectual Property ........................................... 25 6 References ...................................................... 26 7 Security Considerations ......................................... 28 8 Author's Address ................................................ 28 9 Full Copyright Statement ........................................ 29 Expires 4 August 2000 [Page 30] From owner-disman@dorothy.peer.com Sat Feb 5 10:33:57 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05507 for ; Sat, 5 Feb 2000 10:33:57 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA19399; Sat, 5 Feb 2000 09:33:32 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA28626 for disman-list; Sat, 5 Feb 2000 07:31:32 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA28621 for ; Sat, 5 Feb 2000 07:31:27 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id JAA19308 for ; Sat, 5 Feb 2000 09:31:55 -0600 (CST) Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) by smtprtp1.ntcom.nortel.net; Sat, 5 Feb 2000 10:31:11 -0500 Received: from zsc4c012.corpwest.baynetworks.com ([134.177.2.159]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 1DZBL030; Sat, 5 Feb 2000 07:31:10 -0800 Received: from dlevi-pc3.corpwest.baynetworks.com (bne-5399ppp-51.corpeast.baynetworks.com [132.245.112.51]) by zsc4c012.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 11AP88NV; Sat, 5 Feb 2000 07:31:09 -0800 Message-Id: <3.0.32.20000205102345.00827504@ZSC4C012.corpwest.baynetworks.com> X-Sender: dlevi@ZSC4C012.corpwest.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 05 Feb 2000 10:23:47 -0800 To: disman@dorothy.peer.com From: "David Levi" Subject: Re: FW: Non-member submission from [Thippanna Hongal ] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list At 01:13 PM 1/31/2000 +0100, you wrote: > > > >I think we need to define a common way to deal with this situation. >The intention of the text currently in RFC 2591 is that all events >that fire during non existant time are processed. If we keep that >position and your implementation does not behave this way, then it is >not conforming to the RFC. > >So the real question here is whether the behaviour described in RFC >2591 should be changed or not. Any opinions? I think making this user-configurable is a good approach, perhaps by adding a mib object to the schedTable to control the behaviour for each row. > >hongal> At this time I would like to add another implementation >hongal> feature. > >hongal> If a schedule fails to do its intended operation for certain >hongal> number of time then schedOperStatus is set to DISABLED. While >hongal> considering the number of times , I consider the interval >hongal> between the schedules too. > >This may be a useful addition. Any comments from the WG? Is there >interest to add such a capability? Any suggestions for a concrete >definition? I also think this is a good idea. -Dave ----------------------------------------------------------------------------- David B. Levi Nortel Networks dlevi@nortelnetworks.com Voice: +1 865 686 0432 Fax: +1 865 686 0433 Voice Mail: +1 408 495 3622 ----------------------------------------------------------------------------- From owner-disman@dorothy.peer.com Tue Feb 8 06:37:58 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13803 for ; Tue, 8 Feb 2000 06:37:58 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id FAA22635; Tue, 8 Feb 2000 05:37:38 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id DAA22425 for disman-list; Tue, 8 Feb 2000 03:30:57 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA22414 for ; Tue, 8 Feb 2000 03:30:51 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id FAA21927 for ; Tue, 8 Feb 2000 05:31:21 -0600 (CST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13511; Tue, 8 Feb 2000 06:31:17 -0500 (EST) Message-Id: <200002081131.GAA13511@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@dorothy.peer.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-express-mib-11.txt Date: Tue, 08 Feb 2000 06:31:17 -0500 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Distributed Management Expression MIB Author(s) : B. Stewart, R. Kavasseri Filename : draft-ietf-disman-express-mib-11.txt Pages : 48 Date : 07-Feb-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing expressions of MIB objects. The results of these expressions become MIB objects usable like any other MIB object, such as for the test condition for declaring an event. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-express-mib-11.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-express-mib-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-express-mib-11.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: <20000207125445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-express-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-express-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000207125445.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-disman@dorothy.peer.com Tue Feb 8 06:38:06 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13804 for ; Tue, 8 Feb 2000 06:37:58 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id FAA22632; Tue, 8 Feb 2000 05:37:37 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id DAA22426 for disman-list; Tue, 8 Feb 2000 03:30:58 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA22420 for ; Tue, 8 Feb 2000 03:30:53 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id FAA21945 for ; Tue, 8 Feb 2000 05:31:24 -0600 (CST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13525; Tue, 8 Feb 2000 06:31:22 -0500 (EST) Message-Id: <200002081131.GAA13525@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@dorothy.peer.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-notif-log-mib-15.txt Date: Tue, 08 Feb 2000 06:31:21 -0500 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Notification Log MIB Author(s) : B. Stewart, R. Kavasseri Filename : draft-ietf-disman-notif-log-mib-15.txt Pages : 30 Date : 07-Feb-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging SNMP Notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-notif-log-mib-15.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-notif-log-mib-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-notif-log-mib-15.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: <20000207125459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-notif-log-mib-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-notif-log-mib-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000207125459.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-disman@dorothy.peer.com Thu Feb 10 07:06:50 2000 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19307 for ; Thu, 10 Feb 2000 07:06:39 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id GAA00252; Thu, 10 Feb 2000 06:05:32 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA24679 for disman-list; Thu, 10 Feb 2000 04:00:32 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA24674 for ; Thu, 10 Feb 2000 04:00:26 -0800 (PST) From: Internet-Drafts@ietf.org Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id GAA29284 for ; Thu, 10 Feb 2000 06:00:58 -0600 (CST) Received: from hermes2.fty.cstelecom.com (hermes2.cstelecom.cie-signaux.fr [172.17.68.52]) by oass09.cstelecom.cie-signaux.fr with ESMTP id MAA29243 for ; Thu, 10 Feb 2000 12:58:40 +0100 (MET) Received: from gl17.fty.cstelecom.com ([172.17.68.34]) by hermes2.fty.cstelecom.com (Netscape Messaging Server 3.62) with ESMTP id 294; Thu, 10 Feb 2000 13:02:52 +0100 Received: from cc25.fty (cc25 [172.17.68.42]) by gl17.fty.cstelecom.com (8.8.8+Sun/jtpda-5.3) with SMTP id MAA18835 ; Thu, 10 Feb 2000 12:59:22 +0100 (MET) Received: by cc25.fty (SMI-8.6/SMI-SVR4) id MAA04247; Thu, 10 Feb 2000 12:59:22 +0100 Date: Thu, 10 Feb 2000 12:59:22 +0100 Message-Id: <200002101159.MAA04247@cc25.fty> Apparently-To: 08@ietf.org Apparently-To: Date:@ietf.org Apparently-To: disman@dorothy.peer.com Apparently-To: 200002081131.GAA13511@ietf.org Apparently-To: all-ietf@loki.ietf.org Apparently-To: -0500@ietf.org Apparently-To: 2000@ietf.org Apparently-To: Feb@ietf.org Apparently-To: 8@ietf.org Apparently-To: Tue@ietf.org Apparently-To: for@ietf.org Apparently-To: a.burgain@CSTELECOM.COM Apparently-To: IETF-Announce:@ietf.org Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Distributed Management Expression MIB Author(s) : B. Stewart, R. Kavasseri Filename : draft-ietf-disman-express-mib-11.txt Pages : 48 Date : 07-Feb-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing expressions of MIB objects. The results of these expressions become MIB objects usable like any other MIB object, such as for the test condition for declaring an event. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-express-mib-11.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-express-mib-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-express-mib-11.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: <20000207125445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-express-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-express-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000207125445.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-disman@dorothy.peer.com Thu Feb 10 07:07:49 2000 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19372 for ; Thu, 10 Feb 2000 07:07:48 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id GAA00477; Thu, 10 Feb 2000 06:07:09 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id EAA24710 for disman-list; Thu, 10 Feb 2000 04:06:25 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA24705 for ; Thu, 10 Feb 2000 04:06:20 -0800 (PST) From: Internet-Drafts@ietf.org Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id GAA00426 for ; Thu, 10 Feb 2000 06:06:52 -0600 (CST) Received: from hermes2.fty.cstelecom.com (hermes2.cstelecom.cie-signaux.fr [172.17.68.52]) by oass09.cstelecom.cie-signaux.fr with ESMTP id NAA29926 for ; Thu, 10 Feb 2000 13:04:35 +0100 (MET) Received: from gl17.fty.cstelecom.com ([172.17.68.34]) by hermes2.fty.cstelecom.com (Netscape Messaging Server 3.62) with ESMTP id 409; Thu, 10 Feb 2000 13:08:47 +0100 Received: from cc25.fty (cc25 [172.17.68.42]) by gl17.fty.cstelecom.com (8.8.8+Sun/jtpda-5.3) with SMTP id NAA19324 ; Thu, 10 Feb 2000 13:05:01 +0100 (MET) Received: by cc25.fty (SMI-8.6/SMI-SVR4) id NAA07482; Thu, 10 Feb 2000 13:05:01 +0100 Date: Thu, 10 Feb 2000 13:05:01 +0100 Message-Id: <200002101205.NAA07482@cc25.fty> Apparently-To: 08@ietf.org Apparently-To: Date:@ietf.org Apparently-To: disman@dorothy.peer.com Apparently-To: 200002081131.GAA13525@ietf.org Apparently-To: all-ietf@loki.ietf.org Apparently-To: -0500@ietf.org Apparently-To: 2000@ietf.org Apparently-To: Feb@ietf.org Apparently-To: 8@ietf.org Apparently-To: Tue@ietf.org Apparently-To: for@ietf.org Apparently-To: a.burgain@CSTELECOM.COM Apparently-To: IETF-Announce:@ietf.org Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Notification Log MIB Author(s) : B. Stewart, R. Kavasseri Filename : draft-ietf-disman-notif-log-mib-15.txt Pages : 30 Date : 07-Feb-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging SNMP Notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-notif-log-mib-15.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-notif-log-mib-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-notif-log-mib-15.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: <20000207125459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-notif-log-mib-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-notif-log-mib-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000207125459.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-disman@dorothy.bmc.com Thu Feb 17 11:34:24 2000 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17547 for ; Thu, 17 Feb 2000 11:34:18 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA02385; Thu, 17 Feb 2000 10:32:39 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id IAA25452 for disman-list; Thu, 17 Feb 2000 08:24:05 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA25444 for ; Thu, 17 Feb 2000 08:23:59 -0800 (PST) From: wkenneth@us.ibm.com Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA29080 for ; Thu, 17 Feb 2000 10:24:31 -0600 (CST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA15112 for ; Thu, 17 Feb 2000 11:12:22 -0600 Received: from d54mta05.raleigh.ibm.com (d54mta05.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id LAA53392 for ; Thu, 17 Feb 2000 11:23:55 -0500 Received: by d54mta05.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256888.005A14A2 ; Thu, 17 Feb 2000 11:23:55 -0500 X-Lotus-FromDomain: IBMUS To: disman@dorothy.peer.com Message-ID: <85256888.0059B3C2.00@d54mta05.raleigh.ibm.com> Date: Thu, 17 Feb 2000 08:16:47 -0500 Subject: comments Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Hi, I would like to thank David Partain for his review. The following are his comments with their proposed resolution: David>Here are the issues that I've found. After this (brief) list, David>you'll find language edits in the form of a unified diff. If you David>wish to have some other form for this information, please let me David>know. David>1. pingCtlTrapGeneration is a BITS object, which means that all David> three of the options (probeFailure, testFailure, David> testCompletion) can be set at the same time. This seems wise David> since you might want all three kinds of notifications. David> However, pingCtlTrapFilter is supposed to be used to control David> both when the probeFailure and testFailure traps are sent. David> That is, you cannot control sending of both probeFailure and David> testFailure separately. Right. The filter object applies to both. I agree that it would be better to break this object in to two and proposed replacing pingCtlTrapFilter with pingCtlTrapProbeFailureFilter and pingCtlTrapTestFailureFilter: pingCtlTrapProbeFailureFilter OBJECT-TYPE SYNTAX Unsigned32 (0..15) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is used to determine when to generate a pingProbeFailed NOTIFICATION. Setting pingCtlTrapGeneration to probeFailure(0) implies that a pingProbeFailed NOTIFICATION is generated only when the number of successive probe failures as indicated by the value of pingCtlTrapProbeFailureFilter fail within a given ping test." DEFVAL { 1 } ::= { pingCtlEntry 14 } pingCtlTrapTestFailureFilter OBJECT-TYPE SYNTAX Unsigned32 (0..15) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is used to determine when to generate a pingTestFailed NOTIFICATION. Setting pingCtlTrapGeneration to testFailure(1) implies that a pingTestFailed NOTIFICATION is generated only when the number of ping failures within a test exceed the value of pingCtlTrapTestFailureFilter." DEFVAL { 1 } ::= { pingCtlEntry 15 } David> Is this intentional or am I missing something? Its what was intended. I think two objects instead of 1 is an improvement. David> Was the thinking perhaps that you could only set to one of David> these? If so, it needs to be INTEGER. If not, there need to David> be two filter objects. No. All of the BITS options can be selected. The filter object was intended to apply to both pingProbeFailed and pingTestFailed NOTIFICATION generation. David>2. David> a. Shouldn't the syntax of pingCtlSourceAddress be David> IpHostAddress if you're going to require that it be an IP David> address in numeric form? Yes, thanks for catching this. I've made the change. David> b. Also, this object says in its description, "The address David> type (HostAddressType) that relates to this object is David> specified by the corresponding value of David> pingCtlTargetAddressType." That seems wrong to me. Why David> should the target address type be the same as the source David> address type? That would mean that I cannot ping an IPv6 David> machine from an IPv4 machine. Furthermore, David> pingCtlTargetAddressType would also include DNS names, David> which are explicitly excluded from the possibilities for David> pingCtlSourceAddress. There are two issues here. First is should the source address object allow use of DNS names. I think not since in this case you would use this option to force what IP address gets set in the packet and not want to use DNS to resolve to an address. The second part to this is should the type of address be restricted to be the same as that of the target address. I think it would be better to remove this restriction. A type object wouldn't be needed since if we don't allow DNS names then the length of the octet string would be sufficient to determine type. David>3. The same comment as 2.b applies to traceRouteCtlSourceAddress. Agreed. David>4. It doesn't seem very reasonable to me that you'd want 4billion David> rows in a table. Any reason pingCtlMaxRows isn't limited? Is David> it just that getting agreement on what it would be would be David> difficult? David> The same applies to the other MaxRows objects. Its been a while but I think I had limits that due to discussion were taken out. Basically, isn't this essentially implementation dependent? David accepted this response. David>5. In several places, Counter32 objects are assigned an initial David> value. This is in contradiction with RFC 2578, page 23, David> which states, "Counters have no defined "initial" value, and David> thus, a single value of a Counter has (in general) no David> information content." In practice, I doubt that what is in David> this document is a problem, but the fact that David> traceRouteHopsProbeResponses is zero could either mean that David> it's just been initialized or that there have been 4294967295 David> previous responses and we've just wrapped. David> So, although I think it's not going to be a practical problem, David> it does not strictly follow the SMI. I understand that counters have to be polled in order to determine deltas within an interval however the "counters" in this case indicate where you are in a test. I think it would be OK to change the following objects to Unsigned32: pingResultsProbeResponses pingResultsSentProbes traceRouteResultsTestAttempts traceRouteResultsTestSuccesses traceRouteHopsSentProbes traceRouteHopsProbeResponses David>6. It is conceivable that some lookup implementations might David> return a negative number to be put into lookupCtlRc. Perhaps David> Integer32 is better than Unsigned32. Right. Glade you caught this. The text talks about negative values while the TC is incorrect. I have changed it to Integer32. David>If you so desire, I can go through it again, but I believe that David>the MIBs are fundamentally sound and implementable. Obviously, I David>haven't implemented them, but I believe that I could in a fairly David>straightforward manner. David>I've compiled all three modules with both mosy and smicng with no David>problems. I don't have a version of smicng that supports RFCs David>2578-80 (no one but d.perkins does) though. David also recommended that the REMOPS MIBs use the textual conventions as defined within the endpoint MIB: draft-ops-endpoint-mib-06.txt | draft-ietf-disman-remops-mib-07.txt | InetAddressType ::= TC | HostAddressType ::= TEXTUAL-CONVENTION SYNTAX INTEGER { | SYNTAX INTEGER { unknown(0), | none(0), ipv4(1), | dnsName(1), ipv6(2), | ipv4(2), dns(16) | ipv6(3) } | } | InetAddress ::= TC | HostAddress ::= TEXTUAL-CONVENTION SYNTAX | SYNTAX OCTET STRING (SIZE (0..255)) | OCTET STRING (SIZE (0..255)) | | none | IpHostAddress ::= TEXTUAL-CONVENTION | DESCRIPTION | "The textual convention for | specifying an IP host address. | The type of address can be | determined by the octet string | length: | OCTETs ADDRESS TYPE | 0 not specified | 4 ipv4 | 16 ipv6" | SYNTAX OCTET STRING (SIZE (0..16)) | Since IpHostAddress doesn't have a corresponding TC in the endpoint MIB the best solution would be to add a corresponding type object using the InetAddressType TC, convert use of HostAddress to InetAddress and then in the compliance statements indicate that only a subset of the address types must be implemented. Bert wants the following changes made: - import mib-2 instead of experimental, - use ::= { mib-2 xx } -- to be assigned by IANA - add a REVISION clause aka: REVISION "200001210000Z"-- same date/time as LAST-UPDATED DESCRIPTION-- XXXX assigned by RFC Editor "Initial version, published as RFC XXXX." I have made these changes. Unless I hear objections to the proposed changes I will update the I-D and submit a new draft in the next week or so, Ken From owner-disman@dorothy.bmc.com Thu Feb 17 12:52:07 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20396 for ; Thu, 17 Feb 2000 12:52:05 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA29706; Thu, 17 Feb 2000 11:50:37 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id JAA28416 for disman-list; Thu, 17 Feb 2000 09:48:54 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA28410 for disman@dorothy.peer.com; Thu, 17 Feb 2000 09:48:50 -0800 (PST) Date: Thu, 17 Feb 2000 09:48:50 -0800 (PST) From: Randy Presuhn Message-Id: <200002171748.JAA28410@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Re: comments Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > From: wkenneth@us.ibm.com > To: disman@dorothy.peer.com > Message-ID: <85256888.0059B3C2.00@d54mta05.raleigh.ibm.com> > Date: Thu, 17 Feb 2000 08:16:47 -0500 > Subject: comments ... > I would like to thank David Partain for his review. The following are his > comments with their proposed > resolution: ... The proposed resolutions look fine to me. Thanks Ken & David! ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.bmc.com Fri Feb 18 10:00:30 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24482 for ; Fri, 18 Feb 2000 10:00:28 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id IAA11928; Fri, 18 Feb 2000 08:59:05 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id GAA13978 for disman-list; Fri, 18 Feb 2000 06:53:55 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA13969 for ; Fri, 18 Feb 2000 06:53:43 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id IAA10431 for ; Fri, 18 Feb 2000 08:54:14 -0600 (CST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id PAA01171; Fri, 18 Feb 2000 15:53:21 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id PAA29285; Fri, 18 Feb 2000 15:53:20 +0100 Date: Fri, 18 Feb 2000 15:53:20 +0100 Message-Id: <200002181453.PAA29285@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: wkenneth@us.ibm.com CC: disman@dorothy.peer.com In-reply-to: <85256888.0059B3C2.00@d54mta05.raleigh.ibm.com> (wkenneth@us.ibm.com) Subject: Re: comments References: <85256888.0059B3C2.00@d54mta05.raleigh.ibm.com> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> wkenneth writes: David> b. Also, this object says in its description, "The address type David> (HostAddressType) that relates to this object is specified by David> the corresponding value of pingCtlTargetAddressType." That David> seems wrong to me. Why should the target address type be the David> same as the source address type? That would mean that I cannot David> ping an IPv6 machine from an IPv4 machine. [...] Note that the latest ID of the endpoint MIB requires that you have InetAddressType/InetAddress pairs. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.bmc.com Mon Feb 21 13:09:36 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13869 for ; Mon, 21 Feb 2000 13:09:35 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id MAA28610; Mon, 21 Feb 2000 12:07:49 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA06789 for disman-list; Mon, 21 Feb 2000 10:01:42 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA06783 for ; Mon, 21 Feb 2000 10:01:35 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id MAA25785 for ; Mon, 21 Feb 2000 12:02:03 -0600 (CST) Received: from ipb.pt (titan.estig.ipb.pt [193.136.195.250]) by elara.ipb.pt (8.9.3/8.9.3) with ESMTP id SAA24314 for ; Mon, 21 Feb 2000 18:00:12 GMT Message-ID: <38B17DF4.EE60B298@ipb.pt> Date: Mon, 21 Feb 2000 18:03:32 +0000 From: rp X-Mailer: Mozilla 4.71 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: disman list Subject: Expression MIB value identification issue Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi. My name is Rui Pedro and I have a small difficulty on the Expression MIB. In draft-ietf-disman-express-mib-11.txt, on 3.3.4. (Value Identification) it mentions that values "are identified with a combination of the object identifier (OID) for the data type from expValueTable (such as expValueCounter32Val), the expression name, and an OID fragment." According to the ExpExpressionTable, each expression is identified by owner and name. The obove mentioned "expression name" includes the owner also? If not so, how to correctly identify values from the expressions with same name but different owners? I am sorry if this question is not adequate to the mailing list. Cheers. Rui Pedro