CURRENT_MEETING_REPORT_
Reported by Donna McMaster/SynOptics
Minutes of IEEE 802.3 Hub MIB Working Group (HUBMIB)
The meeting was called to order at 9:40 a.m. by co-Chairs Donna
McMaster and Keith McCloghrie.
IEEE Report
Geoff Thompson, Executive Secretary of IEEE 802.3 Repeater Management
Task Force, reported on the Task Force's status. The IEEE's Repeater
MIB was approved last September and published last November, and has
been submitted to ISO where it is undergoing a 30-day CD ballot. A few
editorial changes are being submitted as comments from the United
States. The IEEE's MAU MIB has undergone two rounds of balloting and is
expected to be approved and published by July 1993, and be submitted to
ISO soon after. The organization of the specification has been changed
to be protocol-independent with the GDMO-specification in a normative
Annex. This allows, for example, the sizes of counters to be made
protocol-specific.
MAU MIB
A message to the mailing-list had questioned the value of mauJabberState
because that state was so short-lived. The meeting agreed that this was
not the case since the Jabber state is not exited until reset, and thus
decided to leave the document as-is.
The question of if and how to represent an interface/port/mau used only
to manage a repeater was discussed. Normally, these are internal to a
device and thus often proprietary, and in fact such a MAU might
effectively be null, in which case there was no need to have MIB objects
for it. Even if the MAU wasn't null, rpMauType could have an
enterprise-specific OBJECT IDENTIFIER value. It was agreed to add a
sentence or two to the Overview section of the MAU MIB to explain this.
The suggestion to add a diagram to the document was rejected, since it
was thought the issues were too vendor- specific to be able to reach
agreement on a diagram.
A suggestion to change the name of mauJabberStateChanges was accepted in
order to better reflect the behavior of the object, since it only counts
the times the 'jabber' state is entered, not all state changes.
Repeater MIB
There was lengthy discussion on rptrAddrTrackLastSourceAddress. The MIB
editors had made a suggestion to the mailing-list prior to the meeting
to specify that a noSuch error/exception should be returned prior to the
first frame being received on a port. Responses on the mailing-list had
1
preferred other approaches. All the possible solutions discussed at the
previous meeting were again listed and discussed at this meeting, with
the addition of having the object be initialized with the well-known MAC
address defined for use in FDDI. By a process of elimination, an
agreement was reached on the solution of deprecating the object and
defining a replacement which would have a zero-length value until the
first frame was received on the port.
Other minor changes were agreed to, including:
o The nonDisruptiveSelfTest description should be clarified to allow
returning ``ok'' after doing only a trivial test.
o The setting of rptrReset to cause the Repeater to reset should
allow the agent to delay the reset (for a short period) if it so
wishes (e.g., to allow the SNMP Response to be transmitted).
At this point, the scheduled time for the Working Group meeting expired.
Some of the participants left to meet other scheduled commitments, while
others continued to discuss items informally until 12:30 p.m. In
addition, a second informal meeting was held from 1:30 p.m. - 3:30 p.m.
to continue discussion of open issues.
First Informal Meeting
On the topic of having a ``repeater index'' in the MIB, nobody remaining
in the meeting had much to say. A few implementors thought it might
make it easier to manage multiple repeaters, but nobody still in the
meeting wanted to change the MIB.
The requirements for progression to Draft Standard status were reviewed.
There were at least nine implementations of the MIB represented at the
meeting. Donna asked the participants if they felt that there was
enough implementation experience. It was agreed that there was enough
implementation experience, but perhaps not enough interoperability
experience.
Bob Stewart observed that all of our implementations of the MIB are of
agents, but that agents don't interoperate with each other; manager
implementations are required for interoperability experience. All of
the agents have interoperated with ``MIB browser'' applications, but no
known MIB-specific management applications had been written.
The participants agreed that a call should be issued on the mailing list
for NMS implementors to let the Group know what kind of applications
they're working on, and what implementation and/or interoperability
experience they have. Donna and Keith will consider talking to the
press to publicize the status of the MIB and encourage implementors to
write applications that utilize the Repeater MIB information.
One person observed that the Group had no multiple instantiation
2
implementation experience. It was pointed out that this wasn't part of
the Standard.
Dave Perkins questioned whether there was enough operational experience
with the objects in the MIB. Donna observed that there is considerable
operational experience with similar objects in enterprise MIBs.
The participants concluded that there was enough experience to move the
MIB forward as a Draft Standard. Therefore it was decided that the
editors will make the few agreed-upon changes to the Draft and submit
the new MIB to the mailing list for three weeks review. If no
unresolved issues arise on the mailing list in that time, the Draft will
be forwarded to the IESG.
The same actions and schedule are to apply to the MAU MIB.
Second Informal Meeting
About eight Working Group members met informally to discuss informative
text that could be added to the Repeater MIB and/or MAU MIB documents to
help readers understand the implementation options for the repeater
port(s) through which management packets are transmitted and received.
The text generated by this group, below, will be included in the next
Repeater MIB draft, to be reviewed by the Working Group.
o Describe ports as sources of traffic into the repeater, with
examples such as:
- Externally connected devices such as 10BASE-T or AUI.
- Internal management ports.
- Backplane internal to implementation.
o Some implementations may not manage all of the ports. For managed
ports, there must be entries in the port table.
o It is the decision of the implementor to select the appropriate
group(s) in which to place internal ports. GroupCapacity for a
given group always reflects the number of the number of MANAGED
ports in that group.
o If some ports are unmanaged such that not all packet sources are
represented by managed ports, then the sum of the input counters
for the repeater will not equal the actual output of the repeater.
Next Meeting
It was agreed not to hold a meeting during the next IETF meeting in
Amsterdam.
3
Attendees
David Arneson arneson@ctron.com
David Battle battle@cs.utk.edu
Andy Bierman abierman@synoptics.com
Jack Brown jbrown@huachuca-emh8.army.mil
Jeff Case case@cs.utk.edu
John Chang changj@ralvm6.vnet.ibm.com
Shane Dawalt sdawalt@desire.wright.edu
Manuel Diaz diaz@davidsys.com
Sandra Durham sdurham@synoptics.com
David Engel david@ods.com
John Hopprich hopprich@davidsys.com
Jeff Hughes jeff@col.hp.com
Kenneth Key key@cs.utk.edu
Moshe Kochinski moshek@FibHaifa.com
Duane Kuang duanek@kalpana.com
Carl Madison carl@startek.com
Keith McCloghrie kzm@hls.com
Evan McGinnis bem@3com.com
Donna McMaster mcmaster@synoptics.com
David Perkins dperkins@synoptics.com
Sam Roberts sroberts@farallon.com
Dan Romascanu dan@lannet.com
Rick Royston rick@lsumvs.sncc.lsu.edu
Paul Serice serice@cos.com
Chris Shaw cshaw@banyan.com
Timon Sloane timon@timon.com
Ira Steckler isteckle@chipcom.com
Bob Stewart rlstewart@eng.xyplex.com
Steve Suzuki suzu@fet.com
Geoffrey Thompson thompson@synoptics.com
Stephen Tsun snt@3com.com
Peter Wilson peter_wilson@3com.com
Kiho Yum kxy@nsd.3com.com
4