NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Jon Saperia <saperia@networks.bgs.com>
Cheryl Krupczak <cheryl@empiretech.com>
Applications Area Director(s):
Keith Moore <moore+iesg@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
General Discussion:applmib@emi-summit.com
To Subscribe: applmib-request@emi-summit.com
Archive: ftp://ftp.emi-summit.com/applmib/applmib-archive
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).
The activities of the working group will take place in two stages. The first will focus on the development of a System Application MIB that will not require applications to write additional instrumentation code. This generic information will serve as a base for the follow-on Application MIB which will contain additional information that will require applications to write additional instrumentation. The schedule below describes the schedule for the development of the System Application MIB.
Goals and Milestones:
· Definitions of System-Level Managed Objects for Applications
· Definitions of Managed Objects for WWW Servers
Application MIB Working Group Minutes
Reported By: Jon Saperia and Cheryl Krupczak
The Application MIB Working Group met twice during the week of April 7, 1997. On Monday, it met for two hours and on Wednesday for one hour. The agenda as previously posted was:
I. Mailing List Information Discussion II. Charter and Other Issues III. Architectural Presentation of the Work of the Application MIB working group and discussion of the current status of each of our three documents: draft-ietf-applmib-sysapplmib-07.txt draft-ietf-applmib-wwwmib-02.txt draft-ietf-applmib-mib-02.txt IV. Discussion and review of WWW MIB V. Discussion and review of the Application MIB
Harald Alvestrand, our new Co-Area Director, reminded the group that a valid, accurate charter and schedule must be in place in order for the working group to continue to function. We agreed to work on this and update as necessary.
The working group agreed to take up the WWW Mib on Monday since several interested parties were not going to be available for the Wednesday discussion.
The first presentation was of the general architecture of the working group's activities and the inter-relationships between our work and other extant MIBs. After Jon Saperia described the structure of our work and the architectural relationship of our MIBs, Cheryl Krupczak presented the status of the work on the System Application MIB and provided a detail description of the relationship of the various tables in the MIB. Harrie Hazewinkel made a presentation based on an earlier internet draft (draft-hazewinkel-appl-mib-00.txt).
The discussion focused in specific detail on those MIB objects in the System Application MIB, Application MIB, Network Services Monitoring MIB, Host Resources MIB, and WWW MIBs which overlap. The purpose of this discussion was to help clarify the Architecture and System Application MIB work already completed and create a common understanding so that we can continue the work of the Application and WWW MIBs.
Randy Presuhn briefly spoke about the Application MIB work, how its tables are laid out and how these relate to the System Application MIB. Detail discussion on this MIB was deferred until the Wednesday meeting so that we could take up the WWW MIB. Harold raised the concern that the Application MIB view is a per-process level view and not an application service point-of-view. A service level view is agreed to be a useful perspective and invites technical proposals on how to construct such a view.
It was later observed that the WWW mib is a service level view MIB, and the application MIB will add tables which allows for the mapping between the per-process and service level views. This approach will allow other service level view MIBs which might be developed in the future to connect with the application MIB.
Carl Kalbfleisch led the discussion of the WWW MIB. The primary discussion was on the scope of items to include in the MIB. The scope issues include:
· Service Level View · Documents Served Counters/Issues · Configuration Information · Protocol Level Information · Proxy Information
After some discussion, it was agreed that the current WWW MIB should focus on a service level view (which is how it is currently written). Several people recommended that it might be better to break the MIB up into pieces based on server [sub]type such as mail, http, ftp, etc. The authors agreed to look at those parts which are generic enough to go into this MIB with some clarification, or which parts, if any, should be moved to small, server-specific MIBs such as an ftp MIB.
A question was raised about whether we should include protocol specific MIB objects. The issue is could we represent request/response statistics at the protocol level in our service level view without delving too far down into the protocol and writing an HTTP Protocol MIB? It was agreed that those who have such an interest could take a detailed discussion of an HTTP MIB (from the protocol perspective).
There is some concern about Document Level Statistics in the WWW MIB. If we could write objects which are unambiguous and do not overlap with terms which are currently being debated, we might want to include them. For example, a count of the number of Document Open Attempts might be helpful in debugging a service. People who are interested in such objects should write some examples so that we can evaluate if there is sufficient benefit for their inclusion in an already large MIB.
The rest of the discussion focused on the mapping issues related to the service level view of the WWW MIB and the Application MIB's per-process view. For example, there could be a single process such as an HTTP daemon which is serving multiple virtual hosts. There could also be
several processes working together to provide service.
On Wednesday, Randy Presuhn led a discussion of Application MIB Issues:
· stdin/stdout/stderr · counter 64 · file open Mode · open file name as index · connection endpoint id · transaction stream statistics · www MIB approach · hybrid · arm · traps · dependency · logging · stdguide requirements · conformance · timed (date and time)
After some discussion, a proposal was made that we follow the interface MIB lead and have one 32-bit counter and a 64-bit counter for those objects which are "high performance." This allows implementations to choose the most effective approach for their environment.
We agreed that for the file open, we would keep things simple and just report what has been open for a write operation.
There is an issue with an open file name as an index, since some names would not fit using our current smi. It was agreed to take this offline.
It was agreed that we would allow connection endpoints to be expressed as "other" and "unknown" and to allow for applications that may not have endpoints.
There was some discussion on the transaction stream statistics and which approach we should take. It was agreed that what a unit of work is, is up to the specific application. In particular some protocols have a hazy line about what a transaction is. There may be some help in RFC1611 for development of tables based on different kinds of services which count transactions.
It was agreed that the issue of traps would be taken up on the mailing list.
Logging and stdguide requirements need to be added to the document.
The remainder of the meeting continued the discussion of how applications and per-service and per-process level statistics could be related with tables in the Application MIB. Diagrams will be posted separately to the mailing list.