Editor's Note: These minutes have not been edited. Application MIB Working Group Minutes 38th IETF - Memphis Reported By Jon Saperia and Cheryl Krupczak The Application MIB Working Group met twice during the week of April 7th. On Monday it met for two hours and on Wednesday April 9th for 1 hour. The agenda as previously posted was: Mailing List Information Discussion Charter and Other Issues Architectural Presentation of the Work of The Application MIB working group and discussion of the current status of each of our 3 documents: draft-ietf-applmib-sysapplmib-07.txt draft-ietf-applmib-wwwmib-02.txt draft-ietf-applmib-mib-02.txt Discussion and review of WWW MIB 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 groups activities and the inter-relationships between our work an 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 could continue the work of the Application and WWW MIBs. Randy Presuhn briefly spoke about the Application MIB work and how its tables were laid out and how these related to the System Application MIB. Detail discussion on this MIB was differed until the Wednesday meeting so that we could take up the WWW MIB. Harold raised the concern that the Application MIB view was 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 invited 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 is going to add tables which allows for the mapping between the per-process and services 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 Klbfleisch lead the discussion of the WWW MIB. The primary discussion was on the scope of items to include in the MIB. The scope issues included: 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 to see which parts 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 a detailed discussion of an HTTP MIB (from the protocol perspective) could be taken off line by those who had such an interest. There was some concern about Document Level Statistics in the WWW MIB. If we could write objects which were unambiguous and did not overlap with terms which were 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 to 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 as 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 interfaces MIB lead and have 1 32bit counter and a 64 bit counter for those objects which are 'high performance' This would allow 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 issues with an open file name as an index since some names would not fit using our current smi. It was agreed to take this off line. It was agreed that we would allow connection endpoints to be expresses 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.