New Work in the Network Management Area
        Orlando, 12/10/1998
        Chair: Bert Wijnen
        Reported by: Shawn A. Routhier
        http://www.ops.ietf.org
        Area mailing list: ops-area@ops.ietf.org

Editor's note:  Most of this meeting was devoted to a series
of presentations with little discussion on each.  I have
attempted to briefly summarize each presentation, however
the reader might  want to examine the slides for more detail.

The opening comments from the chair noted that while we may start
looking at new work now, we, as promised by a previous AD, must
finish SNMPv3 and SMIv2 before that new work can be started.

The opening comments from the AD (Harald):
The IETF's purpose is to make the internet work.  The purpose
of the OPS area is to manage the network, it is not to allow
vendors to sell, nor to provide elegant solutions.  It's purpose
is to make sure we can make the internet go.  Device management
via SNMP is useful as long as it makes the internet work, and
if other schemes will help we should investigate them.  The
purpose of doing new work is to make sure the internet survives,
and the yardstick to measure any new ideas is "is this the most
critical issue we can solve".  

The first presentation was from Karl E. Schohl, ANX Business Manager
from the Automotive Industry Action Group.  This industry is using
their networks in a business to business fashion and quality is
a critical factor.  As such they are using network management in
order to track the service quality and to handle trouble as it arises.
One particular area they have worked on is defining performance and
reliablity  metrics in order to categorize the networks and the service
levels.  Currently these metrics are per technology and aren't consistent
across technologies.  They are looking for buy in from the NM community
to supply expertise to help in building consistent methods for discovery
and management.  It was pointed out that MIBs for some areas they were
concerned with (Tunnels and VPN) already exist and more work in those
areas may not be needed.

The next presentation was from Terry Davis of Boeing and was
on serveral thoughts from an enterprise viewpoint.  A lot of their
time is spent doing middle layer work and tying existing systems
together.  Ideas that make these connections simpler are valuable.
They are also interested in getting the end nodes included within
the network management scheme, particularly to allow for management
of end to end services.  They have found some simple tools such as
a response time MIB and traceroute functionality to be valuable.
He also made the point that SNMPv3 needs to be finished.

Bob Stewart wanted to bring up several issues that have been discussed
in other areas but have yet to find a conclusion or home.
Security - how much affect is or should security have when building mibs.
Should every mib table have an owner string as part of the instances for
security.
Persistence and storage type - There are several questionable areas,
mostly for scalars, that should be clarified.  When should any changes
take affect - immediately or upon reboot?  Should the row be saved across
reboots?  And so on.
Bulk data transfer - several drafts submitted that attempt to
remove some of the ASN1 redundancy and then use FTP tomove the file.
This is work that is looking for a home.

The idea of a general method for throttling traps was brought up in
other working groups and was deferred in them as out of scope.  It
was raised here as a possible future work item.

It was pointed out that there were two sets of discussions occurring,
one on managing a single device and one a managing a collection of
devices.  There may be a disconnect between the two and we may need
to resolve it.

Juergen Schoenwaelder discussed several items that might not be
large enough to require their own working group but might be able
to be handled in some other group or perhaps without one.  The items
were: the TDOMAIN/TADDRESS work from Mike Daniele, creating a single
document out of several commonly used Textual Conventions, and some
methods for timestamping events preferably without using a wall clock.

Bob Natale described the current status of the WinSNMP effort and
proposed bringing it into the IETF with a working group to update
it to include SNMPv3 funtionality.  Bob included a proposed WG
charter and some possible candidates for WG roles.  There was some
discussion about the WinSNMP API and the AgentX API (no connection)
and the SNMPv3 ASIs (less detailed but obviously more constrained).
As well as discussion about possible backwards compatibility issues
as the WG would not be required to produce a backwards compatible API.
For other information about WinSNMP see the website at "www.winsnmp.com"
and the mailing list at "WinSNMP@mailbag.intel.com".  To subscribe
send mail to "listserv@mailbag.intel.com" with a blank subject line
and a message body of "subscribe winsnmp".

Jim McQuaid discussed "Applications Performance on the Network".
This talk assumes that the IETF isn't the appropriate forum
for several areas such as, desktops, servers, applications and databases.
Rather the IETF should concentrate on network issues and, more
specifically in this case, on gaining an understanding of feasible
network based performance metrics.  The suggested deliverables
would be definitions for the performance metrics, a framework for
the data collection and a MIB or other method for outputting the data.
The audience pointed out that some of this work might be included
elsewhere such as RMON and IPPM.  For other information see the
mailing list at "artmib_bof@art.netscout.com", subscribe to
"artmib_bof-request@art.netscout.com".

Dave Thaler discussed "automated problem reporting & feedback".
The concept is to allow problem reports to be automatically
moved around the network, possibly triggering new testing and
being modified as they move.  A key to this functionality is
a standard format and method for reporting network problems.  Some
of the issues are scalability, reporting the destination ID, and
privacy.  Some work has already been done in this area on the MBONE
at Merit.  For more information see "http://www.eecs.umich.edu/~thalerd/gdt/"
or the strawman protocol in "draft-thaler-gdt-00.txt".  There was
some discussion that some work in this area may have been done in the
CMIP world as well as the IETF.  There was also discussion that there
might need to be two APIs one to report an item, and another to move that
information around the network.  Lastly SNMP might not be the proper
tool to start with as the two sides may be in different trust domains which
could cause some problems.

Ariel Pashtan discussed "common network management agents".
Currently managers must understand different interfaces for
different network elements which makes writing and using them
difficult.  This was a proposal to try and standardize the
interfaces for the NEs to improve the management functions.
One part of the propsal was to define service levels to allow
managers to categorize and manipulate the elemenets more easily.
There was some discussion about how this topic interacted with
other areas such as DISMAN and the possibility of starting with
a small area such as a common interface to a distributed mid-level
manager or alarms that agents might produce and growing from there.

John Ioadnnidis discussed "trust management for SNMP".
This was another look at dealing with security policies.  The view
starts with the position that the current VACM in SNMPv3 isn't
flexible enough for fine grained access control and expands to include
the difficulty with expressing complex policies and managing them
in general.  The "trust management" scheme being worked on elsewhere
in the IETF might provide another solution to the problem.  In
this scheme the application would from a query to send to a server
to determine the appropriate access levels for a "user".
More information may be found in "draft-blaze-ietf-trustmgt-keynote-00.txt"
There was some discussion about possible slow downs while attempting
to access a server for each packet, as the results may be cached this
shouldn't be a problem.

Ed Ellison presented the Policy Framework WG.  They are working
on some of the elements required to allow an entire set of devices
to use a coherent policy from end to end.  As part of their work 
they have liaison relationship with DMTF (http://www.dmtf.org).
They are interested in retrieving information via MIBs and SNMP.
This information would be used to correlate what actually happened
from what was desired by the policy.  For example wat service level
was given vs what was desired.

Dave Perkins presented proposals to complete the set of data types
in use by SNMP.  He suggests that the list of data types should match
those find in most programming languages and should include types
such as uint64, int64, float, double float and discriminated union.
This should be done without breaking conforming entities or mib
processing tools and without protocol or api changes.  He has already
done some prototyping for the types and belives this should be a short
(4 months?) effort.  A member of the audience asked if the new types
would be usable as indexes, Dave didn't think so.

Dave also suggested that work should be done on creating a new PDU
for use with bulk data retrieval.  The new PDU should have the same
look and feel as the current PDUs, have minimal impact on SNMP entities
and meet specific constraints on functionality - Dave suggests a requirement
of 3x speed up over GETBULK.  He believed this should be another
short duration effort.

The microphone was then opened to the audience for general comments.
Two other work items were suggested: some of the Asset Management MIB
that was discussed in the Entity MIB might be better done here and
the merging of the TCP/UDP MIBs for IPv4 and IPv6.  

One person suggested that we continue the style of the SNMPv3 WG
and try to use a moudlar architecture where possible and split
the problem(s) into smaller areas with smaller WGs.  The ADs
mentioned the small design team approach and its success with SMIv2.

Finally it was suggested that we should review the current set of
tools that we have and determine which tools may be missing as well
as cleaning up overlaps. 

There was no time left for discussion and prioritization.  The discussion
will be continued on the mailing list -- ops-area@ops.ietf.org, comments
and/or new items should be sent to the mailing list ASAP.