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 >
Text File  |  1994-02-17  |  8KB  |  194 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Edward Alcoff/Network Application Technology and Michael
  5. Erlinger/Harvey Mudd College
  6.  
  7. Minutes of the Remote LAN Monitoring Working Group (RMONMIB)
  8.  
  9.  
  10. Agenda - Monday's Session
  11.  
  12.    o Presentation of new charter.
  13.    o Discussion of experiences that may affect RFC 1271 changes.
  14.    o Discussion of the four advancement options for RFC 1271.
  15.    o Consensus on the particular option to be pursued for RFC 1271.
  16.    o Discussion of areas of RFC 1271 that should be modified.
  17.  
  18.  
  19. The chair presented the new charter:
  20.  
  21.  
  22.  
  23.      The RMON Working Group is chartered to prepare a recommendation
  24.      to the IESG evaluating RFC 1271 (the RMON MIB) with respect to
  25.      the standards track.
  26.  
  27.      The recommendation will document implementation,
  28.      interoperability, and deployment experience.  If this
  29.      experience suggest that changes should be made to the document,
  30.      a new draft may be prepared.  The recommendation will report
  31.      one of four outcomes:
  32.  
  33.  
  34.       1. That RFC 1271 should be advanced from proposed to draft
  35.          status, without changes (if no problems are found);
  36.  
  37.       2. That a draft prepared by the working group, should replace
  38.          RFC 1271, and be designated a Draft Standard (if only
  39.          minor changes are made);
  40.  
  41.       3. That a draft prepared by the working group, should replace
  42.          RFC 1271, and be designated a Proposed Standard ( if major
  43.          changes or feature enhancements are made); or,
  44.  
  45.       4. That RFC 1271 should be designated as historic (if this
  46.          technology is problematic).
  47.  
  48.  
  49.  
  50. After some discussion, the consensus was that a draft prepared by the
  51. working group should replace RFC 1271 and be designated a Draft
  52. Standard, with minor changes to be made.  Work on version 2 of RMON was
  53. delayed until the Spring IETF, to allow RFC 1271 to progress through the
  54. standards track.  The RMON mailing list would also be polled for
  55. consensus on this strategy.
  56.  
  57. Steve McRobert stated that the EtherStats group is incorrectly
  58. specified, with regards to dribble bits.  Steve Waldbusser agreed and
  59. said that RMON implementors were developing RMON the way it made sense
  60. to and not the way the RFC specified.  McRobert had posted several other
  61. items with regards to the EtherStats group and Waldbusser said that
  62. fixing them should be a relatively easy task.  The Chair said that he
  63. would bring the information on this matter to the second session of the
  64. RMON working group for discussion.
  65.  
  66. The RMON working group has also been tasked to write up RMON
  67. interoperability issues and information with regard to RMON
  68. implementation experience.  Steve Waldbusser said that he would help
  69. coordinate this effort.  Bob Stewart also suggested that the working
  70. group start a new features list for consideration for the next version
  71. of RMON. The chair then solicited extensions to the RMON that have been
  72. implemented by the vendors.  This request will also be passed to the
  73. RMON mailing list.
  74.  
  75. The chair then presented a list of fourteen areas for change to RFC 1271
  76. to the meeting and the working group added three more for discussion.
  77.  
  78. Editor's Note:  An itemized list of changes is available via FTP or mail
  79. server from the remote directories as
  80. /ietf/rmonmib/rmonmib-minutes-93nov.txt.  Refer to Section 1.2 of the
  81. proceedings for retrieval instructions.
  82.  
  83. The floor was then opened to general questions and contributions.
  84.  
  85.  
  86.  
  87. Thursday's Session
  88.  
  89. The Thursday meeting was initially dedicated to discussion of the AMD
  90. (Ian Crayford and Steve McRobert) concerns with the Ether Stats table.
  91.  
  92. By the time of the meeting these issues had been resolved by Steve
  93. Waldbusser and Steve McRobert.  Basically, RMON implementations were
  94. doing the `right thing', but the RFC text was unclear.
  95.  
  96. The agreed-upon changes were:
  97.  
  98.  
  99.    o Remove the incorrect definition of alignment errors.
  100.    o Define the term ``bad packets'' that is used frequently.
  101.    o Mention that the collisions object is naturally dependent on the
  102.      position of the probe in the network.
  103.  
  104.  
  105. One of Steve McRobert's issues that consensus could not be reached on
  106. was that the RMON's usage of the term jabbers was different than the
  107. 802.3 definition.
  108.  
  109. Two possible solutions were proposed:
  110.  
  111.  
  112.   1. Deprecate the current object (and object ID) and re-create another
  113.      with the right name.
  114.  
  115.   2. Add text to the description field that says:  ``Note that this is
  116.      not the same as 802.3's definition of a jabber.''
  117.  
  118.  
  119. Consensus on this issue will be sought on the mailing list.
  120.  
  121. A broad discussion on RMON related to silicon implementation ensued.
  122. Two approaches materialized:
  123.  
  124.  
  125.   1. Wholesale modification of the current RMON specification, and
  126.   2. Keeping the current specification stable while acknowledging that
  127.      RMON II will seriously consider hardware implementation issues, and
  128.      therefore may not remain compatible with the current RMON. The
  129.      working group agreed to the second strategy.
  130.  
  131.  
  132. One particular concern that was discussed for silicon implementations is
  133. that no performance gains can be achieved for filtering when the
  134. acceptType is set to acceptFailed.  After some discussion it was
  135. identified as a general problem with formulas in ``Sum of Products''
  136. form, and that outlawing them is probably not the right solution given
  137. that these are useful for a variety of filtering applications.  The
  138. suggestion was made that RMON applications could warn the user that the
  139. SOP form selected when setting acceptType to acceptFailed can be very
  140. inefficient.
  141.  
  142.  
  143. Attendees
  144.  
  145. Edward Alcoff            oldera@nat.com
  146. Jim Barnes               barnes@xylogics.com
  147. Bart Berger              bart_berger@3com.com
  148. Ram Bhide                ram@nat.com
  149. Andy Bierman             abierman@synoptics.com
  150. Jia-bing Cheng           cheng@ralvm6.vnet.ibm.com
  151. Chris Chiotasso          chris@lightstream.com
  152. Frank Ciotti             frankc@telxon.com
  153. Blair Copland            copland@unt.edu
  154. Manuel Diaz              diaz@davidsys.com
  155. Jonathan Didner          jonb@bangate.compaq.com
  156. David Engel              david@ods.com
  157. Michael Erlinger         mike@jarthur.claremont.edu
  158. William Fardy            billf@frontier.com
  159. Steve Garritano          steveg@kalpana.com
  160. Christine Gressley       gressley@uiuc.edu
  161. Robert Grow              bob@xlnt.com
  162. Stuart Hale              stu_hale@vnet.ibm.com
  163. Daniel Hansen            danh@ngc.com
  164. John Hopprich            hopprich@davidsys.com
  165. Jeff Hughes              jeff@col.hp.com
  166. Kevin Jackson            kjackson@concord.com
  167. Mark Kepke               mak@fc.hp.com
  168. Kenneth Key              key@snmp.com
  169. Michael Kornegay         mlk@bir.com
  170. Cheryl Krupczak          cheryl@empiretech.com
  171. William Kwan             kwan@rabbit.com
  172. Dave Livingston          squirrel@vnet.net
  173. Carl Madison             carl_madison@3mail.3com.com
  174. Peram Marimuthu          peram@wg.com
  175. Evan McGinnis            bem@3com.com
  176. Steve McRobert           steve.mcrobert@amd.com
  177. Tom Nisbet               nisbet@fbsw.tt.com
  178. Steven Onishi            sonishi@wellfleet.com
  179. David Perkins            dperkins@synoptics.com
  180. Jon Saperia              saperia@zko.dec.com
  181. Michael Scanlon          scanlon@ftp.com
  182. Chris Shaw               cshaw@banyan.com
  183. Timon Sloane             timon@timonware.com
  184. Bob Stewart              rlstewart@eng.xyplex.com
  185. Adam Stolinski           stolinsk@cerf.net
  186. Kaj Tesink               kaj@cc.bellcore.com
  187. Steven Waldbusser        waldbusser@andrew.cmu.edu
  188. Thomas Walsh             tomw@kalpana.com
  189. Alice Wang               alice.wang@eng.sun.com
  190. Peter Wilson             peter_wilson@3mail.3com.com
  191. Paul Woodruff            pwoodruff@synoptics.com
  192. Henry Yip                natadm!henry@uunet.uu.net
  193.  
  194.