Editor's note: These minutes have not been edited. Distributed Management Working Group 11 December 1996 - 3:30 PM Chair: Maria Greene Reported by: Bob Stewart (bstewart@cisco.com) If you want on the mailing list, please subscribe for yourself. You can track down mailing lists via the IETF Web page at www.ietf.org. Just signing the blue sheet will not get you added. Agenda: Script MIB Issues Framework & Expression MIB Presentation *** Script MIB Issues *** ** Get results via URL? Push or pull? Pulling metavariables is preferable. A URL is in addition to metavariables. Metavariables have problems with garbage collection and intermediate results. Mapping of variables to URL should be generic. A URL is for returning information to humans and is not good for computers. Consider the size of the returned information. Return a small amount in a variable and a large amount by some other means. Data remains available until next run. A URL implies HTTP, that is, not UDP only. Would it make sense to have a Trap? Yes, to say results are available. What about incremental results? No way we need a URL. Intermediate results can go by push. Final results can go by pull that causes script to run. A script can push as it wishes. This is all we can do without specifying a language. For intermediate results script should be able to use standard notifications. A URL can be private between application and script. ** Scheduling scripts? It's a local "pull." Time of day seems appropriate here. Problem is we're not defining language and capabilities so its hard to describe what is in the support structure. What solution is more tractable, change the script or write to a MIB? What about triggering by other events? Startup mechanisms can be entirely independent of scripts or one another. Scripts can emulate other mechanisms such as by running periodically. Script MIB purpose is to download and start scripts and get results. It seems easy to do a MIB to implement controls on when to run, once or periodically, elapsed or absolute time. We're talking about a chrontab MIB. The mechanism should be the same for all scripts. Pick the simple cases and cover them. It's good to have a central place to say what will run. A general chrontab MIB could be reused. Sounds like we should add a few parameters to execution table or a separate table. ** Runtime instrumentation Perhaps this is script or language specific. This would be nice but is too hard. A debugger should be a script. Current plan supports sending partial results. An example would be CPU usage. It would be useful to have complete error codes and hint, such as divide by zero at line number. ** Notify of status changes? Don't do this for normal termination. What about the infinite loop case? Perhaps we need a timeout. It's scary to keep adding new ideas. When is it safe to terminate? Cleanup is necessary in any case. Some environmental interfaces check for a kill at startup. What parameters would we need for a limit? Don't do this, there are too many possibilities. Call script to stop it? No call system is specified. System may not listen. Are there objections to leaving this out? Yes, we need a hog limiter, but implementation is scary. Discussion will continue on mailing list. What about other controls on scripts, such as not allowing them to change system state. That's a tough problem. This is a big security hole and we're supposed to consider it. We could just say what we intend. ISO decided there are two cases: some scripts can change their access and some run with the access of the starting party. We are rapidly sliding into other issues such as SNMP community versus user. This should be discussed on the mailing list. The capability of the engine is rarely sufficient. Implementation must consider that management implies the ability to break things. Security depends on system abilities and their relationsship to the SNMP user, assuming SNMP security. We need notifications for abnormal terminations. ** Clone script? This assumes the script is in source form. Why bother? This is not useful. We have no experience to require such a function. No. ** Generation of notifications and address of remote system. Imbed this in the script. Doing it this way is clumsy. Requester gets responses and notifications. Other targets are in script. This sounds like parameter passing. Where does an abnormal termination go? To the requestor. This interacts with upcoming SNMPv2 features. Defer this to the mailing list and the DisMan framework. ** Just use the MIB to download? Upload depends on the implementation and some can't do it. ** Return multiple results and values? Maybe this should be via the framework. Do multiple returns from inside the script. Adding a table is not good. We'd need a table for large returns. The framework may provide a log table. Those aren't typed or indexed conveniently. Typing is done with multiple objects. See the union textual convention in the Perkins draft. Return ASCII or typed, one or multiple. The script can do its own returns. This is easy for the managed system but hard for the application. Defer this to the mailing list. ** Event Trigger Is it a good feature to execute based on a notification? This is hard to nail down, do it by script. Can a script sense events? Leave it to the script writers. Have an object to trigger a script with a script to receive notifications. You'd need to provide parameters from the event and pattern match to select what to run. It's easy to express this in a MIB. Write a dispatch script to recognize events. How does a script get events? We need to be able to tie a script to any notification. There are events other than notifications. Some events can easily be included, some can't. Defer this for more experience. We'll need master scripts to dispatch events. We're implying applications to notice other events, so this isn't appropriate here. Is this worth it just for SNMP notifications? These are good ideas but we won't think through it at this meeting. We need to find a line between the lnaguage and a generic MIB. Event traps are good, but not in this MIB. Is this critical for now? Do this on the mailing list. Distributed Management Working Group 11 December 1996 - 7:00 PM Chair: Maria Greene Reported by: David Levi (levi@snmp.com) Agenda for the evening disman meeting: - Presentation and discussion of framework for disman - Presentation and discussion of expression MIB - Scheduling The meeting started with a presentation by Steve Waldbusser about the framework document: There are a number of framework issues that need to be addressed - Scalability issues - there may be thousands of devices in a network - keeping management system up to date each time a node is added, must update management system, possibly using some auto discovery mechanism - auto dicovery is one mechanism that management stations use to deal with scalability - distributing scripts helps solve scalability problems, but there is a need for autonomy for this approach to be effective There was some dicussion about work being done by ISO which is similar to the work being done by the disman WG. There were also comments about the need to draw a distinction between a script, and the execution of the script. Steve then went on to describe a number of services which the framework should provide. These are 'core functions', and help handle automation. The services roughly correspond to groups in the framework MIB - Known Devices - Domains (devices can be in multiple domains) - a domain is a collection of devices, like all systems in the finance department - there will be rules applied to a device to determine if it is in a domain - ISO has primitives to determine if a device is in a domain. - What is in a domain at any particular time can be fuzzy, trying to keep this in a database can be problematic. Has to be a 'best effort' as to what is in a domain at any particular time. - determination of domain should be separate from auto-discovery - are rules for domain assignment lossy? there will *have* to be info entered by humans to accomodate this. - might want devices that you cannot communicate with directly to be included in a domain - can be *lots* of ways to populate known systems/domains, not just auto-discovery and manual addition - discovering *how* to talk SNMP to a device is important, but not yet discussed (i.e. what community string to use, or what username/keys when/if v2 becomes standard). - Targets - a target is also a collection of devices, like all Cisco routers - there will be rules applied to a device to determine if it is part of a target - an application would specify a domain and a target for a management operation. the operation would be applied to all devices in the intersection of the domain and target. - might be useful to permit a rule to be the combination of other rules (union, intersection, etc) - Delegation control - need a mechanism to control what management operations are performed on what distributed managers on behalf of what 'sponsor' manager. - Scheduling - mechanisms for specifying when particular management operations should be performed - Reliable Notifications - event notification spanning multiple PDUs - push model for data - send event saying 'this happened, get the resulting data from this place' - Notification Destinations Further discussion about framework: - idea of a policy associated with a domain - launching a script can potentially be a rather major event, may want to be very careful before doing this. scripts may be large and complex - how do you deal with a script which changes something that affects its own behaviour - repository of standard scripts - discussion of use of object-oriented technology versus SNMP-based technology. Where to draw the line? These technologies do not have to be mutually exclusive. Bob Stewart presented some information about the Expression MIB: - description of how postfix expression evaluation works - there is a time element which is not easily handle using an expression evaluator, for example, expressions involving delta values - Jeff Case gave a brief history of the SRI script language - it is easy to encode an expr in a mib - might want to consider spread-sheet-like expressions - need to have expressions based on historical data, this is also difficult to express in a mib - multiple statement expressions, aliases? this may be getting too close to a script language - should try to identify some expressions and threshhold for which the expression MIB would be useful. this would help demonstrate the value of having an expression MIB - need to discuss on mailing list how much we need this, how much it should do, how powerful it should be - may be useful to looks at HEMS (High-Level Entity Management System), documented in RFCs 1021-1024 Scheduling - post list of issues on script MIB to mailing list - posting of other I-Ds (framework, expression MIB) - discuss script MIB on mailing list - there may be an interim meeting before april ietf