CURRENT MEETING REPORT Minutes of Application MIB Working Group (APPLMIB) Reported by Rick Sturm, U S West Approximately 50 people attended the Working Group sessions on December 6 and 7. Approximately one-third of those in attendance had not yet subscribed to the mailing list and therefore were not aware of some the discussions that had preceded this meeting. Initially, background information was presented covering mailing list details (over 400 currently subscribed), archive details, charter, and consensus items from discussions on the mailing list. The consensus items developed from the mailing list discussions were presented. Those in attendance at the meeting concurred with the items on the list of consensus items. The following are key points that were made regarding the consensus points. Relevant Work There were a number of questions regarding the need for this MIB in addition to the Host Resources (HR) MIB. Cheryl Krupczak reviewed the "Group 3 Report." This report had been previously posted to the mailing list and is available in the archive. The report discusses how the Application MIB and HR MIBs are related and how they can compliment one another. One point made in the meeting was that there is value in keeping the HR MIB and the Application MIB separate because the implementers of each will not necessarily be the same. Another issue that was raised regarding relevant work was about the relationship of this effort and the work being done within the Desktop Management Task Force on the Software MIF. It was explained that there has already been some contact between members of the Working Group and the Software MIF group. They had been invited to attend the meeting and give a presentation about the Software MIF. However, a conflict with a DMTF meeting precluded this. The Software MIF Working Group will be contacted and invited to share information with the APPLMIB Working Group via the mailing list. The mailing list will make it possible for the APPLMIB Working Group members to obtain the information in a more timely manner rather than waiting for a presentation at the next meeting of the Working Group. Relationship with the Network Services Monitoring MIB The Network Services Monitoring MIB contains a table: applTable. In order to avoid confusion, the work of this Working Group will include the sysAppl prefix before all of the objects in the sysAppl MIB. Using the RFC1565 MIB applTable is problematic for a generalized application for the following reasons: 1. The semantics of some of the objects in the table appear to require application instrumentation (for example, congested status). The Working Group has agreed not to require application instrumentation for the sysAppl MIB. 2. The sysAppl MIB will not be using pointers to X.500 type info. The information may be of value and we have discussed configuration information for the sysAppl MIB-details of which should be posted soon. The sysAppl MIB will contain at least some configuration information. The information can be obtained without application instrumentation. Examples of this include installation dates, and file sizes. 3. The applTable does not maintain a history of each invocation instance of the application. The sysAppl MIB table does. This is equivalent in difference between tables in the sysAppl MIB and the swRun Group in the HR MIB. The next item of business was the proposed structure for the application MIB. The first point that was made was that the work needs to be divided into two parts. The first part will produce a MIB that will collect information about the application without requiring the application to be instrumented, that is, it will extract the information from the operating system. This is called the SysAppl MIB. There will be only one SysAppl MIB per system. Jon Weinstock presented an outline of the structure of the SysAppl MIB. Information about this structure will be posted to the mailing list by January 1996. In addition, details about the proposed SysAppl MIB will be posted to the mailing list in early January. After the SysAppl MIB has been created, a second MIB will be created. The second MIB will utilize information provided by the managed application. In order to populate this MIB it will be necessary to instrument each managed application. There will be one copy of this MIB for each managed application. Therefore, this means that there will be multiple copies of this type of MIB on a system in addition to the single copy of the SysAppl MIB. The Working Group will not address this MIB until the SysAppl MIB has been created. Scope of the Application MIB It was pointed out that the it is intended that the application MIB will not be limited to just UNIX systems. It is intended that, to the extent that it is possible, this MIB will be operating system neutral. This is defined, in part, in the Consensus Points that are attached to these minutes. In addition, the SysAppl MIB will be limited to information related to fault, configuration, and performance management that can be obtained from the system without requiring the instrumentation of the managed applications. The following lists reflect information requirements that were expressed by people in attendance at the meeting. Fault Functions: o Status change notification and restart actions; o heartbeat; o running application discovery; o log history; o resource allocation failures; o running state; o error status-virus detection status; and, o application log pointers and format information. Element status change object - to know when the status of an application or one of its elements changes. This needs to be read/write: o failed installations; o license failures; o failed patches; and, o failed de-installs. Configuration: o Correct configuration/verification o current values - limit and high water mark o Prerequisites (associated parameters such as environment variables) o Access Control - who is allowed to use and how does the thing run (for example, suid) o Restart characteristics and parameters Performance Data: o Set of transport addresses open for use (pointers where appropriate to the tcpconn table, etc.); o Resources in use: o cpu; o memory; o open files; o disk space; o swap; o log files; o devices in use; and, o shared memory. In conclusion, there was consensus among those in attendance at the Application MIB Working Group meetings in Dallas that the proposed structure and strategy are appropriate and that work on the Application MIB should proceed based upon them. APPLICATION MIB WORKING GROUP CHARTER Co-Chairs Jon Saperia Rick Sturm Network Management Area Director: Deirdre Kostick Mailing List Information General Discussion:applmib@emi-summit.com To Subscribe: applmib-request@emi-summit.com Description of Working Group The Application MIB Working Group is chartered to define a set of managed objects for the monitoring and control of distributed applications. Specifically, these managed objects will focus on providing information about the configuration (including application dependencies and associations between applications), fault (including status information such as up, down, or degraded) and performance (including resource utilization) of distributed applications. The Working Group will only concern itself with the specification of MIB objects in the management areas defined above. It will not undertake to define details of implementation such as programming API's for the access to this information. The Working Group will consider existing MIB modules that define objects with similar functions or modules which can be used in conjunction with the Application MIB such as RFC 1514 (The Host Resources MIB) and RFC 1697 (The RDBMS-MIB). Goals and Milestones January 1996 o Post an initial Internet-Draft of the Application MIB for discussion o First Meeting of Working Group at IETF IN Dallas February 1996 o Interim meeting to work on MIB o Revised Internet-Draft made available for discussion March 1996 o Review Draft at Los Angeles IETF working group meeting May 1996 o Revised Internet-Draft made available for discussion June 1996 o Working Group meeting in Montreal July 1996 o Final revised Internet-Draft made available for discussion September 1996 o Submit Internet-Drafts to IESG for standards track evaluation Current Internet-Drafts o none. Consensus Points of the Application MIB Working Group Single Versus Multiple MIBs The consensus of the Working Group is that on each host where managed applications exist there will be a single instance of the Application MIB, regardless of the number of managed applications that exist on that system. That MIB will have entries based on which applications are, or have been, running on the host over given periods of time. Persistent Application Information There has been discussion about whether the information about managed applications that will be contained in the MIB should exist only while a managed application is active on a system or if it should be maintained across time, regardless of the presence, or state, of the managed application(s). The group consensus is that the information about the managed applications should persist independently of the application(s) that are being managed. This will permit the manager to query the status of the application, even when the application has failed. MIB Entry Persistence There has been discussion about whether MIB entries should only exist while a managed application is active on a system or if it should persist across time, regardless of the presence, or state, of the managed application(s). The group consensus is that the MIB entries should persist independently of the application(s) that are being managed. This will permit the manager to query the status of the application, even when the application has failed. Relevant Work The purpose of this group is to define an SNMP-based MIB within the limits defined by the group's charter. The group has agreed to examine relevant, existing work (e.g., the Host Resources MIB) and to build upon that work where appropriate. API Definition The group has reached consensus that the definition of APIs to support the implementation of the MIB is beyond the scope and charter of the group. Therefore, the group will not attempt to define APIs to be used with the application MIB, and will not presume that any particular APIs will be available or supported. Implementation Details The group has concluded that while it may be useful to hypothesize how the application MIB will be used or implemented, the definition of such implementation details is beyond the scope and charter of this group. Scope of the MIB - Distribution There is a desire to support distributed applications, but not at the expense of creating a MIB which cannot or will not be implemented. For this reason the consensus of the group is that the focus be on applications in a single host and add hooks wherever possible for additional growth. Features for distributed applications will be added to the extent they do not make the implementation overly complex. Application Definition For the purpose of developing the application MIB, the following definition will be referenced: an application is a set (segment) of executable code, that runs a single computer processor (or a set of coupled processors functioning as a single unit) which provides some type of functionality.