home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rmonmib / rmonmib-minutes-96mar.txt < prev    next >
Text File  |  1996-05-24  |  8KB  |  194 lines
  1. Editor's note:  These notes have not been edited.
  2.  
  3.  
  4. Meeting Minutes -- 35th IETF; Los Angeles, CA
  5. Area:    Network Management
  6. WG:      rmonmib
  7. Date:    6 March 1996
  8. Email:   rmonmib@cisco.com
  9. Archive: ftp://ftp.cisco.com/ftp/rmonmib/rmonmib
  10.  
  11. WG Chair (& meeting minutes):
  12.      Andy Bierman      <abierman@cisco.com>
  13. Area Advisor (& WG Editor):
  14.      Steve Waldbusser  <waldbusser@ins.com>
  15. _______________________________________________________
  16. Agenda
  17. ------
  18.     1) agenda bashing
  19.     2) general RMON-2 MIB corrections
  20.     3) usrHistoryTable corrections
  21.     4) RMON Protocol Identifiers document
  22.     5) TimeFilter Issues
  23.     6) Counter64 Issues
  24.     7) RMON-2 Implementation Issues
  25.     8) Future RMON work 
  26.  
  27. Materials
  28. ---------
  29.     >> draft-ietf-rmonmib-rmon2-03.txt
  30.     >> draft-ietf-rmonmib-rmonprot-01.txt
  31.  
  32. Summary
  33. -------
  34. The Chair presented a series of issues regarding the current RMON-2 IDs.
  35. The WG discussed and resolved (when possible) each issue in turn, within
  36. the time allotted.
  37.  
  38. 1) agenda bashing
  39. -----------------
  40. The agenda was accepted without comment.
  41.                                                   
  42. 2) general RMON-2 MIB corrections
  43. ---------------------------------
  44. Minor typos, clarifications, and cosmetic changes were listed and discussed
  45. briefly. The next I-D for the MIB will contain the appropriate corrections.
  46.  
  47. MIB change: 
  48.      *MatrixTopNRate objects have SYNTAX Integer32; this will be changed 
  49.      to SYNTAX Gauge32
  50.  
  51. 3) usrHistoryTable Corrections
  52. ------------------------------
  53. The DESCRIPTION clauses are incorrect concerning usrHistory  control  table
  54. row creation and row deletion behavior. Clarifying text will be added to the
  55. next I-D stating that the usrHistoryObjectTable can exist when the
  56. associated usrHistoryControlStatus is not equal to 'active(1)'.
  57.  
  58. Also related to row creation, the WG clarified that the usrHistoryControl
  59. entries can be activated, even if the associated usrHistoryObjectTable has
  60. not been fully configured by the management station. Un-configured
  61. usrHistoryObject instances should default to { 0 0 }, and each associated
  62. instance of usrHistoryValStatus should be set to 'valueNotPresent(1)'. 
  63.  
  64. 4) RMON Protocol Identifiers (PI) document
  65. ------------------------------------------
  66. The completion possibilities for this document were discussed. The current
  67. draft does not contain a complete set of network and transport layer protocol
  68. macro identifiers. Enough are present to support most network layer protocols,
  69. but there is minimal support for transport layer protocols other than UDP
  70. or TCP. It should be noted that only protocols that encapsulate other 
  71. (child) protocols within them need to be documented before they can be
  72. encoded in a protocolDirID string. 
  73.  
  74. The WG considered email and meeting suggestions:
  75.    1) split into a base document and separate protocol-family-specific
  76.       documents; publish the base document now, with others to follow as
  77.       finished.
  78.    2) hold back publication of RMON-2 until more macros are produced
  79.       (email-ed by WG members to the list).
  80.    3) Consider the document to be a work-in-progress; publish now, and
  81.       collect PI macros on the mailing list until enough are completed for
  82.       additional publication. Up to 3 updates over the next 2 years may be
  83.       required.
  84. The WG decided to proceed with approach '3'.
  85.  
  86. Another PI document issue was discussed regarding the ongoing addition of
  87. enumerations to the list of 'workgroup-assigned' values.  The possibility of
  88. asking IANA to maintain the enumeration list (e.g. IANAIfType) was discussed.
  89. The details of this task will be finalized on the mailing list.  The list
  90. currently contains one entry.  Presumably, more entries will be defined over
  91. time.  A WEB page to help facilitate PI collection may be maintained by
  92. InterWorking Labs.
  93.  
  94. The format of the workgroup assigned list was discussed, with the possibility
  95. of creating some limited hierarchical structure to the enumeration list. 
  96. (e.g. IPX family instead of 'rawIpxOver802.3').  No consensus or details were
  97. finalized and this issue will be discussed further on the mailing list.
  98.  
  99. 5) TimeFilter Issues
  100. --------------------
  101. Minor clarification to the TimeFilter TC:  TimeMark values do not need to be
  102. updated when rows are deleted.
  103.  
  104. The WG discussed the intended behavior of the TimeFilter; whether the TC
  105. scope should be per-conceptual-row, or per-instance in each row. It was
  106. agreed that the current defined behavior (per row) was more desirable and
  107. no changes to the TC will be made. MIB designers should attempt to group
  108. objects within the same 'time-filtered' conceptual row, such that all or most
  109. of the objects are expected to change value with similar frequency.
  110.  
  111. 6) Counter64 Issues
  112. -------------------
  113. The WG has been asked to consider some level of SNMPv1 and/or SNMPv2c support
  114. for Counter64 octet counters in the applicable  RMON-2 tables. 
  115.  
  116. First, the time-frame of any such changes was discussed:
  117.     >> now -- published with the initial RFC
  118.     >> soon -- published within 4 months of the initial RFC
  119.     >> later -- published if and when RMON-2 is updated
  120. WG consensus was to address this problem in the next 4 months.
  121.  
  122. Several approaches were then discussed, which had been posted to the mailing
  123. list:
  124.  SNMPv2c:
  125.     >> Counter64 from RFC 1902
  126.  SNMPv1:
  127.     >> OCTET STRING ((SIZE(8))
  128.     >> Opaque
  129.     >> Counter32/Counter32 pair -- atomic-get requirement on agent
  130.     >> Counter32/Counter32 pair -- no atomic-get requirement
  131.     >> scaled Counter32
  132.     >> any combination of one SNMPv1 approach and Counter64
  133. There was strong WG consensus in favor of a Counter32/Counter32 pair as
  134. well as a Counter64 object.
  135.  
  136. 7) RMON-2 Implementation Issues
  137. -------------------------------
  138. Three types of implementation issues were discussed:
  139.     >> Interoperability
  140.     >> Conformance
  141.     >> Performance
  142.     
  143. The WG was asked to consider developing a new bulk data transfer mechanism for
  144. inclusion in RMON-2. There was no WG consensus to hold up RMON-2 to start this
  145. development effort. There was general WG consensus that data transfer
  146. improvement would be beneficial, but there wasn't clear consensus on which 
  147. time-frame, WG, or approach would be appropriate.  The WG decided that the 
  148. mailing list will remain open for discussion of interoperability issues and 
  149. other RMON-related issues, even though the RMON-2 work is drawing to a close.
  150.  
  151. The WG discussed various aspects of a possible interoperability test  event:
  152.     >> Time-frame
  153.     >> Scope
  154.     >> Ground Rules
  155.     >> Logistics
  156.  
  157. The WG agreed to schedule a test event in the July 1996 time-frame, Possible
  158. facilities will be investigated, as well as possible sponsors. Chris Wellens
  159. offered to have her company (InterWorking Labs) facilitate the test event
  160. details (chrisw@iwl.com), which seemed acceptable to the WG members present.
  161. Test participants would be expected to pay an entry fee and sign and abide
  162. by the ground rules agreement.  The scope would be limited to basic RMON-2
  163. NMS and agent interoperability tests for all groups. Some obvious areas of 
  164. concern include row creation, protocol directory and the TimeFilter index.
  165. Tests would be done under complete non-disclosure and test scripts would be
  166. available in advance to the event participants.  Details for the test event
  167. will be finalized on the mailing list.
  168.  
  169. 8) future RMON work 
  170. -------------------
  171. Future rmonmib WG endeavors were briefly discussed. Possibilities include:
  172.  * RMON for other media:
  173.     >> ATM-RMON
  174.     >> Switched & 100 MBit Ethernet
  175.     >> FDDI-RMON
  176.     >> WAN-RMON
  177.  * Data Aggregation and other optimizations
  178.     >> high-level RMON-MIB for mid-level managers
  179.     >> collection by subnet or address mask
  180.     >> Counter64
  181.     >> more efficient data transfer mechanisms
  182.  
  183. The WG agreed to use the existing mailing list to discuss proposals for
  184. future RMON work. WG members are encouraged to submit internet drafts for
  185. consideration by the group. Comments on the drafts should be sent to the
  186. mailing list.
  187.  
  188. The WG agreed to request a BOF session at the next IETF (Montreal). The 
  189. session will be open first to prepared presentations, then open (time 
  190. permitting) to presentations from the floor. The goal of the BOF will be to
  191. identify areas of common interest for future rmonmib WG efforts. Currently,
  192. one proposal for future RMON work exists:   
  193.     >> draft-bierman-rmon-atmrmon-00.txt
  194.