CURRENT_MEETING_REPORT_

Reported by Edward Alcoff/Network Application Technology and Michael
Erlinger/Harvey Mudd College

Minutes of the Remote LAN Monitoring Working Group (RMONMIB)


Agenda - Monday's Session

   o Presentation of new charter.
   o Discussion of experiences that may affect RFC 1271 changes.
   o Discussion of the four advancement options for RFC 1271.
   o Consensus on the particular option to be pursued for RFC 1271.
   o Discussion of areas of RFC 1271 that should be modified.


The chair presented the new charter:



     The RMON Working Group is chartered to prepare a recommendation
     to the IESG evaluating RFC 1271 (the RMON MIB) with respect to
     the standards track.

     The recommendation will document implementation,
     interoperability, and deployment experience.  If this
     experience suggest that changes should be made to the document,
     a new draft may be prepared.  The recommendation will report
     one of four outcomes:


      1. That RFC 1271 should be advanced from proposed to draft
         status, without changes (if no problems are found);

      2. That a draft prepared by the working group, should replace
         RFC 1271, and be designated a Draft Standard (if only
         minor changes are made);

      3. That a draft prepared by the working group, should replace
         RFC 1271, and be designated a Proposed Standard ( if major
         changes or feature enhancements are made); or,

      4. That RFC 1271 should be designated as historic (if this
         technology is problematic).



After some discussion, the consensus was that a draft prepared by the
working group should replace RFC 1271 and be designated a Draft
Standard, with minor changes to be made.  Work on version 2 of RMON was
delayed until the Spring IETF, to allow RFC 1271 to progress through the
standards track.  The RMON mailing list would also be polled for
consensus on this strategy.

Steve McRobert stated that the EtherStats group is incorrectly
specified, with regards to dribble bits.  Steve Waldbusser agreed and
said that RMON implementors were developing RMON the way it made sense
to and not the way the RFC specified.  McRobert had posted several other
items with regards to the EtherStats group and Waldbusser said that
fixing them should be a relatively easy task.  The Chair said that he
would bring the information on this matter to the second session of the
RMON working group for discussion.

The RMON working group has also been tasked to write up RMON
interoperability issues and information with regard to RMON
implementation experience.  Steve Waldbusser said that he would help
coordinate this effort.  Bob Stewart also suggested that the working
group start a new features list for consideration for the next version
of RMON. The chair then solicited extensions to the RMON that have been
implemented by the vendors.  This request will also be passed to the
RMON mailing list.

The chair then presented a list of fourteen areas for change to RFC 1271
to the meeting and the working group added three more for discussion.

Editor's Note:  An itemized list of changes is available via FTP or mail
server from the remote directories as
/ietf/rmonmib/rmonmib-minutes-93nov.txt.  Refer to Section 1.2 of the
proceedings for retrieval instructions.

The floor was then opened to general questions and contributions.



Thursday's Session

The Thursday meeting was initially dedicated to discussion of the AMD
(Ian Crayford and Steve McRobert) concerns with the Ether Stats table.

By the time of the meeting these issues had been resolved by Steve
Waldbusser and Steve McRobert.  Basically, RMON implementations were
doing the `right thing', but the RFC text was unclear.

The agreed-upon changes were:


   o Remove the incorrect definition of alignment errors.
   o Define the term ``bad packets'' that is used frequently.
   o Mention that the collisions object is naturally dependent on the
     position of the probe in the network.


One of Steve McRobert's issues that consensus could not be reached on
was that the RMON's usage of the term jabbers was different than the
802.3 definition.

Two possible solutions were proposed:


  1. Deprecate the current object (and object ID) and re-create another
     with the right name.

  2. Add text to the description field that says:  ``Note that this is
     not the same as 802.3's definition of a jabber.''


Consensus on this issue will be sought on the mailing list.

A broad discussion on RMON related to silicon implementation ensued.
Two approaches materialized:


  1. Wholesale modification of the current RMON specification, and
  2. Keeping the current specification stable while acknowledging that
     RMON II will seriously consider hardware implementation issues, and
     therefore may not remain compatible with the current RMON. The
     working group agreed to the second strategy.


One particular concern that was discussed for silicon implementations is
that no performance gains can be achieved for filtering when the
acceptType is set to acceptFailed.  After some discussion it was
identified as a general problem with formulas in ``Sum of Products''
form, and that outlawing them is probably not the right solution given
that these are useful for a variety of filtering applications.  The
suggestion was made that RMON applications could warn the user that the
SOP form selected when setting acceptType to acceptFailed can be very
inefficient.


Attendees

Edward Alcoff            oldera@nat.com
Jim Barnes               barnes@xylogics.com
Bart Berger              bart_berger@3com.com
Ram Bhide                ram@nat.com
Andy Bierman             abierman@synoptics.com
Jia-bing Cheng           cheng@ralvm6.vnet.ibm.com
Chris Chiotasso          chris@lightstream.com
Frank Ciotti             frankc@telxon.com
Blair Copland            copland@unt.edu
Manuel Diaz              diaz@davidsys.com
Jonathan Didner          jonb@bangate.compaq.com
David Engel              david@ods.com
Michael Erlinger         mike@jarthur.claremont.edu
William Fardy            billf@frontier.com
Steve Garritano          steveg@kalpana.com
Christine Gressley       gressley@uiuc.edu
Robert Grow              bob@xlnt.com
Stuart Hale              stu_hale@vnet.ibm.com
Daniel Hansen            danh@ngc.com
John Hopprich            hopprich@davidsys.com
Jeff Hughes              jeff@col.hp.com
Kevin Jackson            kjackson@concord.com
Mark Kepke               mak@fc.hp.com
Kenneth Key              key@snmp.com
Michael Kornegay         mlk@bir.com
Cheryl Krupczak          cheryl@empiretech.com
William Kwan             kwan@rabbit.com
Dave Livingston          squirrel@vnet.net
Carl Madison             carl_madison@3mail.3com.com
Peram Marimuthu          peram@wg.com
Evan McGinnis            bem@3com.com
Steve McRobert           steve.mcrobert@amd.com
Tom Nisbet               nisbet@fbsw.tt.com
Steven Onishi            sonishi@wellfleet.com
David Perkins            dperkins@synoptics.com
Jon Saperia              saperia@zko.dec.com
Michael Scanlon          scanlon@ftp.com
Chris Shaw               cshaw@banyan.com
Timon Sloane             timon@timonware.com
Bob Stewart              rlstewart@eng.xyplex.com
Adam Stolinski           stolinsk@cerf.net
Kaj Tesink               kaj@cc.bellcore.com
Steven Waldbusser        waldbusser@andrew.cmu.edu
Thomas Walsh             tomw@kalpana.com
Alice Wang               alice.wang@eng.sun.com
Peter Wilson             peter_wilson@3mail.3com.com
Paul Woodruff            pwoodruff@synoptics.com
Henry Yip                natadm!henry@uunet.uu.net