NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 26-Nov-97
Chair(s):
Randy Presuhn <rpresuhn@bmc.com>
Operations and Management Area Director(s):
John Curran <jcurran@bbn.com>
Michael O'Dell <mo@uu.net>
Operations and Management Area Advisor:
John Curran <jcurran@bbn.com>
Technical Advisor(s):
Bob Stewart <bstewart@cisco.com>
Mailing Lists:
General Discussion:disman@nexen.com
To Subscribe: majordomo@nexen.com
In Body: subscribe disman your_email_address
Archive:
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 and a framework in which these applications and others can be consistently developed and deployed. A distributed network manager is an application 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 communication mechanism used between managers (or the components of the management application) 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 framework. The working group will especially keep security considerations in mind when defining the interface to distributed management.
The working group will complete these tasks:
o Define a Threshold Monitoring MIB o Define a Script MIB o Define a Distribution Management Framework and MIB
This last MIB is required in order to keep distributed managers from adding to the management problem. This MIB will allow distributed managers of many types to be controlled in a consistent way including controlling their "management domain" (the set of devices upon which they act), the relationships between the management applications or components, and to some extent the scheduling of their operation.
The working group will consider existing definitions, including:
o RFC1451, The Manager to Manager MIB which was being considered by the SNMPv2 working group
o the RMON working group's work in this area
o the SNMP Mid-Level-Manager MIB which is now an expired Internet-Draft
o the work of the Application MIB working group
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:
May 96 |
|
Post Internet-Draft for Threshold Monitoring MIB. |
Jun 96 |
|
Meet at the Montreal IETF meeting to discuss charter and review the Threshold Monitoring MIB Internet-Draft. |
Jul 96 |
|
Post Internet-Draft for Framework document. |
Aug 96 |
|
Post Internet-Draft for Script MIB. |
Sep 96 |
|
Hold an interim meeting to discuss Internet-Drafts and issues that come up on the mailing list. |
Nov 96 |
|
Submit final version of Threshold Monitor MIB Internet-Draft for consideration as a Proposed Standard. Submit updated versions of Internet-Drafts for Script MIB and the Framework document. |
Dec 96 |
|
Meet at the IETF meeting to discuss Internet-Drafts and issues that come up on the mailing list. |
Feb 97 |
|
Submit final versions of Internet-Drafts for Script MIB and Framework document for consideration as Proposed Standards. |
Internet-Drafts:
· Definitions of Managed Objects for the Delegation of Management Scripts
· Distributed Management Framework
· Event MIB
· Expression MIB
· Management Target MIB
· Notification MIB
No Request For Comments
Minutes of the Distributed Management (disman) WG
WG Chair: Randy Presuhn
Reported by: Andy Bierman
Summary
The DISMAN WG met at this meeting to advance the documents in progress. Most of the meeting time was used addressing difficult security issues. Many aspects of script and expression configuration and operation within a secure SNMPv3/VACM environment were discussed, and a great deal of progress was made in this area.
Agenda
1. Administrative issues
1.1 Review of agenda & adjustments
1.2 Mailing List Information
1.3 Charter Updates - yes the revised charter has been submitted to our area directors.
1.4 Allocation of time for discussions
2. Technical Presentations
none currently scheduled, please let the chair
know in advance so time can be budgeted
3. General Technical Discussion
3.1 Impact of SNMPv3 work
3.1.1 terminology
3.1.2 application types
3.1.3 access control implications
3.2 Framework issues
3.2.1 Do we still need it?
3.2.2 Alignment with SNMPv3 work
3.3 Target MIB
3.3.1 Editor's overview of changes
3.3.2 Alignment with SNMPv3 work
3.4 Script MIB issues
3.4.1 Editor's overview of changes
3.4.2 Alignment with SNMPv3 work
3.4.2.1 Naming
3.4.2.2 Access Control
3.5 Expression evaluation MIB issues
3.5.1 implementation experience
3.5.2 impact of SNMPv3 support
3.6 Notification MIB
3.7 Common issues
3.7.1 integration with other mibs
3.7.2 conformance issues
3.7.3 representing ownership
3.7.4 security considerations
3.7.5 implementability
3.7.6 deployability
3.7.7 internationalization
4. Future work
5. Closing
5.1 Review of action items
5.2 Planning for possible interim meeting
5.3 Discussion of next meeting
Reading Material
ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-event-mib-01.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-express-mib-02.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-framework-00.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-mgt-target-mib-01.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-notify-mib-01.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-script-mib-01.txt
1) Technical Presentations
Several of the document authors gave presentations on specific issues relating to the DISMAN work.
1.1) David Levi -- Trap Forwarding Application
The SNMPv3 framework does not allow a trap receiver application to receive all information related to a given trap PDU, particularly the original source address, if that trap was received via at least one trap forwarder. The 'ContextSNMPEngineId' (where info came from), doesn't change from hop to hop, but 'AuthSNMPEngineId' does change from hop to hop. It is not possible with the Proxy MIB to determine the original source address.
A proposal was made for proxied traps, to add a varbind in the trap identifying the original source address. The WG decided to defer the issue to the SNMPv3 working group for resolution.
1.2) Bob Stewart -- Expression MIB Implementation Experience
Implementing the Expression MIB is non-trivial. Many people were involved in the agent implementation effort, which took approximately 18 person-months to complete. This implementation experience resulted in many clarifications, reflected in the latest draft.
Status of the new draft:
· A new object has been added to indicate if an expression object is identified with a partial OID (and should be 'wildcard-expanded'), or if the OID is complete (and should not be 'wildcard-expanded').
· Access control issues need to be resolved. New comments in the MIB are needed to clarify access control.
· A 'changedElement' expression operator was added. This is needed to flag a changed object value, which can't be done with arithmetic operators for all object types (e.g., OID). Operation of integer deltas does not change.
· The Editor needs to finish the Event MIB to fully support the Expression MIB.
· A change to the Event MIB was made to use Notifications to log errors.
· Event MIB error handling needs some clarifications
· Expression MIB needs an overview, and more front-end prose describing NMS constraints and usage guidelines.
The WG discussed the merits of these changes and the Expression MIB in general. The use of notifications to flag expression errors is controversial. It was noted that work on universal logging is being done in two other working groups. The new draft will be discussed further on the mailing list.
1.3) Juergen Schoenwaelder -- Security Issues & Terms
Security profiles control configuration and execution access to scripts and expressions, and a script needs to be restricted to specific services on the runtime system.
The security profile of the script installer (script owner) is used to specify who can run the script and which 'execution security profiles' may be used (by which users) to execute the script. The installer profile may be different than the execution profile.
The VACM MIB is used to control configuration and execution access. The WG agreed that a description of how to use VACM to secure a DISMAN system should be added to the document.
A unix-like "SETUID" capability is needed to allow a third party to start a script, running under security profile of the script owner, not the script invoker. During the course of the meetings, a great deal of discussion focused on the security details of many such configuration and execution scenarios.
The DISMAN MIB(s) should not assume that a particular security model is used, which means the security profile information must be available in the MIB(s).
The WG should establish guidelines for configuring user names, and a 'mapping table' indicating context name to local user/group name on the execution target. Mappings for 'owner-to-local-user' and 'invoker-to-local-user' are needed.
1.4) Steve Waldbusser -- Framework Terminology Issues
A distributed system can be modeled as three logical components:
+-----------+ +----------------+ +------------------+
| |+ disman | |+ target | |+
| Higher || user | Distributed || user | Target Agent ||
| Layer || ------> | Manager || ------> | or Network Host ||
| Mgmt || | [users] || | [users] ||
| App || | [scripts/exprs]|| | [scripts/exprs] ||
| || ++---------------+| | [managed system] ||
++----------+| +----------------+ ++-----------------+|
+-----------+ +------------------+
Each of these logical components can be physically located on the same machine or different machines.
The "disman user" and "target user" are identified by more than a user ID:
· disman user: SNMP Security Model, Security Name & Key; allowed to install and manage disman functionality on specific distributed managers
· target user: SNMP Security Model, Security Name & Key; allowed to invoke specific DISMAN functions on specific targets
Tokens are used to describe all necessary information needed to perform particular operations on behalf of the disman user.
SNMPv3 makes it clear what these objects are:
· securityModel
· securityName;
· set of targets;
· set of access rights for those targets
There may be a set of tokens per target user of each script or expression. Invocation properties of a script or expression must be attached to the invocation button, not the configuration of the control rows.
A script installer may wish to limit the set of tokens that a particular script invoker may use (for that script). Token subsets are constant subsets, and to create a different set of credentials, new tokens must be created.
To utilize a DISMAN system, first a disman user configures a Distributed Manager by installing some scripts, some user names, some security tokens, and then associating scripts to tokens, based on the functional requirements of the script, and the profile of each target user.
Remaining Issues:
a) After a script is configured, a Script Invoker can start the script running. Is the 'Script Invocation Identity' the ID of the owner or the invoker?
b) The Expression MIB has notion of invoker and owner as well. The WG needs to develop one VACM-based DISMAN security architecture. What changes to the various MIBs are needed?
c) There may be several tokens available per user per script. How do you tell which tokens to use? Care should be taken to avoid an explosion of configuration rows needed on each Distributed Manager (e.g., one token per target-user, per target, per target-context, per target-MIB-view).
d) What if User A installs a script; user B wants to reuse the script with his/her own tokens? Should this be supported?
e) How do you tell which tokens are used, if different values of contextName are needed to access a given MIB object on a target system?
f) How should the combinations of credentials be supported?
- owner
- subset of owner
- invoker
- union of owner and invoker
1.5) David Levi & Juergen Schoenwaelder -- Session Control
The Script MIB needs to support some forms of script scheduling:
one-shot -- invoked once when 'invoke button' is pressed
periodically -- like unix 'cron' command
time-of-day -- like unix 'at' command
A new table to support the time-based scheduling will be added to the Script MIB.
The WG decided not to support script invocation based on reception of an SNMP notification. Instead, a script may listen for notifications in a platform-specific, proprietary way. It is likely that only one script will be able to listen for notifications on some platforms. This issue may be addressed in a future version of the Framework document.
2) Issues List Follow-up
After all presentations, the WG Chair led a discussion of issues related to all documents in progress. The topics were ordered, based on complexity:
- Quick List (2.1 .. 2.10)
- Tough List (2.11 .. 2.17)
2.1) Framework draft
The Framework draft has expired and needs to be updated.
Action Item (Steve Waldbusser): Align terms in FW draft with the new terminology tentatively accepted by the WG. Add detailed example of configuring VACM and the script MIB to maintain security and usefulness.
2.2) UTF-8
The WG should examine all strings for proper application of UTF-8 based strings. It should be used for true internationalization, not localization, since many options make communication more difficult, not easier.
2.3) Event MIB Terminology
The terminology in the Event MIB (and possibly the Expression MIB) needs to be aligned with the (new) terminology in the Framework draft.
2.4) Script Return Status Codes
The script return codes are defined with inline syntax, as opposed to the use of a textual convention to identify the status codes. This should be declared as a TC only if it is appropriate to ever export them for use in another MIB module. Since this is likely to occur in the long-term, due to the augmentation of the Script MIB, it may be better to move the return code definitions to a TC definition now.
2.5) Script Download Compliance
The Script MIB compliance statements need to be refined to allow:
- 'push' downloading of scripts (via SNMP) is optional
- 'pull' downloading of scripts (via URL) is optional to support a special class of disman agent with only pre-defined read-only scripts
2.6) Suspend/Resume Commands
Should the Script MIB support suspend/resume 'script states', and therefore allow (or require) a script to support these commands? This issue was hotly debated, and WG consensus for this feature has not yet been established.
It was noted that these commands require 'signals' between the DISMAN platform and a running instance of a script, and that the suspend and resume signals are just two on a list of possible signals that a user may wish to send to a running script instance. A DISMAN implementation must send such signals to scripts in a platform-specific way.
If a script to chooses to suspend or optionally ignore the signal, how does an NMS know the suspend command worked or not? The response to the SetPDU will probably indicate success, even if the script instance actually ignored the signal.
2.7) SmCodeTable Line Numbers
Should the smCodeTable allow non-contiguous line numbers during a sequence of smCodeTable SetPDU, i.e., script line insertions.
Resolution -- relax the rule requiring line numbers to be contiguous, but do not allow the insertion of lines, i.e., smCodeTable insertions must be in ascending order in successive SetPDUs.
2.8) Process IDs (PIDs)
A unique invocation identifier is needed for each instance of all scripts, regardless of running state. The DISMAN platform should provide an automatic PID generator, i.e., the NMS must not be involved in the PID generation, but the PID value should be available via the Script MIB.
The agent should allow smLaunchStart to be set to zero, which indicated that the system assigns the PID. [ed. - open issue: does this mean the agent has to support NMS PID generation, or is it optional, or completely disallowed?]
2.9) smLanguageIndex
Should the smLanguageIndex be a table column instead of an INDEX component, and allowed to be zero?
[ed. - It's not clear which tables are affected by this change; could be the smScriptEntry, smCodeEntry, smExecEntry, and smRunEntry.
The WG agreed that the script language should be indicated in a column rather than an INDEX. If the column value equals zero, then a hardcoded script language is implied and there is no need to specify it. This feature was debated, since the default language must be specified in the smLanguageTable anyway. Allowing the value zero means that another MIB object will be required to indicate the mapping between the default (0), and some language in the smLanguageTable. It's better to conserve MIB objects and make the language identifier reference a real smLanguageTable entry.
This issue will be discussed further on the mailing list.
2.10) Deferment of NV-Storage
A feature will be added to the Script MIB, to allow an agent implementation to defer NV storage of a script until all the code lines are downloaded. This will be dome by adding an editing state to the scriptStatus. This feature also allows the agent to determine the actual NV-storage size, instead of wasting resources writing partial scripts to NV-storage.
2.11) Script Results
Can the valueTable in the Expression MIB be used to make script results visible? This MIB uses a discriminated union of MIB object results instead of a string result.
This issue will be discussed further on the mailing list.
2.12) Logging MIB Status
Should these features be developed or dropped from the first release of DISMAN documents:
- error logging feature
- notification log
This issue will be discussed further on the mailing list.
[ed. - end of day 1; start day 2]
2.14) Naming Scope
A suggestion was made to use naming scope to isolate each user of the scripting capability, instead of providing a multitude of launchpad buttons for each script. There were objections to this approach, based on available tools and experience (e.g., RepeaterID).
Resolution: The namingScope (contextName) will not be used to isolate each user's view of the Script MIB or Expression MIB.
2.15 Script MIB Discussion
The WG discussed the MIB structures required to implement the desired script/expression VACM-based access control/security features. The following is a summary of the MIB components:
· table of scripts
- INDEX script-id, scriptOwner
- script.*.owner -> r/w (for group of owner)
· launch pads
- many buttons to the same script allowed
- launch.*.owner -> r/w (for group of owner)
- launch.start-button.owner -> r/w (for some others) [optional]
· smRunTable
- one per running script
- run.*.owner -> r/w for that owner
- run.*.owner -> r/w for others (optional) (also applies to tokens : token.*.owner)
· tokens
- associated with the launch pad, not the script
- INDEX - owner, launchpadId, tokenInstanceId
- tokens used on individual targets
- script to launchpad mapping must be restricted to the same group
- public-launchpad: issue is restricting the tokens used with the script instance
- combining privileges needed to save rows?
- combining privileges may produce security holes & unexpected privileges; already behind schedule 9 months, perhaps add this in a later release.
· mapping: owner --> 'local tokens'
- needed to execute local operations
- mapping: owner --> local tokens
SecurityLevel
SecurityName
- For expressions, this recorded at row-create-time, i.e., whoever activates the row that evaluates the expression.
· tokenTable
- MIB objects:
INDEX [tokenOwner, tokenIndex];
tokenOwner string
tokenIndex int
tokenSecurityName string
tokenSecurityLevel int
tokenSecurityModel int
tokenSecurityKey string
- used to limit the list of target systems
- why do we need this?
don't have a way to delegate write access to the SNMPv3 targetTable (targetTable == an access right on a given system).
- can the SNMPv3 targetTable be used instead of a DISMAN token table? V3 needed for trap destinations;
Issues raised:
- Does the requirements for proxy cover the requirements of DISMAN?
- Does admin for proxy cover the admin requirements of DISMAN?
- Resolution: use the SNMPv3 target tables; use the tags feature to subset the target list.
2.16) Expression MIB
To support the VACM-based DISMAN security features, the expression owner needs to be part of the expression index. The details of this change were not explored, but this discussion will continue on the mailing list.
2.17) Document Complexity
There was concern expressed about the complexity of the DISMAN technology, and conveying that complexity to users in the documents. More examples are needed, starting with simple applications and then introducing more complex applications.
The Expression MIB needs examples written which show how the main features are used, with both simple and complex expressions.
3) Conclusions
3.1) Action Items
· The deferred issues (mentioned throughout the minutes) will be discussed on the mailing list.
· The DISMAN drafts will be updated to reflect the changes agreed upon at this meeting.
· The (currently expired) Framework document will be resubmitted.
3.2) Interim Meeting
A possible interim meeting was discussed again. Location was not an issue, but the proposed locations are all in the USA:
San Jose, CA
Chicago, IL
Houston, TX
There is not strong interest in an interim meeting at this time. Many principal members of the working group met twice before the IETF meeting to discuss the documents in detail. This interim meeting approach may be repeated again before the next IETF meeting in Los Angeles, CA.
DISMAN Security Profiles
DISMAN - Overview of Technical Issues
Roster not received