home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ifmib / ifmib-minutes-93nov.txt < prev    next >
Text File  |  1994-02-08  |  9KB  |  240 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Theodore Brunner/Bellcore
  5.  
  6. Minutes of the Interfaces MIB Working Group (IFMIB)
  7.  
  8. Discussion focussed on the ``Evolution of the Interfaces Group of MIB
  9. II'' Internet-Draft of October 20, 1993.  The discussion reviewed issues
  10. raised on the mailing list and was the final forum for concerns about
  11. the Internet-Draft before it was forwarded from the IFMIB Working Group
  12. to the Area Director for consideration as a Proposed Standard.
  13.  
  14.  
  15. Evolution of the Interfaces Group of MIB II Internet-Draft
  16.  
  17.    o ifOperStatus and ifOperStatusDetail
  18.  
  19.      A suggestion was made on the mailing list to add more detail about
  20.      why an interface is ``down.''  An example was given of an on-demand
  21.      connection down for lack of traffic.  IfOperStatusDetail was
  22.      included in the document.  A question was raised in the meeting as
  23.      to what is a generic OID; all seemed media specific.  An
  24.      alternative to StatusDetail was suggested (actually an original
  25.      suggestion on the list), of expanding ifOperStatus to include a
  26.      ``down-non-failure'' state, in addition to the existing down(2)
  27.      interpreted as ``down-failure.''
  28.  
  29.      Result:  The new ifOperStatus state was accepted and a group was
  30.      delegated to work out the details and report back.
  31.  
  32.    o Counters
  33.  
  34.      A question was raised as to why ifXxxOctets is counted at the
  35.      bottom of the interface stack while packets are counted at the top
  36.      of the stack.  It was answered that Octets-on-the-wire gives a
  37.      measure of network utilization, while packets-on-the-wire would
  38.      not.
  39.  
  40.      Result:  There is no interest in changing the definition.
  41.  
  42.    o ifOutQLen
  43.  
  44.      A question was raised about why it is being deprecated.  It was
  45.      suggested that it has network debugging utility.  A response was
  46.      given that ifOutDiscards and the Ethernet MIB offer the same
  47.      functionality.  Following the last IFMIB meeting there had been a
  48.      proposal sent out on the list of a redefinition of ifOutQLen, but
  49.      it was not carried forward in the document, nor extensively
  50.      discussed.
  51.  
  52.      Result:  The authors will present it again to the working group.
  53.  
  54.    o ifStackTable
  55.  
  56.      A question was raised as to why there is no reverse of ifStackTable
  57.      to directly read off the layer above.  It was answered that one
  58.      direction was sufficient; a manager loads the whole table upon
  59.      startup and builds the entire layer mapping from it.  The reverse
  60.      direction would not be generally needed.
  61.  
  62.      Result:  There was interest in changing the definition.
  63.  
  64.    o ifStackTable
  65.  
  66.      It was asked why is it easy to read top to bottom instead of bottom
  67.      to top.  The reason is that the IP layer references interfaces
  68.      below it.
  69.  
  70.      Result:  There is no interest in changing the definition.
  71.  
  72.    o ifConnector
  73.  
  74.      It was asked if the enumeration could be changed to an OID
  75.      describing the plug, if it is a physical connection.  It was
  76.      decided that this is too complex; extensions are not wanted.
  77.  
  78.      Result:  The syntax will be changed to boolean.
  79.  
  80.  
  81.  
  82. Session Two - Internet Draft Discussion
  83.  
  84.    o ifOperStatus and Traps
  85.  
  86.      The group reporting back suggested that LinkUp and LinkDown traps
  87.      are generated only when there is a ifOperStatus state transition
  88.      into or out of the down(2) state (down(2) is interpreted as the
  89.      failure condition.)  For instance, no traps are generated on
  90.      transitions through the testing or unknown states.  Further, on
  91.      boot up the agent should transition out of ifOperStatus down(2) if
  92.      ifAdminStatus is up.  If ifAdminStatus is down, the agent should
  93.      transition to ifOperStatus down(2).
  94.  
  95.      Result:  The changes were accepted.
  96.  
  97.    o Promotion of the ether-like MIB (RFC 1398)
  98.  
  99.      Issues in progressing from Proposed Standard to Draft Standard.
  100.      There are some typos.  The ChipSet OID will be added since its
  101.      deleted from ifExtensions/interfaces.  The SNMPV1 macros need to be
  102.      changed to SNMPV2 macros.  There is a question if this MIB at Draft
  103.      status can rely on SNMPV2 which is currently proposed.
  104.  
  105.      Result:  Work will continue on the discussion list.
  106.  
  107.    o ifOutCongest and ifOutCongestThreshold
  108.  
  109.      Original author's proposal for ifOutQLen replacement.  The
  110.      ifOutCongest is a counter and ifOutCongestThreshold is read-write.
  111.  
  112.       -  Question if threshold is 0 then outCongest becomes a packet
  113.          counter equal to Ucast+Mcast+Bcast.
  114.  
  115.       -  Question how to implement if queue managed by packets.
  116.  
  117.       -  Question that outQLen did not involve any counting per packet
  118.          sent, while this proposal does.
  119.  
  120.      Result:  The proposal was not accepted.
  121.  
  122.    o TestTable
  123.  
  124.      It was questioned that the TestTable does use a semaphore to
  125.      reserve testing to one manager, but does not use a semaphore to
  126.      preserve the results of a test for the manager to read.  The answer
  127.      is that this is an unlikely event.  It was also stated that this
  128.      table enjoys little support (or opposition.)
  129.  
  130.      Result:  The working group does not feel that this is important
  131.      enough to either do a fix, or get rid of the testTable all
  132.      together, and suffer delay in promoting the MIB.
  133.  
  134.  
  135. This ended the discussion of the Interface Evolution MIB. The working
  136. group supported this version (with above edits) for consideration as a
  137. Proposed Standard.
  138.  
  139.  
  140.  
  141. Generic Connection Table
  142.  
  143. An initial presentation was made on the motivation for the current
  144. document, and a number of questions were raised, but not fully answered.
  145. There is concern as to whether this would delay the ATM and Frame Relay
  146. MIBs nearing completion now.
  147.  
  148. The following questions were raised:
  149.  
  150.  
  151.    o Will there be benefits to all constituencies from such a generic
  152.      model (ATM/Frame Relay or CNM/Device Management)?
  153.  
  154.    o What is the meaning of a connection AdminStatus versus media
  155.      specific AdminStatus?
  156.  
  157.    o Is cnTable mandatory?
  158.  
  159.    o Does cnTable contain any additional information to what is in the
  160.      media specific tables?
  161.  
  162.    o Is there a difference between CNM and device cross connect?
  163.  
  164.  
  165. There is a desire to pursue an effort on generic connection tables, but
  166. there is no desire to delay existing efforts; the ATM and Frame Relay
  167. MIBs will proceed as scheduled.  A generic connection effort will start,
  168. and be formulated as an independent addition to those efforts.  It is
  169. presumed that the questions raised at this meeting will be addressed as
  170. part of that effort.
  171.  
  172.  
  173. Attendees
  174.  
  175. Masuma Ahmed             mxa@mail.bellcore.com
  176. Fred Baker               fbaker@acc.com
  177. Jim Barnes               barnes@xylogics.com
  178. Bart Berger              bart_berger@3com.com
  179. Andy Bierman             abierman@synoptics.com
  180. Tracy Brown              tacox@mail.bellcore.com
  181. Theodore Brunner         tob@thumper.bellcore.com
  182. Lida Carrier             lida@apple.com
  183. Jeff Case                case@cs.utk.edu
  184. Chris Chiotasso          chris@lightstream.com
  185. Manuel Diaz              diaz@davidsys.com
  186. Jonathan Didner          jonb@bangate.compaq.com
  187. Kurt Dobbins             dobbins@ctron.com
  188. Christopher Dorsey       dorsey@es.net
  189. David Engel              david@ods.com
  190. William Fardy            billf@frontier.com
  191. Steve Feldman            feldman@mfsdatanet.com
  192. Robert Fenoglio          fenoglio@vnet.ibm.com
  193. Christine Gressley       gressley@uiuc.edu
  194. Stuart Hale              stu_hale@vnet.ibm.com
  195. Mike Holloway            mikeh@newbridge.com
  196. John Hopprich            hopprich@davidsys.com
  197. Refael Horev             horev@lannet.com
  198. Melanie Humphrey         msh@uiuc.edu
  199. Frank Kastenholz         kasten@ftp.com
  200. Mark Kepke               mak@fc.hp.com
  201. Michael Kornegay         mlk@bir.com
  202. Deirdre Kostick          dck2@mail.bellcore.com
  203. Cheryl Krupczak          cheryl@empiretech.com
  204. Joseph Liu               jliu@atg.wiltel.com
  205. Andrew Malis             malis@maelstrom.timeplex.com
  206. Peram Marimuthu          peram@wg.com
  207. Evan McGinnis            bem@3com.com
  208. Steve McRobert           steve.mcrobert@amd.com
  209. Rina Nathaniel           rina@rnd-gate.rad.co.il
  210. Sath Nelakonda           sath@lachman.com
  211. Orly Nicklass            orly@radmail.rad.co.il
  212. Tom Nisbet               nisbet@fbsw.tt.com
  213. Shannon Nix              sdn@netlink.com
  214. Bill Norton              wbn@merit.edu
  215. Steven Onishi            sonishi@wellfleet.com
  216. Zbigniew Opalka          zopalka@agile.com
  217. Eric Peterson            elpeterson@eng.xyplex.com
  218. Kenneth Rehbehn          kjr@netrix.com
  219. Kenneth Rodemann         krr@qsun.att.com
  220. Michal Rozenthal         michal@fibronics.co.il
  221. Jon Saperia              saperia@zko.dec.com
  222. Michael Scanlon          scanlon@ftp.com
  223. Jean-Bernard Schmitt     jbs@vnet.ibm.com
  224. Chi Shue                 chi@casc.com
  225. Timon Sloane             timon@timonware.com
  226. Andrew Smith             asmith@synoptics.com
  227. Robert Snyder            snyder@cisco.com
  228. Louis Steinberg          louiss@vnet.ibm.com
  229. Bob Stewart              rlstewart@eng.xyplex.com
  230. Adam Stolinski           stolinsk@cerf.net
  231. Kaj Tesink               kaj@cc.bellcore.com
  232. Michael Thatcher         thatcher@rahul.net
  233. Dean Throop              throop@dg-rtp.dg.com
  234. Steven Waldbusser        waldbusser@andrew.cmu.edu
  235. Alice Wang               alice.wang@eng.sun.com
  236. James Watt               james@newbridge.com
  237. Evan Wetstone            evanw@vnet.ibm.com
  238. Peter Wilson             peter_wilson@3mail.3com.com
  239.  
  240.