home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / hubmib / hubmib-minutes-93mar.txt < prev    next >
Text File  |  1993-05-18  |  9KB  |  218 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Donna McMaster/SynOptics
  5.  
  6. Minutes of IEEE 802.3 Hub MIB Working Group (HUBMIB)
  7.  
  8. The meeting was called to order at 9:40 a.m.  by co-Chairs Donna
  9. McMaster and Keith McCloghrie.
  10.  
  11. IEEE Report
  12.  
  13. Geoff Thompson, Executive Secretary of IEEE 802.3 Repeater Management
  14. Task Force, reported on the Task Force's status.  The IEEE's Repeater
  15. MIB was approved last September and published last November, and has
  16. been submitted to ISO where it is undergoing a 30-day CD ballot.  A few
  17. editorial changes are being submitted as comments from the United
  18. States.  The IEEE's MAU MIB has undergone two rounds of balloting and is
  19. expected to be approved and published by July 1993, and be submitted to
  20. ISO soon after.  The organization of the specification has been changed
  21. to be protocol-independent with the GDMO-specification in a normative
  22. Annex.  This allows, for example, the sizes of counters to be made
  23. protocol-specific.
  24.  
  25. MAU MIB
  26.  
  27. A message to the mailing-list had questioned the value of mauJabberState
  28. because that state was so short-lived.  The meeting agreed that this was
  29. not the case since the Jabber state is not exited until reset, and thus
  30. decided to leave the document as-is.
  31.  
  32. The question of if and how to represent an interface/port/mau used only
  33. to manage a repeater was discussed.  Normally, these are internal to a
  34. device and thus often proprietary, and in fact such a MAU might
  35. effectively be null, in which case there was no need to have MIB objects
  36. for it.  Even if the MAU wasn't null, rpMauType could have an
  37. enterprise-specific OBJECT IDENTIFIER value.  It was agreed to add a
  38. sentence or two to the Overview section of the MAU MIB to explain this.
  39. The suggestion to add a diagram to the document was rejected, since it
  40. was thought the issues were too vendor- specific to be able to reach
  41. agreement on a diagram.
  42.  
  43. A suggestion to change the name of mauJabberStateChanges was accepted in
  44. order to better reflect the behavior of the object, since it only counts
  45. the times the 'jabber' state is entered, not all state changes.
  46.  
  47. Repeater MIB
  48.  
  49. There was lengthy discussion on rptrAddrTrackLastSourceAddress.  The MIB
  50. editors had made a suggestion to the mailing-list prior to the meeting
  51. to specify that a noSuch error/exception should be returned prior to the
  52. first frame being received on a port.  Responses on the mailing-list had
  53.  
  54.                                    1
  55.  
  56.  
  57.  
  58.  
  59.  
  60. preferred other approaches.  All the possible solutions discussed at the
  61. previous meeting were again listed and discussed at this meeting, with
  62. the addition of having the object be initialized with the well-known MAC
  63. address defined for use in FDDI. By a process of elimination, an
  64. agreement was reached on the solution of deprecating the object and
  65. defining a replacement which would have a zero-length value until the
  66. first frame was received on the port.
  67.  
  68. Other minor changes were agreed to, including:
  69.  
  70.  
  71.    o The nonDisruptiveSelfTest description should be clarified to allow
  72.      returning ``ok'' after doing only a trivial test.
  73.  
  74.    o The setting of rptrReset to cause the Repeater to reset should
  75.      allow the agent to delay the reset (for a short period) if it so
  76.      wishes (e.g., to allow the SNMP Response to be transmitted).
  77.  
  78.  
  79. At this point, the scheduled time for the Working Group meeting expired.
  80. Some of the participants left to meet other scheduled commitments, while
  81. others continued to discuss items informally until 12:30 p.m.  In
  82. addition, a second informal meeting was held from 1:30 p.m.  - 3:30 p.m.
  83. to continue discussion of open issues.
  84.  
  85. First Informal Meeting
  86.  
  87. On the topic of having a ``repeater index'' in the MIB, nobody remaining
  88. in the meeting had much to say.  A few implementors thought it might
  89. make it easier to manage multiple repeaters, but nobody still in the
  90. meeting wanted to change the MIB.
  91.  
  92. The requirements for progression to Draft Standard status were reviewed.
  93. There were at least nine implementations of the MIB represented at the
  94. meeting.  Donna asked the participants if they felt that there was
  95. enough implementation experience.  It was agreed that there was enough
  96. implementation experience, but perhaps not enough interoperability
  97. experience.
  98.  
  99. Bob Stewart observed that all of our implementations of the MIB are of
  100. agents, but that agents don't interoperate with each other; manager
  101. implementations are required for interoperability experience.  All of
  102. the agents have interoperated with ``MIB browser'' applications, but no
  103. known MIB-specific management applications had been written.
  104.  
  105. The participants agreed that a call should be issued on the mailing list
  106. for NMS implementors to let the Group know what kind of applications
  107. they're working on, and what implementation and/or interoperability
  108. experience they have.  Donna and Keith will consider talking to the
  109. press to publicize the status of the MIB and encourage implementors to
  110. write applications that utilize the Repeater MIB information.
  111.  
  112. One person observed that the Group had no multiple instantiation
  113.  
  114.                                    2
  115.  
  116.  
  117.  
  118.  
  119.  
  120. implementation experience.  It was pointed out that this wasn't part of
  121. the Standard.
  122.  
  123. Dave Perkins questioned whether there was enough operational experience
  124. with the objects in the MIB. Donna observed that there is considerable
  125. operational experience with similar objects in enterprise MIBs.
  126.  
  127. The participants concluded that there was enough experience to move the
  128. MIB forward as a Draft Standard.  Therefore it was decided that the
  129. editors will make the few agreed-upon changes to the Draft and submit
  130. the new MIB to the mailing list for three weeks review.  If no
  131. unresolved issues arise on the mailing list in that time, the Draft will
  132. be forwarded to the IESG.
  133.  
  134. The same actions and schedule are to apply to the MAU MIB.
  135.  
  136. Second Informal Meeting
  137.  
  138. About eight Working Group members met informally to discuss informative
  139. text that could be added to the Repeater MIB and/or MAU MIB documents to
  140. help readers understand the implementation options for the repeater
  141. port(s) through which management packets are transmitted and received.
  142. The text generated by this group, below, will be included in the next
  143. Repeater MIB draft, to be reviewed by the Working Group.
  144.  
  145.  
  146.    o Describe ports as sources of traffic into the repeater, with
  147.      examples such as:
  148.  
  149.       -  Externally connected devices such as 10BASE-T or AUI.
  150.       -  Internal management ports.
  151.       -  Backplane internal to implementation.
  152.  
  153.  
  154.    o Some implementations may not manage all of the ports.  For managed
  155.      ports, there must be entries in the port table.
  156.  
  157.    o It is the decision of the implementor to select the appropriate
  158.      group(s) in which to place internal ports.  GroupCapacity for a
  159.      given group always reflects the number of the number of MANAGED
  160.      ports in that group.
  161.  
  162.    o If some ports are unmanaged such that not all packet sources are
  163.      represented by managed ports, then the sum of the input counters
  164.      for the repeater will not equal the actual output of the repeater.
  165.  
  166.  
  167. Next Meeting
  168.  
  169. It was agreed not to hold a meeting during the next IETF meeting in
  170. Amsterdam.
  171.  
  172.  
  173.                                    3
  174.  
  175.  
  176.  
  177.  
  178.  
  179. Attendees
  180.  
  181. David Arneson            arneson@ctron.com
  182. David Battle             battle@cs.utk.edu
  183. Andy Bierman             abierman@synoptics.com
  184. Jack Brown               jbrown@huachuca-emh8.army.mil
  185. Jeff Case                case@cs.utk.edu
  186. John Chang               changj@ralvm6.vnet.ibm.com
  187. Shane Dawalt             sdawalt@desire.wright.edu
  188. Manuel Diaz              diaz@davidsys.com
  189. Sandra Durham            sdurham@synoptics.com
  190. David Engel              david@ods.com
  191. John Hopprich            hopprich@davidsys.com
  192. Jeff Hughes              jeff@col.hp.com
  193. Kenneth Key              key@cs.utk.edu
  194. Moshe Kochinski          moshek@FibHaifa.com
  195. Duane Kuang              duanek@kalpana.com
  196. Carl Madison             carl@startek.com
  197. Keith McCloghrie         kzm@hls.com
  198. Evan McGinnis            bem@3com.com
  199. Donna McMaster           mcmaster@synoptics.com
  200. David Perkins            dperkins@synoptics.com
  201. Sam Roberts              sroberts@farallon.com
  202. Dan Romascanu            dan@lannet.com
  203. Rick Royston             rick@lsumvs.sncc.lsu.edu
  204. Paul Serice              serice@cos.com
  205. Chris Shaw               cshaw@banyan.com
  206. Timon Sloane             timon@timon.com
  207. Ira Steckler             isteckle@chipcom.com
  208. Bob Stewart              rlstewart@eng.xyplex.com
  209. Steve Suzuki             suzu@fet.com
  210. Geoffrey Thompson        thompson@synoptics.com
  211. Stephen Tsun             snt@3com.com
  212. Peter Wilson             peter_wilson@3com.com
  213. Kiho Yum                 kxy@nsd.3com.com
  214.  
  215.  
  216.  
  217.                                    4
  218.