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!