NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 20-Aug-98
Chair(s):
Randy Presuhn <rpresuhn@bmc.com>
Operations and Management Area Director(s):
Harald Alvestrand <Harald.Alvestrand@maxware.no>
Bert Wijnen <wijnen@vnet.ibm.com>
Operations and Management Area Advisor:
Bert Wijnen <wijnen@vnet.ibm.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: ftp://ftp.peer.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 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 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 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:
Define a Script MIB
Define a Scheduling MIB
Define a Threshold Monitoring MIB
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:
Done |
|
Post Internet-Draft for Threshold Monitoring MIB. |
Done |
|
Meet at the Montreal IETF meeting to discuss charter and review the Threshold Monitoring MIB Internet-Draft. |
Done |
|
Post Internet-Draft for Framework document. |
Done |
|
Post Internet-Draft for Script MIB. |
Done |
|
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. |
Done |
|
Meet at the IETF meeting to discuss Internet-Drafts and issues that come up on the mailing list. |
Done |
|
Submit final versions of Internet-Drafts for Script MIB and Schedule MIB document for consideration as Proposed Standards. |
Jul 98 |
|
Submit final versions of Internet-Drafts for Expression, Event and Notification MIB documents for consideration as Proposed Standards. |
Aug 98 |
|
Agree on charter revisions for future work. |
Sep 98 |
|
Submit final version of Internet-Draft for Framework document for consideration as Proposed Standard. |
Internet-Drafts:
· Definitions of Managed Objects for the Delegation of Management Scripts
· Distributed Management Framework
· Definitions of Managed Objects for Scheduling Management Operations
· Definitions of Managed Objects for Remote Operations Using SMIv2
No Request For Comments
Meeting of the Distributed Management (disman) working group
at IETF-42 Chicago (Thu 8/27/98 0900-1130)
Reported by: Dale Francisco (dfrancis@cisco.com)
Randy Presuhn, Chair (rpresuhn@bmc.com)
For more information on the disman wg, please see:
http://www.ietf.org/html.charters/disman-charter.html
Randy began the meeting with a brief review of the agenda:
Administrative matters 10 min.
Status of current work 20 min.
Technical presentations 1 hr.
Relations with other wgs, charter discussion 1 hr.
Wrapup 5 min.
Status of Current work
======================
The script MIB and schedule MIB are with the IESG. Bob Stewart did new drafts of
Notification, Event, and Expression MIBs--please submit comments on these items. The
question arose as to the appropriate time for wg last call on these MIBs. A show of hands
revealed that only 5 people have read the documents so far.
Bob Stewart mentioned that he had received a few private communications on Notification
logging, in particular a suggestion that it might be useful to have separate logs per manager
(easier filtering, less computationally expensive than determining access privileges on a
per-entry basis). Randy stressed the need to be clear on the security implications of logging.
A couple of people mentioned the advantages for scalability and disconnected operation
that notification logging would provide.
It was decided that the deadline for comments on these three MIBs would be six weeks
after the meeting, and Bob committed to turning the documents in no more than two weeks
after that time. the goal would be last call at the end of October.
Steve Waldbusser discussed the status of the Framework document. At this point, it's
mostly minor edits and fixes of typos. Steve urged as many people as possible to read it.
Six people were willing to read it within the next month, and 12 within the next six weeks.
It was decided that mid October would be the final comment date, with end of October for
final revised docs.
Technical Presentations
=======================
1) Remote Ping and Traceroute through a MIB
Ken White, IBM (wkenneth@us.ibm.com)
See draft-ietf-disman-remops-mib-01.txt.
There are many enterprise solutions for remote ping, but not for traceroute. The intent of
this work is to provide an interoperable MIB for both ping and traceroute remote operation.
The current draft has many improvements based on experience and suggestions. A Results
table approach was taken to overcome the mismatch between the minimal requirement for
SNMP maximum message size (484 bytes) and potentially larger strings from traceroute results.
Future work includes:
- consider traceroute over ip-multicast
- IPv6 implementation of ping
The REMOPS-MIB consists of 2 notifications, 5 scalars, and 4 tables with 21 objects. Two
tables are used to configure the remote operations, and two to store the results. The target
address can be a DNS name, IPv4 address, or IPv6 address. Features of the remopsPingTable
and the remopsTraceRouteTable (application configuration) include:
- entries created and deleted via RowStatus
- remopsPingOperStatus to indicate status of request
- remopsPingOwnerIndex to allow v3 VACM
Two scalars are used for controlling resource use by the REMOPS-MIB instrumentation. MaxConcurrentRequests limits the number of concurrent actions, and PurgeTime (the amount
of time a result remains in the ResultTable after the associated request completes) can be used
to keep the ResultTable within size constraints.
During the question and comment period, Bob Stewart suggested that the best way to think
of this was as an application that happens to have a MIB controlling it.
A question arose as to whether DNS name support was really needed. Some suggested
that the DNS names of intermediate nodes should be returned because that's how traceroute
worked, but others argued that many embedded systems may not have DNS support. Ken
said that 95% of the time DNS support wasn't needed, but it was there as an option (off by
default).
Finally, there was discussion of the trade-offs between a dedicated remote operations MIB
and a script MIB approach. Ken felt that the ping and traceroute MIBs were (obviously)
much simpler to implement and less resource intensive, and that they could be used in
places where there was no script MIB support.
2) Implementation of SMX
David Levi (levi@snmp.com)
David Levi gave a brief discussion and slide presentation on SMX (Script MIB Extensibility),
a research project of Jurgen Schonwalder, who was unable to attend the meeting. Please see www.ibr.cs.tu-bs.de/projects/jasmin/ for more information.
Jasmin (JAva Script Mib ImplementatioN) Goals:
- Evaluate the current script MIB proposal by implementing and using it.
- Use the JVM as the primary runtime system.
- Create an architecture that allows plugging in alternate runtime systems.
- Share implementation experience with the disman wg.
Internal architecture:
SMX is the protocol for communication between the runtime systems (which are actually
executing scripts) and the SNMP Agent.
SMX protocol details:
TCP is used between runtime systems and the SNMP agent. Messages contain simple
ASCII encodings similar to SMTP, HTTP; there is an assumption of the existence of a
shared file system between the SMX peers.
The SMX peer inside the SNMP agent sends commands to the runtime system. The
runtime system responds to commands or sends asynchronous messages.
Enforcement of integrity and security is the responsibility of the agent.
The SMX protocol is simple (a small number of commands) in order to make it easy to
create new runtime systems. The format of messages is defined using the ABNF (RFC 2234).
There are 6 commands (hello, start, suspend, resume, abort, and status) which are sent by
the SNMP agent. There are 15 reply codes sent by the runtime system (which could be Java
VM, Tcl, other). In the current implementation, most replies are sent in response from a
SNMP subagent written in C, based on EMANATE (though it doesn't use the data structures
generated by the MIB compiler). Currently, it's about 12,000 lines of commented C code.
Jasmin Java Runtime:
Based on JDK 1.1.5, the runtime system allows multiple scripts with the same runtime
security profile to execute.
The system is written in 99% pure Java (with a little C to get at a cookie at startup). The
system is available for testing on the net, at osborne.ibr.cs.tu-bs.de port 161
Future projects:
- Implement a Tcl runtime system.
- Implement some useful real-world management scripts.
3) Bulk Transfer
Bob Stewart (bstewart@cisco.com)
(no slides)
The main point of this discussion was to describe the Bulk Transfer MIB concept and to
present and solicit ideas on future work.
The purpose of the Bulk Transfer MIB is to deal with complaints about the slowness of
retrieving large amounts of data with SNMP, while maintaining the underlying data
structures and MIBs. The basic idea is that the MIB is used to specify which objects
(in other MIBs) are of interest, then let the instrumentation write the data to a file for
quick retrieval. There are different file formats available, including ASCII and binary.
Some of the nice features of the Bulk Transfer file format include:
- Unlike GetBulk, tables are squared up (there's an indication of NULL for missing values).
- Redundant parts of OIDs are removed to cut file size.
Since not all systems have file systems, a separate FTP-CLIENT MIB was implemented that
allows sending the file to a particular server instead of storing it locally. The concept of an
"ephemeral file" (a file that exists only one buffer at a time) is the glue between BULK-
TRANSFER and FTP-CLIENT.
Summary: This is a very different way of getting SNMP data, particularly appropriate to
frequently polled, large tables.
Bob stated that these MIBs would be available soon at a to-be-announced URL. There was
general consensus that this sort of application was something that would be useful across
many working groups.
4) Framework Document (draft-ietf-disman-framework-02.txt)
Steve Waldbusser (waldbusser@ins.com)
(no slides)
Steve started by saying that he was mostly here to ask questions. Disman describes 8 to 10
services, one of which is the Credential Delegation Service (CDS). Since there hadn't been
any discussion of CDS since the last meeting, he wanted to discuss issues and go out with
marching orders.
CDS is required when a management station talks to a distributed manager which in turn
talks to a target agent. The management station uses authentication to talk to the distributed
manager. But what does the distributed manager use to talk to target agent? Without CDS,
it could only use credentials stored in the distributed manager, with no relation to particular
management stations. The problem is there's no mean of divvying them up--if available to
one "good guy" MS, it's available to all (this is spelled out in the Framework). Credentials ==
keys (identities + passwords). Without CDS, it's all-or-nothing access to whatever rights
the distributed manager has. So it only works for a secure distributed manager.
One solution includes a credential store (MIB) within the distributed manager. So, for
instance, some rows in the REMOPS MIB would have a fragment from the CDS-MIB.
A practical IETF question: How to add this MIB fragment to already-progressed MIBs?
a) Add CDS to existing MIBs (all MIBs that want to use CDS would need to add it--i.e.,
all 5 disman MIBs)
b) Define CDS today anyway, and add it to selected MIBs when possible.
c) Separate the current draft into a Framework document and a CDS MIB document.
Randy said that it was unquestionable that disman needed CDS; the question was, where to
put the MIB definition? For that set of MIBs that need it, what is the strategy for getting
there? He suggested that the CDS MIB probably belongs in the Framework, and that the
strategy might be to recycle out-the-door MIBs when available, and fix in-progress ones now.
There followed a discussion of the pros and cons of separating CDS from the rest of the
Framework into a new doc, keeping the Framework MIB-free. Bert Wijnen, area director,
after hearing from Steve and David Levi that the docs could be separated in a week, inclined
towards separate documents. The working group agreed.
Relations with other WGs
========================
Randy said that he hadn't yet had a chance to discuss with the AgentX or v3 working groups
any disman interoperability questions. But there was a question whether it was possible to
do a disman implementation in a "pure" AgentX environment; the main concern was whether
there would be access to the isAccessAllowed() ASI.
The best way to lay out the discussion that followed is to attribute it to speakers (paraphrased,
not exact quotes):
Randy: Should we demand support from AgentX?
Bob Stewart: Outline the problems, make them clear to AgentX, then let
AgentX do what they want.
Waldbusser: I'm offended that we need those things--it breaks SNMP as
we know it.
Randy: A command responder needs access to isAccessAllowed().
Bob Natale (AgentX chair): Post it to the AgentX list.
Randy: What I wanted to get here is that some of the postings on the
mailing list have insisted that these are disman requirements.
So, is it the sense of the group that this is a requirement, or
that there are just a few members
that think we need it?
Waldbusser: Up to this point, disman has been just another SNMP
application--now we're talking about special privileges.
Bob Stewart: We're talking about the benefits of local access to MIB data,
not a _requirement_. isAccessAllowed() is a good example.
Bob Natale: The A-Ds say that cooperation is needed among the entity,
v3, agentx, and disman working groups. I propose this
consensus: For the purpose of implementing disman MIBs,
availability of isAccessAllowed() and knowledge of
operation invoker parameters is highly desirable; AgentX
may be an appropriate vehicle for accomplishing that; and
we want to investigate.
Bob Stewart: If we're implementing in AgentX, we absolutely need the
capability.
Randy: No question...but is AgentX the desired vehicle?
Jon Saperia: Is there a need for this in a subagent?
Randy, Bob: Yes.
Bert Wijnen: But is this really an AgentX issue?
Randy: If it's not tied to the AgentX API, it'll get real messy
because of synchronization problems.
Bert: AgentX wasn't supposed to worry about security issues.
After this discussion, it was the consensus of the working group that Randy should take the
action item of posting to the AgentX list a clear statement of the problem.
Charter updates
===============
Target for end of comments: Oct 16, 1998
for revised drafts: Oct 30, 1998
Possible additions to charter:
Remote Operations MIB--The consensus was that about 8 interested people wanted to
see it happen, and 2 people would commit to help with writing and reviewing the documents.
So we'll add it to the charter.
Script MIB extensibility (SMX)--We don't have enough understanding yet, so let's not
add it. More investigation is needed--defer to next meeting consideration of adding it to
the charter.
Bulk Transfer--The consensus was that this was really core, not disman, work. Action
item for Bert Wijnen: Where should we kickoff discussion of this topic?
Wrapup
======
We will meet at the next IETF, yes?
Consensus of working group: Yes!
Working Agenda
Jasmin - Java Script MIB Implementation
Remote Ping and Traceroute