Editor's note: These notes have not been edited. Meeting Minutes -- 35th IETF; Los Angeles, CA Area: Network Management WG: rmonmib Date: 6 March 1996 Email: rmonmib@cisco.com Archive: ftp://ftp.cisco.com/ftp/rmonmib/rmonmib WG Chair (& meeting minutes): Andy Bierman Area Advisor (& WG Editor): Steve Waldbusser _______________________________________________________ Agenda ------ 1) agenda bashing 2) general RMON-2 MIB corrections 3) usrHistoryTable corrections 4) RMON Protocol Identifiers document 5) TimeFilter Issues 6) Counter64 Issues 7) RMON-2 Implementation Issues 8) Future RMON work Materials --------- >> draft-ietf-rmonmib-rmon2-03.txt >> draft-ietf-rmonmib-rmonprot-01.txt Summary ------- The Chair presented a series of issues regarding the current RMON-2 IDs. The WG discussed and resolved (when possible) each issue in turn, within the time allotted. 1) agenda bashing ----------------- The agenda was accepted without comment. 2) general RMON-2 MIB corrections --------------------------------- Minor typos, clarifications, and cosmetic changes were listed and discussed briefly. The next I-D for the MIB will contain the appropriate corrections. MIB change: *MatrixTopNRate objects have SYNTAX Integer32; this will be changed to SYNTAX Gauge32 3) usrHistoryTable Corrections ------------------------------ The DESCRIPTION clauses are incorrect concerning usrHistory control table row creation and row deletion behavior. Clarifying text will be added to the next I-D stating that the usrHistoryObjectTable can exist when the associated usrHistoryControlStatus is not equal to 'active(1)'. Also related to row creation, the WG clarified that the usrHistoryControl entries can be activated, even if the associated usrHistoryObjectTable has not been fully configured by the management station. Un-configured usrHistoryObject instances should default to { 0 0 }, and each associated instance of usrHistoryValStatus should be set to 'valueNotPresent(1)'. 4) RMON Protocol Identifiers (PI) document ------------------------------------------ The completion possibilities for this document were discussed. The current draft does not contain a complete set of network and transport layer protocol macro identifiers. Enough are present to support most network layer protocols, but there is minimal support for transport layer protocols other than UDP or TCP. It should be noted that only protocols that encapsulate other (child) protocols within them need to be documented before they can be encoded in a protocolDirID string. The WG considered email and meeting suggestions: 1) split into a base document and separate protocol-family-specific documents; publish the base document now, with others to follow as finished. 2) hold back publication of RMON-2 until more macros are produced (email-ed by WG members to the list). 3) Consider the document to be a work-in-progress; publish now, and collect PI macros on the mailing list until enough are completed for additional publication. Up to 3 updates over the next 2 years may be required. The WG decided to proceed with approach '3'. Another PI document issue was discussed regarding the ongoing addition of enumerations to the list of 'workgroup-assigned' values. The possibility of asking IANA to maintain the enumeration list (e.g. IANAIfType) was discussed. The details of this task will be finalized on the mailing list. The list currently contains one entry. Presumably, more entries will be defined over time. A WEB page to help facilitate PI collection may be maintained by InterWorking Labs. The format of the workgroup assigned list was discussed, with the possibility of creating some limited hierarchical structure to the enumeration list. (e.g. IPX family instead of 'rawIpxOver802.3'). No consensus or details were finalized and this issue will be discussed further on the mailing list. 5) TimeFilter Issues -------------------- Minor clarification to the TimeFilter TC: TimeMark values do not need to be updated when rows are deleted. The WG discussed the intended behavior of the TimeFilter; whether the TC scope should be per-conceptual-row, or per-instance in each row. It was agreed that the current defined behavior (per row) was more desirable and no changes to the TC will be made. MIB designers should attempt to group objects within the same 'time-filtered' conceptual row, such that all or most of the objects are expected to change value with similar frequency. 6) Counter64 Issues ------------------- The WG has been asked to consider some level of SNMPv1 and/or SNMPv2c support for Counter64 octet counters in the applicable RMON-2 tables. First, the time-frame of any such changes was discussed: >> now -- published with the initial RFC >> soon -- published within 4 months of the initial RFC >> later -- published if and when RMON-2 is updated WG consensus was to address this problem in the next 4 months. Several approaches were then discussed, which had been posted to the mailing list: SNMPv2c: >> Counter64 from RFC 1902 SNMPv1: >> OCTET STRING ((SIZE(8)) >> Opaque >> Counter32/Counter32 pair -- atomic-get requirement on agent >> Counter32/Counter32 pair -- no atomic-get requirement >> scaled Counter32 >> any combination of one SNMPv1 approach and Counter64 There was strong WG consensus in favor of a Counter32/Counter32 pair as well as a Counter64 object. 7) RMON-2 Implementation Issues ------------------------------- Three types of implementation issues were discussed: >> Interoperability >> Conformance >> Performance The WG was asked to consider developing a new bulk data transfer mechanism for inclusion in RMON-2. There was no WG consensus to hold up RMON-2 to start this development effort. There was general WG consensus that data transfer improvement would be beneficial, but there wasn't clear consensus on which time-frame, WG, or approach would be appropriate. The WG decided that the mailing list will remain open for discussion of interoperability issues and other RMON-related issues, even though the RMON-2 work is drawing to a close. The WG discussed various aspects of a possible interoperability test event: >> Time-frame >> Scope >> Ground Rules >> Logistics The WG agreed to schedule a test event in the July 1996 time-frame, Possible facilities will be investigated, as well as possible sponsors. Chris Wellens offered to have her company (InterWorking Labs) facilitate the test event details (chrisw@iwl.com), which seemed acceptable to the WG members present. Test participants would be expected to pay an entry fee and sign and abide by the ground rules agreement. The scope would be limited to basic RMON-2 NMS and agent interoperability tests for all groups. Some obvious areas of concern include row creation, protocol directory and the TimeFilter index. Tests would be done under complete non-disclosure and test scripts would be available in advance to the event participants. Details for the test event will be finalized on the mailing list. 8) future RMON work ------------------- Future rmonmib WG endeavors were briefly discussed. Possibilities include: * RMON for other media: >> ATM-RMON >> Switched & 100 MBit Ethernet >> FDDI-RMON >> WAN-RMON * Data Aggregation and other optimizations >> high-level RMON-MIB for mid-level managers >> collection by subnet or address mask >> Counter64 >> more efficient data transfer mechanisms The WG agreed to use the existing mailing list to discuss proposals for future RMON work. WG members are encouraged to submit internet drafts for consideration by the group. Comments on the drafts should be sent to the mailing list. The WG agreed to request a BOF session at the next IETF (Montreal). The session will be open first to prepared presentations, then open (time permitting) to presentations from the floor. The goal of the BOF will be to identify areas of common interest for future rmonmib WG efforts. Currently, one proposal for future RMON work exists: >> draft-bierman-rmon-atmrmon-00.txt