Editor's Note: These minutes have not been edited. Minutes for Distributed Management meetings, April 7, 1997 Reported by David Levi ------------------------------------------------------------------------- The meeting started with a couple of announcements. First, the new charter is close to being accepted by the IESG. The schedule in the new charter extends work though the Munich meeting. Second, there needs to be text written for all of the DISMAN IDs for security requirements. There were four technical presentations. Andy Bierman gave a short presentation about the document he recently submitted regarding integration for trap filtering with the script MIB. Juergen Schoenwaelder presented the list of open issues in the script MIB, and discussed his implementation of the script MIB. Steve Waldbusser gave a presentation about the DISMAN framework and services. Bob Stewart presented the MIBs he recently posted, and went through a detailed example of how one would use them. There were two topics which were discussed throughout the presentations and throughout the meetings, integration and security. Integration ----------- Currently there is very little integration between the various IDs related to DISMAN. For example, there isn't a mechanism in any of the framework documents for executing a script defined in the script MIB when a trap is received by a distributed manager. The document that Andy Bierman posted was intended to get discussion started on this topic. There is general agreement in the group that there needs to be integration between the various documents. There was also some discussion about how the various MIBs should be split among multiple documents. It might be useful to have the MIBs related to different framework services be in separate documents in order to make it easier for an implementation to only use the services it needs. Another was to accomplish this is to have different conformance statements in the framework MIBs. There was not complete agreement on which approach should be used. There is also some overlap in functionality between the various IDs. Looking at where this overlap exists may help in determining how documents should be split. Security -------- The DISMAN MIBs need to be designed in a way that can make use of (and not conflict with) the SNMPv3 security mechanisms. Of course, we are anticipating that the SNMPv3 working group will be successful, and that we'll have these security mechanisms available in the near future. The security topic that received the most discussion was the issue of how to have a management task which has been delegated to a subordinate manager maintain the same access rights as the 'user' that delegated the task. For a specific example, a particular user might download a script to an mlm and set the script to run every ten minutes. When the script runs and attempts to perform SNMP operations, the access it has to other agents ought to be the same as the user who originally downloaded the script. There is probably also a need for the ability for one user to download configuration info for a management task to an mlm, and for a different user to be able to run that management task. This is similar to a unix program being 'setuid'. A related question is whether such a management task should have the privileges of the user who created it, the user who ran it, or some combination. The model that seems to be getting agreement for dealing with these issues involves using careful indexing of MIB tables. For example, we might include the username of the user who creates a script in the smScriptTable, and including both the username of the user who created a script and the username of the user who runs a script in the smRunTable. This would allow the SNMPv3 access control mechanisms to be used to control: - which users can create scripts, - which users can run scripts, - which users can run scripts that were created by another user (and which user's scripts they are allowed to run) There is also the issue of determing SNMP version and community/key information to be used by a management task that has been delegated to an mlm. There needs to be rather fine-grained control over which community/key information is available to a particular management task. This is so that a user who configures a management task (with the intent to allow another user to run that task) can restrict which community/key information other user's can make use of when running the task. In order to accomplish this, there will need to be a way to download a 'profile' to an mlm, and attach this to a management task (both when it is configured and when it is executed). There was discussion about whether IPsec would be useful to DISMAN. While it might help with authentication, it will not help with authorization (access control), or when using SNMP over other transports. Framework Issues ---------------- There was more discussion about the services related to destinations, or 'targets', of management tasks. There are 2 parts to this: - keeping lists of all known systems - forming subsets of all known systems, i.e. the set of devices on which you want to perform an operation Subsets of devices are selected by rules. In the original framework document, there were 2 'levels' of rules through which the list of known systems would be run to get a subset. This will probably be relaxed so that there can be an arbitrary number of rules used. There also must be some mechanism/language for expressing rules. The original document use a form of regular expressions. It may be desirable to use expressions or scripts as well. Other ----- Here are a few notes about Bob's presentation about his MIBs. There are 4 MIBs: The expression MIB allows you to define a new object whose value is determined by an expression involving other MIB variables. There are mechnisms for: - wildcarding the object involved in the expression - using delta values of objects involved in the expression All objects in expressions are local to the agent in which the expression runs. One thing that needs to be fixed is that if you want an expression to run in multiple contexts, you need to configure it in each context (I think this means you currently cannot mix objects from multiple contexts in a single expression). The management target MIB is used to select a set of targets for a management operation. This MIB has some overlap with the framework document. It also provides SNMP version/community info for targets. There are two kinds of targets, single systems, and groups of systems. The notification MIB is intended to control where notifications are sent, when they are sent, and to log/count notifications that have been sent. This MIB allows sending of notifications to be enabled and disabled at three levels, per management target, per notification, and per system. The event MIB provides a mechanism for periodically checking a condition and generating an event if the condition has been met. The result of generating an event is to take some action (sending a notification or setting an object).