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