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 minutes@ietf.org.