2.1.3 Application MIB (applmib)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 27-Oct-97


Jonathan Saperia <saperia@networks.bgs.com>
Cheryl Krupczak <cheryl@empiretech.com>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>

Applications Area Advisor:

Keith Moore <moore@cs.utk.edu>

Mailing Lists:

General Discussion:applmib@emi-summit.com
To Subscribe: applmib-request@emi-summit.com
Archive: ftp://ftp.emi-summit.com/applmib/applmib-archive

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).

The activities of the working group will take place in two stages. The first will focus on the development of a System Application MIB which 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:

Dec 95


Meet at Dallas IETF.

Jan 96


Post initial Internet-Draft of the Application Mib.

Feb 96


Post revised Internet-Draft.

Feb 96


Interim meeting to work on MIB.

Mar 96


Review Internet-Draft at LA IETF.

May 96


Post revised Internet-Draft.

Jun 96


Meet at Montreal IETF.

Jul 96


Issue final Internet-Draft.

Sep 96


Submit Internet-Draft to IESG for consideration as a Proposed Standard.


No Request For Comments

Current Meeting Report

Meeting Minutes for the Application MIB (applmib) Working Group

Reported By Jon Saperia

The meeting had a short agenda since most of the working group task items have already been completed. The items on the agenda were:

1. Current status of the System Application MIB

2. Review of Application MIB Issues

3. Review of the World Wide MIB Status

4. Implementation

The System Application MIB has passed the IESG and is in the process with the RFC editor and will be published as a Proposed Standard. There are no outstanding issues or items for this area of work.

The majority of the meeting was taken with Randy Presuhn reviewing a list of issues raised on the mailing list on Monday by Juergen Schoenwaelder. Randy began by stating that service level aggregation of transaction statistics would be nice with the tables we have, if possible [see discussion below for details on various issues associated with table aggregation].

There were several issues discussed and agreed to in Munich that did not get posted in the newest draft. Randy will make sure these items are included in the revision to go out after this IETF.

1. Service Instance to Service Name and Service Name to Service Instance tables are viewed as overkill by Juergen. The justification for the inclusion of these tables was to be able to find out what processes are included in a service without having to read through all the processes - to capture the one-to-many and many-to-one and sometimes many-to-many relationships. Juergen is not opposed to the function, just the need for all the tables. A discussion of the justification was made and it is necessary to look up services based on the indexing scheme used thought the MIB, and since there is no extra implantation cost for bi-directional lookup, we will keep these tables.

2. The running application element to service instance table is empty. It was corrected in Munich and will be fixed in the next draft.

3. The question was raised if the open files reflected in the MIB should be only the important ones or all open files, even those that are very temporary. There was consensus that all open files should be reported, not just the short lived ones.

4. Open files and open connection tables are similar and could be merged into one with open channel attributes. Randy mentioned that he had thought about that -- would be receptive to collapse to reduce overlapping objects. So we will try to collapse them and put a proposal out to the mailing list. This will result in two tables extending the channel table to capture file and i/o specific attributes.

5. There were a number of discussions about consistency of tables throughout the MIB. One such case was that there was an open file cross-reference table but no open connection cross-reference table. There seemed to be consensus that consistency was a good thing but we were also concerned about the number of objects versus complexity for the management software. This item will be taken up on the mailing list.

6. The question was raised about how to make the truncation algorithm clearer. Truncation is an issue; therefore, you must use this algorithm. A heads up about it and why it is there will be added to the document.

7. There is no network connection cross-reference table. What is needed asked Randy? A good use of the MIB is to match up a transaction with what is going on over the inter- faces, etc. Having the kind of table that Juergen is talking about would simplify that. Randy mentioned that this would cause a lot of registration and de-registration traffic in sub-agent technology. This table would need running application element with the transport domain and address and then the local unique identifier. The file cross-reference table has the same problem with regard to sub-agent technology. There was a desire to put this out on this list with a straw man position to delete the files table and not add the other cross reference table to make the MIB consistent.

8. Seek operations. Why is the number of seek operations on a file useful for management? There was discussion but not enough information to reach consensus so it will be taken up on the mailing list.

9. Why do we need a former connection table and no former file table? Should these things be merged into a closed connections table? In the case of a web server, the open file table will have entries added very rapidly. In the case of a conventional database server, the open file table and file history table will change very slowly. If there is reason to have information about recently closed connections, then you might also want to have recently closed files table as well. This will also be taken up on the list.

10. There was consensus to open file mode to reflect current mode of the file rather than mode the file was opened in.

There was insufficient time to resolve the remaining issues during the one hour meeting time. It was agreed that the issues discussed at this meeting which require mail list discussion along with those that we did not have a chance to raise/resolve will be presented on the mailing list in a few business days.

Randy will send the topics out with one subject per mail message to help us keep the discussion in focus. The goal is that the remaining issues will be resolved in about three weeks.

Carl Kalbfleisch provided a review of the changes that were made to the WWW MIB after Munich IETF. Each of which had proposals that were sent to the mailing list and no objections were raised. The issues were:

1. Error Attributes

2. Support for Proxy

3. Split wwwDoc Top N Stats

4. Rename WWW Entity Table

5. 64-bit values

6. Compliance Statements

The changes were applied to the document. For additional details please see the mailing list archives.

The final remaining issue is an editorial one where we need to remove a comment to bring wwwServiceIndex in alignment with the Application MIB since this has been done.


None Received

Attendees List

go to list

Previous PageNext Page