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!