home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
rmonmib
/
rmonmib-minutes-93nov.txt
< prev
next >
Wrap
Text File
|
1994-02-17
|
8KB
|
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 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