Internet Standards/CD1.mdf/INET/IETF/RMONMIB/93NOV.MIN

Text File | 1994-02-17 | 7.5 KB | 194 lines

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            [e-mail]
Jim Barnes               [e-mail]
Bart Berger              [e-mail]
Ram Bhide                [e-mail]
Andy Bierman             [e-mail]
Jia-bing Cheng           [e-mail]
Chris Chiotasso          [e-mail]
Frank Ciotti             [e-mail]
Blair Copland            [e-mail]
Manuel Diaz              [e-mail]
Jonathan Didner          [e-mail]
David Engel              [e-mail]
Michael Erlinger         [e-mail]
William Fardy            [e-mail]
Steve Garritano          [e-mail]
Christine Gressley       [e-mail]
Robert Grow              [e-mail]
Stuart Hale              [e-mail]
Daniel Hansen            [e-mail]
John Hopprich            [e-mail]
Jeff Hughes              [e-mail]
Kevin Jackson            [e-mail]
Mark Kepke               [e-mail]
Kenneth Key              [e-mail]
Michael Kornegay         [e-mail]
Cheryl Krupczak          [e-mail]
William Kwan             [e-mail]
Dave Livingston          [e-mail]
Carl Madison             [e-mail]
Peram Marimuthu          [e-mail]
Evan McGinnis            [e-mail]
Steve McRobert           [e-mail]
Tom Nisbet               [e-mail]
Steven Onishi            [e-mail]
David Perkins            [e-mail]
Jon Saperia              [e-mail]
Michael Scanlon          [e-mail]
Chris Shaw               [e-mail]
Timon Sloane             [e-mail]
Bob Stewart              [e-mail]
Adam Stolinski           [e-mail]
Kaj Tesink               [e-mail]
Steven Waldbusser        [e-mail]
Thomas Walsh             [e-mail]
Alice Wang               [e-mail]
Peter Wilson             [e-mail]
Paul Woodruff            [e-mail]
Henry Yip                natadm![e-mail]