2.4.5 Distributed Management (disman)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01


Randy Presuhn <rpresuhn@bmc.com>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>

Operations and Management Area Advisor:

Bert Wijnen <bwijnen@lucent.com>

Mailing Lists:

General Discussion:disman@dorothy.bmc.com
To Subscribe: disman-request@dorothy.bmc.com
In Body: subscribe disman your_email_address
Archive: ftp://amethyst.bmc.com/pub/disman/archives

Description of Working Group:

The Distributed Management Working Group is chartered to define an initial set of managed objects for specific distributed network management applications which can be consistently developed and deployed. A distributed network manager is an applicaton that acts in a manager role to perform management functions and in an agent role so that it can be remotely controlled and observed.

Distributed network management is widely recognized as a requirement for dealing with today's growing internets. A manager application is a good candidate for distribution if it requires minimal user interaction, it would potentially consume a significant amount of network resources due to frequent polling or large data retrieval, or it requires close association with the device(s) being managed.
The working group will limit its work to distributed network management applications where the main communication mechanism for monitoring and control is SNMP. Future work (and other working groups) may be chartered to investigate other distribution techniques such as CORBA or HTTP. The objects defined by the working group will be consistent with the SNMP architecture defined in RFC 2571. The working group will especially keep security considerations in mind when defining the interface to distributed management.
The working group will complete these tasks:
Define a Scheduling MIB
Define a Script MIB
Define a Remote Operations MIB
Define an Expression and Event MIB to support Threshold Monitoring
Define a Notification Log MIB
Define an Alarm MIB
The working group will consider existing definitions, including:
o the RMON working group's work in this area
o the Application MIB (RFC 2564), SysAppl MIB (RFC 2287) and related standards.
The work on the Alarm MIB will take into consideration existing standards and practices, such as ITU-T X.733. Whether any mappings to these other standards appear in the Alarm MIB or in separate documents will be decided by the WG. The WG will actively seek participation from ITU participants to make ensure that the ITU work is correctly understood.
It is recognized that the scope of this working group is narrow relative to the potential in the area of distributed network management. This is intentional in order to increase the likelihood of producing useful, quality specifications in a timely manner. However, we will keep in mind and account for potential related or future work when developing the framework including:
o Event and alarm logging and distribution
o Historical data collection/summarization
o Topology discovery

Goals and Milestones:



Post Internet-Draft for Threshold Monitoring MIB.



Meet at the Montreal IETF meeting to discuss charter and review the Threshold Monitoring MIB Internet-Draft.



Post Internet-Draft for Framework document.



Post Internet-Draft for Script MIB.



Submit final version of Threshold Monitor MIB Internet-Draft for consideration as a Proposed Standard. Submit updated versions of Internet-Drafts for Script MIB.



Meet at the IETF meeting to discuss Internet-Drafts and issues that come up on the mailing list.



Submit final versions of Internet-Drafts for Script MIB and Schedule MIB document for consideration as Proposed Standards.



Agree on charter revisions for future work.



Submit final versions of Internet-Drafts for Expression, Event and Notification MIB documents for consideration as Proposed Standards.



Submit final version of Internet-Draft for Remote Ping, Traceroute, and Lookup Operations Using SMIv2



Meeting in Oslo to discuss implementation and deployment experience with Schedule and Script mibs, identify any updates needed to these documents.

Mar 01


WG agreement on direction regarding mappings to / from other alarm frameworks

Mar 01


Submit updated Script and Schedule MIBs for consideration as Draft Standard (or recycle at Proposed).

Mar 01


Submit updated draft of Alarm MIB for IETF meeting

Mar 01


decision on question of whether recycle the Log MIB.

Jul 01


Submit updated draft of Alarm MIB for IETF meeting.

Aug 01


WG last call on Alarm Management MIB.

Sep 01


Alarm Management MIB delivered to IESG for consideration as a Proposed Standard.

Oct 01


call for implementation experience and updatescall for implementation experience and updatescall for implementation experience and updates to the remote operations MIB.

Oct 01


call for implementation experience and updates to the Event and Expression MIBs.

Request For Comments:






Definitions of Managed Objects for Scheduling Management Operations



Definitions of Managed Objects for the Delegation of Management Scripts



Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations



Distributed Management Expression MIB



Event MIB



Notification Log MIB

Current Meeting Report

DISMAN Meeting Minutes, March 19, 2000, IETF Minneapolis

Compiled by Sanjai Narain, narain@research.telcordia.com

There were three broad themes: MIBs for new alarms, Condition MIB (every condition is not an alarm), and Alarm Report Control MIB (how to suppress alarms from being reported). The purpose of today's meeting was how to reconcile these themes.

The following presentations were made:

By Sharon Chisholm: "Alarm MIB requirements", "Alarm MIB" and ITU Alarm MIB" and "Alarm MIB Slice and Dice".

By An-Ni Huynh: "Condition MIB".

By Kam Lam: "Alarm Reporting Control (ARC) MIB".

By Dan Romascanu: ??Exact title??

Randy: Do we care that other groups like Syslog, idwg are suspiciously alarm like. Do we care.

Dan Romascanu: yes we do. Distributed systems alarm.

First speaker. Sharon Chisholm. Alarm MIB requirements. New proposals for alarm management on the mailing list. What is the problem we are trying to solve?

Compliance matrix is shown. Columns are Requirement Number, Description, Compliance.

Alarm definition: 1.6, 1.7. Unambiguously tells you who detected the problem. 1.7: Means of obtaining ITU alarm information.

Randy: Don't want to make the subagents visible.

Audience: Randy doesn't care which subagent generated the alarm.

Randy: Not quite. I don't want to talk about subagents, OK to talk about subsystems.

Dave Perkins: You can buy cheaply videocameras for your house for security. Alarm condition = movement in pool area. There is more value if for each camera there is an agent which

Randy: Does anyone have a problem with this requirement? No response. Strong maybe.

Sharon: Historical, requirement number .4 Condition management.

Randy: Last night, things of historical interest have never been notifications. Hence they never appear in any notification log MIB.

Sharon: Turn this into a 'yes'. Going one, going twice. Next issue is alarm suppression (Requirement 5.1). Is anyone opposed? No response. Several show of hands. 5.2 Severity. How much alarm suppression. Who has a need for alarm suppression by severity? use make use of alarm notification in my mib? Could an alarm be automatically generated?

Sharon: Don't see why not. Another real-life example.

Randy: So if I haven't built something into this implementation that recognizes clear condition, alarm will not clear. We need to be realistic. Is this a show stopper? We need to be confident that this approach is useful in enough number of cases. Have I stated your case fairly, Dave? You don't look too unhappy.

Randy: Judging by time, unless the assembled masses are desperate for more example, this is a good breaking point, let us discuss the Condition MIB.

An-Ni: An-Ni Huynh/Mark Stewart, Lucent. Condition MIB. Mainly for us to understand there is an abnormal state in which an entity exists. We want to know the current status of device. Is condition current, transition or retired? One type of notification for OK condition. Suppress alarm notification/reporting filtering based on level of security. Alarm notification is relevant to condition. What kind of alarm type is it? We also need to know what type of device it is. Also, is it a circuit pack, or physical port? This looks like an ITU-T specification.

Randy: Replace alarm with "condition" on this screen.

An-Ni: Condition detection ? one of three lists: Current condition list, transient condition list, retired condition list.

Randy: I believe that Sharon has a slide which will detail what An-Ni just described (slice/dice).

A more detailed example is a case where you suppress a particular notification if something is being provisioned.

Audience: What is an alarm profile?

An-Ni: For some cases alarm is critical, some minor.

Randy: For example, administrator has declared that I care about LOS on T1 but not dialup.

Randy: We've got suppression, degradation, filtering. I think that if it sounds like we want to look at this side of the problem, this would be a good question for the mailing list. First we want to look at slice/dice.

Randy: Next presentation from Kam Lam.

Kam: ARC MIB. Needs for suppression of alarm reporting. Needs for automatic in service provisioning.

Randy: Is it fair to say that currently in several MIBs we have mechanisms for turning off notification of a particular type. This provides a generic mechanism for new MIBs.

Andy Berman: Delaying is a lot different that suppression.

Randy: If it is cleared, you don't want it to go into the log.

Kam: Once an entry transitions from ARC mode to ALM state, the entry will disappear from table.

Audience: How is this related with X.734?

Randy: Closest to EFD is described in RFC 2574 where notification MIB provides a capability crudely equivalent to EFD.

Audience: EFD is shut at destination, whereas you are trying to shut it off at the source. This is an important point.

Sharon: Alarm MIB requirements. Conditions MIB is solving a different problem than active alarm tables. Persistent versus non-persistent indication of alarms.

Randy: Only SOME conditions are treated as alarms.

Sharon: Initial slice: Separate MIBs for alarm definition and active alarm management. Conditions and ARC.

Randy: I'd like to get a sense who believes we should continue working on the capability Active Alarm Table? Many raised hands. One objection: this is getting too complex, my requirements satisfied by notifications log mib.

Dave Perkins: Not all notifications are alarms. Does the objector understand this?

Randy: The second chunk of work: defines condition detection. Is there any support? A few show of hands. Vehement opposition from same objector. To him this is too much burdensome.

Audience: Be careful in gauging broad consensus. Most people are in the middle between vehement opposition and support, but have no great suggestion. No response =/= assent.

Randy: ARC. Selectively throttle. What is consensus? A few show of hands. Strong opposition. None. Extrapolating that, I believe this means we have at least one additional document that would have within it the ARC, and the condition mib. Is that acceptable as a straw man. Already, there are editors. Others welcome to contribute. Area director Bert said it is fine with him. Anything else on slice and dice?

Audience: Condition, alarm, ARC are closely related, so definition of documents should be coordinated. Moderators agreed.

Audience: If you are finishing with this framework, specify in the documents what relationship with other documents.

Randy. We will meet again on Tuesday.

Minutes of 3/21 Distributed Management Working Group

Randy Preshun started the meeting by proposing and receiving acceptanced of an agenda for this meeting:

I. Working Group Discussion: What if anything needs to be done in terms of additions/corrections to notification log mib based on what is coming in from event/scheduling mib experience?

II. What we need to do with other scripting related discussions?
-- Andy Bierman, SEE
-- Juergen Schoenwalter, SMX

An unofficial third point emerged, in the discussion of a few points of working group administrivia.

I. Notification Log MIB:

(Some of the more notable commentary follows)

Sharon and Randy: If deployment has uncovered inefficiencies or perceived inefficiencies, it is in the interest of the working group not to create a new MIB but fix those inefficiencies.

David Perkins: believes MIB in its current form is not "understandable". Randy noted: at least one object in MIB which is redundant, others may be "suboptimal".

Ram Kavasseri: (document editor) notes, Others have working implementation, and asks, What specifically is not workable? Need customers who are deploying it to give feedback. Randy notes, such feedback MUST go to the working group list.

David gave some initial impressions about "nonworkability": The MIB does two things depending on where it's deployed, which is a confusing and not efficient practice. Second: If SNMP traps used, they can be dropped en route to manager. Hence, Information can be duplicated in log.

Some points of discussion on these claims followed.

ACTION ITEM: Randy asks that David post his issues with the logging to the working group mailing list (along with other performance issues etc.). Would like to see this happen "sooner rather than later".

II. Disman-related scripting work

Andy Bierman: presented the points of relevance and context of his current individual submission: draft-bierman-disman-see-00.txt, the *Script Execution Environment (SEE) Specification*.

The submission itself is fairly lengthy and the details of SEE I-D content were stipulated as out of scope for the purposes of this discussion.

The original Script MIB tried to hide device and mechanism complexity, reduce exposure to single points of failure, and reduce incident response latency.

To the extent of addressing these needs in the disman environment, this first solution was on right track, but critical system components are missing:

-- a standard prog. language
-- a standard runtime environment in which to execute scripts.

Need to:
-- choose a language (Andy notes that any suitable language will do, although Andy has SEE language, and thinks it should be evaluated for fitting the bill)
-- the capabilities of the somewhat should reflect a runtime environment

The language: should include special features for SNMP: OID assembly/manipulation, string encodings for necessary data types.

The runtime environment needs a framework:

-- a mechanism for establishing and passing named script parameters
-- a clear notion and expression of per task runtime permissions
-- attribute centric access control for each library function,
-- documentation templates for scripts and libraries.
-- a notion of standard and vendor system libraries.
-- a notion of task groups
-- capability for scoped "Environment variables" accessible to the script runtime.
-- DIAGNOSTIC facilities, very essential.

The essential design tradeoff is between a Script engine versus a Full operating system:

-- Full arithmetic logic?
-- Conditionals?
-- Iteration?
-- Functions?
-- Run to completion scheduling?

It is likely that the above functions are essential, but a complete operating system is not needed for net management shell.

An Initial profile communicates the execution requirements of a script.
SEE provides a few top level profile options:

-- An "unconstrained" script is invoked when value of any instance of a specified MIB object changes value.
-- Periodic profile: invoked once per time interval
-- Calendar profile: unconstrained script invoked via Scheduling MIB.
-- Notification filter profile: Partially constrained script is invoked just before a notification is issued.

Relationship to Policy Management MIB Module from SNMPCONF working group (aka "PM MIB"): Andy sees these as Similar solutions to different problems. SEE is centered on Applications unrelated to policy-based configuration (his classic example: rotate-logs.sh). PM is s specialized application for policy based configuration of device elements. Andy also believes that PM lends itself to an expectation that NMS application will write PM MIB-managed scripts, whereas the SEE scripting is more suitable for human originated/edited scripts.

So, overall, PM is not and should not be a general purpose scripting environment--that's what the script MIB is for as it pertains to the scripting environment specifically. Within that environment, PM scripts are really callback functions, triggered upon the activation of their filters.

To refine the Script MIB usage from this view, the Script MIB accomplishes the aims of:

-- language registry
-- language extension registry
-- script transfer mechanisms
-- script storage
-- Integration with scheduling MIB.

PM language could be a subset of SEE language. The proper SEE integration would leave function calls, floating point, etc. out of PM.
Similarly OID expressions and OID aliases are covered by SEE.

Looking at it from the point of view of PM integration,
-- The Runtime Environment covers: debugging and logging.
-- SEE covers application profiles, names parameters and environment variables, explicit runtime permissions.
-- PM could use: roles, etc.

Notable Questions:

Steve Waldbusser--what is the placement of application profiles in the environment? Andy: essentially, documentation, predefined environment variables.

Several: Issue of coupling/dependencies between runtime environment architecture and language architecture. In particular, is there any inherent dependency by the runtime environment on the language? Could this adapt to demands for handling interpreters for legacy scripting languages? (Perl and Python mentioned) Andy:the specification has made the language and runtime environment set up to be independent and replaceable with respect to the other (up to a point).

Resolution/ACTION ITEM: continue discussing this on mailing list, and if "critical mass" emerges to pursue this, then Randy talks to Bert and sees about extending charter to include some work here. Furthermore, a caucus of present Working Group members with interest in scripting environments will meet and report on any consensus/discoveries.

SMX/Juergen Schoenwalter

Juergen spoke briefly about the work he's been doing privately on SMX and his belief that it coincided a bit with work going on within the working group. SMX represents a runtime system boundary for the Script MIB, and is already published as experimental in RFC 2593. Juergen mentioned the availability of a second version of SMX as an individual submission Internet draft, and felt it was paralleling discussion of these topics within disman. He wanted to briefly ask anybody who had encountered the draft as to whether the Disman working group wanted to take this on within the charter. As there were no takers on the working group floor, no action was taken.

Other Administrivia

ACTION ITEM: Script MIB to be handed off to Bert to take to IESG, no final comments.

changes to target dates: still tracking script work dates as current.

To summarize anything threatening to turn into an additions to charter: still need to discuss Andy's work on SEE. Proposal on means of talking amongst mid-level managers.

Who is editing team for alarm report condition stuff, report to mailing list?

Gideon Stupp of Sheer Networks wanted to indicate their development of interface architecture for distributed provisioning management and asked if there was any group interest in it. Randy indicated that publishing details on this technology to the working group list would be the best way to pursue this.

ACTION ITEM: Andy Bierman will write up what's wrong with the Script MIB in its current draft form.

ACTION ITEM: Dave Perkins to provide comments and concerns on notification log MIB.


Alarm Reporting Control MIB
Script Execution Environment (SEE) Specification
Alarm and ITU Alarm MIBs
Alarm MIB Requirements
Alarm MIB Slice and Dice