Meeting Minutes for Application MIB Working Group Meeting Tuesday December 9, 1997 Held at 40th IETF - Washington D.C. 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 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 files 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 there was 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 1 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 which 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.