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.
