Subject: DisMan Meeting Minutes

From: Rob Frye <[email-masked]>
Date: Tue, 30 Mar 1999 16:13:05 -0500

DISMAN
Minneapolis, 03/19/1999
Chair: Randy Preshun
Reported by: Rob Frye
Charter: http://www.ietf.org/html.charters/disman-charter.html

Agenda:
- Welcome, Introduction, Charter URL
- Administrative issues
- Status of current documents
- Technical presentations
- Wrapup

The disman working group met at 13:00 CST on 1999-03-18 at the 44th IETF
meeting in Minneapolis, Minnesota. Rob Frye recorded the meeting minutes.
Official count was 46 attendees, unofficial was about 50.  The group
briefly discussed the three DisMan drafts which are currently in working
group last call, and spent most of the time working through issues with
the remote operations draft, trying to focus on getting this document to
last call.  Although several possible additions or extensions to this work
were discussed, the current path forward will be to complete this document
without further significant embellishment.

The Working Group chair, Randy Preshun, took care of Administrative
matters quickly.  Rob Frye agreed to be the minutes taker, signup
sheets were distributed, and it was stated that there should be no
time allocation restrictions as the time was not expected to run over.

Randy provided the status of the current documents.  The
Script (draft-ietf-disman-script-mib-08) and
Schedule (draft-ietf-disman-schedule-mib-06) MIBs
have been approved by the WG and IESG and should be
assigned RFC numbers soon.
The Notify and Log MIB (draft-ietf-disman-notif-log-mib-09),
Event MIB (draft-ietf-disman-event-mib-06), and
Expression MIB (draft-ietf-disman-express-mib-08)
are currently in WG last call.  The Remote Operations MIB
(draft-ietf-disman-remops-mib-03) was last released in
December 1998 and needs to be updated for WG Last Call.

The Notify and Log MIB was the first draft discussed.  Only five
participants in the meeting had already read the draft.  The chair
pointed out an asymmetry of events placed in the Log MIB.  Local events
are filtered to check permissions of the log owner before writing an
event to the log.  Remote events have no filtering done (due mostly to
VACM considerations with [stateless] proxy implementations).  The
group was comfortable with this reported asymmetry and expects no
problem with approval by the IESG.

The Event MIB has one week remaining for WG last call.  One question was
raised by the chair regarding the "strange limits" of object
mteResourceSampleMinimum (-1 | 1..600).  Bob Stewart agreed that since
he was the one who created it that he would investigate and document why
those particular limits.  If no good reason is found then the architectural
constraints will be lifted.  If no other concerns are raised, the draft
will complete WG last call.

The Expression MIB has also had review by very few readers.  The topic
of interactions between owner indexes and VACM group configurations was
initially discussed within the context of the Expression MIB.  It was
brought up then because the Expression MIB would be the logical place
to gather results of remote actions such as pings, and the complexities
of proper configuration of VACM, target addresses and owners impact
the use of the Expression MIB to gather and report on the results of
ping.  Because the owner index issue pertains more to the Remote
Operations MIB, it is described in these minutes as a Remote
Operations document discussion topic.

The next discussion for the Expression MIB was about distribution
analysis, particularly as applied to ping capabilities provided by
the Remote Operations MIB.  This turned into a more general discussion
about "binning" capabilities.  The chair suggested that we ask another WG
to define general-purpose distribution analysis functions and requirements.
The group consensus was that simple delay distribution is important and
helpful, and could easily be defined by the DisMan WG.  There were several
concerns raised regarding what the cutoff should be between what statistics
we should build in now vs follow-on work, considering that distribution
analysis is a very rich field.  It was generally agreed that Min/max/average
calculations should be provided in basic MIBs, and that results in the
Expression MIB can capture more complex items.  There were concerns about
performance issues of retrieving the results in the Expression MIB and
shuffling that data to some other summary statistics MIB, and how timeouts
should be accounted for.  The group consensus was clearly that we have to
define a cutoff on the complexity that the group would undertake at this
time, particularly considering that user customization can add significant
complexity to binning algorithms.  Other examples of the use of binning
methods (eg TN3270, ARPMIB) were given, and in those cases the complexity
is limited.  The final group decision was to keep discussion open on the
mailing list, for Bob Stewart, Carl Kalbfleisch and Russell Dietz to add
basic binning for ping delay distributions to the Remote Operations MIB,
that it is important now to make sure that MIBs record their results in
a manner that would accommodate binning and analysis, and that the A-D
will consider where an appropriate place would be for general purpose
binning and distribution analysis.  The A-D was asked to consider
whether RMON or DisMan was the right place for some related general
application work currently being done in the RMON group (although it
was also noted that it really didn't matter much considering the overlap
in participation between the groups).  During the Remote Operations MIB
discussion, Bob Stewart and Bob Moore were asked to contribute a
strawman for generic data gathering capabilities with wildcarding
similar to wildcard capabilities defined for the Expression MIB.

The Remote Operations draft was next discussed.  A general policy
question on addressing was raised, whether to allow Domain Names
vs IP Addresses of target systems.  The consensus on the list was
to allow Domain Names.  Problems were noted between INS, DNS, etc
being out of sync and that not all resolvers tell how names are
resolved or what precedence was used for resolution.  Both of these
are deemed useful for operations and end users.  The chair requested
Jon Saperia to summarize RFC 1612 (DNS Resolver MIB Extensions) and
other standards for this.  Bert Wijnen, A-D, noted that if we do
include name resolver feedback now, we can easily drop it later when
going to DRAFT status but that it is harder to add it later if it
is not in the document initially.  There was no strong feeling to
change the document for now.  When Jon Saperia posts more information
to the list, further resolver information could be added when other
changes are made to the document.

There was further concern when discussing the Lookup MIB that adding
an extra DNS response time would be a "slippery slope": how far do
we go with putting in response timers, and where do we stop?
After considerable discussion, it was decided that a response time
object should be added to the resolver part of the Lookup MIB unless
it extends the WG time.

Another "slippery slope" was the area of other implementations, tests
and tools like ping, particularly for non-IP protocols.  After agreeing
on the usefulness of this, it was decided that the addition of
control objects and a list of IANA-provided numbers for various
protocols to make it generic would not solve the problem -- the
capability to do ping-like operations in other protocols would
take considerable effort to understand and document.  The final
consensus was to not undertake this work at this time.

As indicated above, the topic of indexing to support VACM (owner
indexes) was initially brought up during the discussion of the
Expression MIB.  The implications of the remote operations MIB
using owner indices defined as VACM groups was explained better while
discussing the Remote Operations document.  The problem is that an
owner (as defined by pingOwnerIndex) can only have one outstanding
ping at a time to a particular destination (pingHostAddress).
If an owner is a VACM groupName, then all individuals defined
in the VACM group together can share a single outstanding ping
to a particular destination.  The final group decision on this
matter was that it needed further discussion on the list, but
that indexing of the form "table.owner.dest.testid" was probably
the right approach.  The additional "testid" index could be
specified as either testAndIncrement or RowStatus objects.  The
reason for "dest" as an index is to limit access to certain tests
for certain destinations.

The meeting concluded with a reminder to sign and turn in the
blue attendance sheets and to send minutes to the disman list
and [email-masked].