CURRENT MEETING REPORT


Minutes of Application MIB Working Group (APPLMIB)

Reported by Rick Sturm, U S West


Approximately 50 people attended the Working Group sessions on 
December 6 and 7.  Approximately one-third of those in attendance had 
not yet subscribed to the mailing list and therefore were not aware of 
some the discussions that had preceded this meeting.

Initially, background information was presented covering mailing 
list details (over 400 currently subscribed), archive details, charter, 
and consensus items from discussions on the mailing list.

The consensus items developed from the mailing list discussions were 
presented.  Those in attendance at the meeting concurred with the items 
on the list of consensus items.  The following are key points that were 
made regarding the consensus points.

Relevant Work

There were a number of questions regarding the need for this MIB in 
addition to the Host Resources (HR) MIB.  Cheryl Krupczak reviewed 
the "Group 3 Report."  This report had been previously posted to the 
mailing list and is available in the archive.  The report discusses how 
the Application MIB and HR MIBs are related and how they can 
compliment one another.  One point made in the meeting was that there 
is value in keeping the HR MIB and the Application MIB separate 
because the implementers of each will not necessarily be the same.

Another issue that was raised regarding relevant work was about the 
relationship of this effort and the work being done within the 
Desktop Management Task Force on the Software MIF.  It was 
explained that there has already been some contact between members 
of the Working Group and the Software MIF group.  They had been 
invited to attend the meeting and give a presentation about the 
Software MIF.  However, a conflict with a DMTF meeting 
precluded this.  The Software MIF Working Group will 
be contacted and invited to share information with the APPLMIB 
Working Group via the mailing list.  The mailing list will make it 
possible for the APPLMIB Working Group members to obtain the 
information in a more timely manner rather than waiting for a 
presentation at the next meeting of the Working Group.


Relationship with the Network Services Monitoring MIB

The Network Services Monitoring MIB contains a table: applTable.  In 
order to avoid confusion, the work of this Working Group will include 
the sysAppl prefix before all of the objects in the sysAppl MIB.


Using the RFC1565 MIB applTable is problematic for a generalized 
application for the following reasons:

1.  The semantics of some of the objects in the table appear to require 
    application instrumentation (for example, congested status).  The 
    Working Group has agreed not to require application 
    instrumentation for the sysAppl MIB.

2.  The sysAppl MIB will not be using pointers to X.500 type info.  The 
    information may be of value and we have discussed configuration 
    information for the sysAppl MIB-details of which should be posted 
    soon.  The sysAppl MIB will contain at least some configuration 
    information.  The information can be obtained without application 
    instrumentation.  Examples of this include installation dates, and 
    file sizes.

3.  The applTable does not maintain a history of each invocation 
    instance of the application.  The sysAppl MIB table does.  This is 
    equivalent in difference between tables in the sysAppl MIB and the 
    swRun Group in the HR MIB.


The next item of business was the proposed structure for the application 
MIB.

The first point that was made was that the work needs to be divided 
into two parts.  The first part will produce a MIB that will collect 
information about the application without requiring the application to 
be instrumented, that is, it will extract the information from the 
operating system.  This is called the SysAppl MIB.  There will be only 
one SysAppl MIB per system.  Jon Weinstock presented an outline of the 
structure of the SysAppl MIB.  Information about this structure will be 
posted to the mailing list by January 1996.  In addition, details about 
the proposed SysAppl MIB will be posted to the mailing list in early 
January.

After the SysAppl MIB has been created, a second MIB will be created.  
The second MIB will utilize information provided by the managed 
application.  In order to populate this MIB it will be necessary to 
instrument each managed application.  There will be one copy of this 
MIB for each managed application.  Therefore, this means that 
there will be multiple copies of this type of MIB on a system in 
addition to the single copy of the SysAppl MIB.  The Working Group 
will not address this MIB until the SysAppl MIB has been created.

Scope of the Application MIB

It was pointed out that the it is intended that the application MIB 
will not be limited to just UNIX systems.  It is intended that, to the 
extent that it is possible, this MIB will be operating system neutral.

This is defined, in part, in the Consensus Points that are attached to 
these minutes.  In addition, the SysAppl MIB will be limited to 
information related to fault, configuration, and performance 
management that can be obtained from the system without requiring 
the instrumentation of the managed applications.  The following lists 
reflect information requirements that were expressed by people in 
attendance at the meeting.

Fault Functions:

o  Status change notification and restart actions;
o  heartbeat;
o  running application discovery;
o  log history;
o  resource allocation failures;
o  running state;
o  error status-virus detection status; and,
o  application log pointers and format information.

Element status change object - to know when the status of an application 
or one of its elements changes.  This needs to be read/write:

o  failed installations;
o  license failures;
o  failed patches; and,
o  failed de-installs.


Configuration:

o  Correct configuration/verification
  o  current values - limit and high water mark
o  Prerequisites (associated parameters such as environment variables)
o  Access Control - who is allowed to use and how does the thing run (for 
    example, suid)
o  Restart characteristics and parameters

Performance Data:

o  Set of transport addresses open for use (pointers where appropriate to 
    the tcpconn table, etc.);
o  Resources in use:
  o cpu;
  o memory;
  o open files;
  o disk space;
  o swap;
  o log files;
  o devices in use; and,
  o shared memory.

In conclusion, there was consensus among those in attendance at the 
Application MIB Working Group meetings in Dallas that the proposed 
structure and strategy are appropriate and that work on the 
Application MIB should proceed based upon them.



APPLICATION MIB WORKING GROUP CHARTER

Co-Chairs 
  Jon Saperia
  Rick Sturm

Network Management Area Director: 
  Deirdre Kostick 

Mailing List Information 
  General Discussion:applmib@emi-summit.com
  To Subscribe: applmib-request@emi-summit.com


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


Goals and Milestones

January 1996 
  o  Post an initial Internet-Draft of the Application MIB for discussion
  o  First Meeting of Working Group at IETF IN Dallas

February 1996 
  o  Interim meeting to work on MIB
  o  Revised Internet-Draft made available for discussion

March 1996 
  o  Review Draft at Los Angeles IETF working group meeting

May 1996
  o  Revised Internet-Draft made available for discussion

June 1996
  o  Working Group meeting in Montreal

July 1996
  o  Final revised Internet-Draft made available for discussion

September 1996
  o  Submit Internet-Drafts to IESG for standards track evaluation

Current Internet-Drafts 
  o  none.


Consensus Points of the Application MIB Working Group


Single Versus Multiple MIBs

The consensus of the Working Group is that on each host where 
managed applications exist there will be a single instance of the 
Application MIB, regardless of the number of managed applications 
that exist on that system.  That MIB will have entries based on which 
applications are, or have been, running on the host over given periods of 
time.


Persistent Application Information

There has been discussion about whether the information about 
managed applications that will be contained in the MIB should exist 
only while a managed application is active on a system or if it should 
be maintained across time, regardless of the presence, or state, of the 
managed application(s).  The group consensus is that the information 
about the managed applications should persist independently of the 
application(s) that are being managed.  This will permit the manager 
to query the status of the application, even when the application has 
failed.


MIB Entry Persistence

There has been discussion about whether MIB entries should only exist 
while a managed application is active on a system or if it should 
persist across time, regardless of the presence, or state, of the managed 
application(s).  The group consensus is that the MIB entries should 
persist independently of the application(s) that are being managed.  
This will permit the manager to query the status of the application, 
even when the application has failed.


Relevant Work

The purpose of this group is to define an SNMP-based MIB within the 
limits defined by the group's charter.  The group has agreed to examine 
relevant, existing work (e.g., the Host Resources MIB) and to build upon 
that work where appropriate.


API Definition

The group has reached consensus that the definition of APIs to support 
the implementation of the MIB is beyond the scope and charter of the 
group.  Therefore, the group will not attempt to define APIs to be used 
with the application MIB, and will not presume that any particular 
APIs will be available or supported.


Implementation Details

The group has concluded that while it may be useful to hypothesize 
how the application MIB will be used or implemented, the definition 
of such implementation details is beyond the scope and charter of this 
group.


Scope of the MIB - Distribution

There is a desire to support distributed applications, but not at the 
expense of creating a MIB which cannot or will not be implemented. For 
this reason the consensus of the group is that the focus be on 
applications in a single host and add hooks wherever possible for 
additional growth.  Features for distributed applications will be added 
to the extent they do not make the implementation overly complex.



Application Definition

For the purpose of developing the application MIB, the following 
definition will be referenced: an application is a set (segment) of 
executable code, that runs a single computer processor (or a set of 
coupled processors functioning as a single unit) which provides some 
type of functionality.