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