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.