CURRENT_MEETING_REPORT_ Reported by Theodore Brunner/Bellcore Minutes of the Interfaces MIB Working Group (IFMIB) Discussion focussed on the ``Evolution of the Interfaces Group of MIB II'' Internet-Draft of October 20, 1993. The discussion reviewed issues raised on the mailing list and was the final forum for concerns about the Internet-Draft before it was forwarded from the IFMIB Working Group to the Area Director for consideration as a Proposed Standard. Evolution of the Interfaces Group of MIB II Internet-Draft o ifOperStatus and ifOperStatusDetail A suggestion was made on the mailing list to add more detail about why an interface is ``down.'' An example was given of an on-demand connection down for lack of traffic. IfOperStatusDetail was included in the document. A question was raised in the meeting as to what is a generic OID; all seemed media specific. An alternative to StatusDetail was suggested (actually an original suggestion on the list), of expanding ifOperStatus to include a ``down-non-failure'' state, in addition to the existing down(2) interpreted as ``down-failure.'' Result: The new ifOperStatus state was accepted and a group was delegated to work out the details and report back. o Counters A question was raised as to why ifXxxOctets is counted at the bottom of the interface stack while packets are counted at the top of the stack. It was answered that Octets-on-the-wire gives a measure of network utilization, while packets-on-the-wire would not. Result: There is no interest in changing the definition. o ifOutQLen A question was raised about why it is being deprecated. It was suggested that it has network debugging utility. A response was given that ifOutDiscards and the Ethernet MIB offer the same functionality. Following the last IFMIB meeting there had been a proposal sent out on the list of a redefinition of ifOutQLen, but it was not carried forward in the document, nor extensively discussed. Result: The authors will present it again to the working group. o ifStackTable A question was raised as to why there is no reverse of ifStackTable to directly read off the layer above. It was answered that one direction was sufficient; a manager loads the whole table upon startup and builds the entire layer mapping from it. The reverse direction would not be generally needed. Result: There was interest in changing the definition. o ifStackTable It was asked why is it easy to read top to bottom instead of bottom to top. The reason is that the IP layer references interfaces below it. Result: There is no interest in changing the definition. o ifConnector It was asked if the enumeration could be changed to an OID describing the plug, if it is a physical connection. It was decided that this is too complex; extensions are not wanted. Result: The syntax will be changed to boolean. Session Two - Internet Draft Discussion o ifOperStatus and Traps The group reporting back suggested that LinkUp and LinkDown traps are generated only when there is a ifOperStatus state transition into or out of the down(2) state (down(2) is interpreted as the failure condition.) For instance, no traps are generated on transitions through the testing or unknown states. Further, on boot up the agent should transition out of ifOperStatus down(2) if ifAdminStatus is up. If ifAdminStatus is down, the agent should transition to ifOperStatus down(2). Result: The changes were accepted. o Promotion of the ether-like MIB (RFC 1398) Issues in progressing from Proposed Standard to Draft Standard. There are some typos. The ChipSet OID will be added since its deleted from ifExtensions/interfaces. The SNMPV1 macros need to be changed to SNMPV2 macros. There is a question if this MIB at Draft status can rely on SNMPV2 which is currently proposed. Result: Work will continue on the discussion list. o ifOutCongest and ifOutCongestThreshold Original author's proposal for ifOutQLen replacement. The ifOutCongest is a counter and ifOutCongestThreshold is read-write. - Question if threshold is 0 then outCongest becomes a packet counter equal to Ucast+Mcast+Bcast. - Question how to implement if queue managed by packets. - Question that outQLen did not involve any counting per packet sent, while this proposal does. Result: The proposal was not accepted. o TestTable It was questioned that the TestTable does use a semaphore to reserve testing to one manager, but does not use a semaphore to preserve the results of a test for the manager to read. The answer is that this is an unlikely event. It was also stated that this table enjoys little support (or opposition.) Result: The working group does not feel that this is important enough to either do a fix, or get rid of the testTable all together, and suffer delay in promoting the MIB. This ended the discussion of the Interface Evolution MIB. The working group supported this version (with above edits) for consideration as a Proposed Standard. Generic Connection Table An initial presentation was made on the motivation for the current document, and a number of questions were raised, but not fully answered. There is concern as to whether this would delay the ATM and Frame Relay MIBs nearing completion now. The following questions were raised: o Will there be benefits to all constituencies from such a generic model (ATM/Frame Relay or CNM/Device Management)? o What is the meaning of a connection AdminStatus versus media specific AdminStatus? o Is cnTable mandatory? o Does cnTable contain any additional information to what is in the media specific tables? o Is there a difference between CNM and device cross connect? There is a desire to pursue an effort on generic connection tables, but there is no desire to delay existing efforts; the ATM and Frame Relay MIBs will proceed as scheduled. A generic connection effort will start, and be formulated as an independent addition to those efforts. It is presumed that the questions raised at this meeting will be addressed as part of that effort. Attendees Masuma Ahmed mxa@mail.bellcore.com Fred Baker fbaker@acc.com Jim Barnes barnes@xylogics.com Bart Berger bart_berger@3com.com Andy Bierman abierman@synoptics.com Tracy Brown tacox@mail.bellcore.com Theodore Brunner tob@thumper.bellcore.com Lida Carrier lida@apple.com Jeff Case case@cs.utk.edu Chris Chiotasso chris@lightstream.com Manuel Diaz diaz@davidsys.com Jonathan Didner jonb@bangate.compaq.com Kurt Dobbins dobbins@ctron.com Christopher Dorsey dorsey@es.net David Engel david@ods.com William Fardy billf@frontier.com Steve Feldman feldman@mfsdatanet.com Robert Fenoglio fenoglio@vnet.ibm.com Christine Gressley gressley@uiuc.edu Stuart Hale stu_hale@vnet.ibm.com Mike Holloway mikeh@newbridge.com John Hopprich hopprich@davidsys.com Refael Horev horev@lannet.com Melanie Humphrey msh@uiuc.edu Frank Kastenholz kasten@ftp.com Mark Kepke mak@fc.hp.com Michael Kornegay mlk@bir.com Deirdre Kostick dck2@mail.bellcore.com Cheryl Krupczak cheryl@empiretech.com Joseph Liu jliu@atg.wiltel.com Andrew Malis malis@maelstrom.timeplex.com Peram Marimuthu peram@wg.com Evan McGinnis bem@3com.com Steve McRobert steve.mcrobert@amd.com Rina Nathaniel rina@rnd-gate.rad.co.il Sath Nelakonda sath@lachman.com Orly Nicklass orly@radmail.rad.co.il Tom Nisbet nisbet@fbsw.tt.com Shannon Nix sdn@netlink.com Bill Norton wbn@merit.edu Steven Onishi sonishi@wellfleet.com Zbigniew Opalka zopalka@agile.com Eric Peterson elpeterson@eng.xyplex.com Kenneth Rehbehn kjr@netrix.com Kenneth Rodemann krr@qsun.att.com Michal Rozenthal michal@fibronics.co.il Jon Saperia saperia@zko.dec.com Michael Scanlon scanlon@ftp.com Jean-Bernard Schmitt jbs@vnet.ibm.com Chi Shue chi@casc.com Timon Sloane timon@timonware.com Andrew Smith asmith@synoptics.com Robert Snyder snyder@cisco.com Louis Steinberg louiss@vnet.ibm.com Bob Stewart rlstewart@eng.xyplex.com Adam Stolinski stolinsk@cerf.net Kaj Tesink kaj@cc.bellcore.com Michael Thatcher thatcher@rahul.net Dean Throop throop@dg-rtp.dg.com Steven Waldbusser waldbusser@andrew.cmu.edu Alice Wang alice.wang@eng.sun.com James Watt james@newbridge.com Evan Wetstone evanw@vnet.ibm.com Peter Wilson peter_wilson@3mail.3com.com