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.