INTERIM_MEETING_REPORT_

Reported by Andy Bierman/cisco Systems

Minutes of the Remote LAN Monitoring Working Group (RMONMIB)

RMONMIB held an interim meeting in Santa Clara, CA on 21-22 November
1994.  The meeting was sponsored by Bay Networks, Inc.


Meeting Materials

   o summary.grp -- Latest feature wish list (posted November 20)
   o summary.lng -- Latest collection of related e-mail on each feature
     listed in summary.grp (posted in 2 parts November 20)
   o rmon-mail-agenda -- Meeting agenda (posted November 9)
   o robin.txt -- Long list of comments from Robin Iddon on RMON2
     features and the AXON ECAM MIB (posted November 15)
   o ecammib.my -- AXON ECAM MIB (posted November 15)
   o hpaxon.mib -- RMON Probe Configuration MIB (`Aspen MIB') (posted
     November 15)


Executive Summary

All potential additions, deletions, and modifications to RMON (made
available to the working group) were discussed.  An effort was made to
understand the purpose, merits, and ramifications of each feature.

The three highest priority features were (not in any order):


   o Network layer host/matrix tables
   o Per-segment protocol distribution
   o Packet filtering enhancements


Framework highlights:


   o No changes will be made to the RMON MIBs (RFC 1271 and RFC 1513)
     that would break existing NMS applications.

   o New tables will be added to new groups, not to existing groups in
     RFC 1271.  (Possibly create new MIB-MODULE?)

   o The capture and filter tables may be deprecated as a result of new
     work on the filters.

   o New objects may be added to existing tables as enhancements

   o The rules defining the acceptable use of the dataSource object will
     be changed to allow other OIDs than `ifIndex.N'

   o EntryStatus will be kept for all existing tables.  New tables will
     use the RowStatus textual convention.

   o The deadline for new problem or feature proposals is January 1,
     1995


The agenda posted to the mailing list was observed, with the following
exception:  instead of making three passes through the work-item list, a
single pass was made in which discussion on each feature was unlimited.

The interest level described for each feature reflects the opinions of
the meeting attendees and the perceived interest seen on the mailing
list, but it shall be considered the working consensus of the group
unless otherwise altered by consensus gathered via e-mail or at the San
Jose meetings.


Detailed Summary

The following areas were covered:


   A) New Monitoring Features
   B) Packet Filtering
   C) Enhancements
   D) Bug Fixes
   E) SNMPv2 Alignment
   F) Probe Configuration
   G) Hardware Considerations


A) New Monitoring Features

A1) Statistical analysis (sampled packet capture w/hardware counters)
	[ Sonia Panchen/Hewlett-Packard (presentation/no MIB) ]
    Summary:
	Sample stream of stats via a post filter (Hewlett-Packard EASE) 
           Controlled
	Sample Rate. Count based sample--not time-based.
    Interest:
	Strong consensus to add this feature--it was observed that this
	addition could be useful for hardware considerations (item G1).
    Probable Implementation:
	The dataSource objects in existing control tables could be 
	`pointed to' an ``statControlEntry'' that would indicate the
	ifIndex to monitor and the packet skip count.
	An additional mode could be provided via filter enhancements
	to allow channels to capture sampled packets (see ruled-based 
        filters).  This would allow NMS-based applications to utilize 
        the raw sampled packet slices.

A2) Duplicate address detection
	[ no work done ]
    Summary:
	Detection of duplicate network layer addresses for the same MAC
	address. It was noted that `false' duplicates would exist
	under some normal network conditions. If this was added, 
	it would be limited to a `best effort' by the probe.
    Interest:
	Moderate consensus to support this. It is hoped that a table
	which provided MAC-NET address bindings would be enough to allow
	an NMS app to derive this feature.
    Probable Implementation:
	A table that contained MAC-NET bindings (per interface)

A3) Address change detection 
	[ MAC changes provided in Repeater MIB, so is this any net addr
         or IP only -- no work done ]
    Summary:
	Detection of MAC-NET address changes. It was determined that
	this feature is really part of item (A2).
    Interest:
	Moderate consensus to support this. This was seen as part of 
	feature A2.
    Probable Implementation:
	A table that contained MAC-IP bindings (per interface)

A4) Network layer HostTable
	[ Venkat Rangan/Hewlett-Packard (presentation, MIB provided) ]
	[ AXON ECAM MIB ]
    Summary:
	This is viewed as a very key feature of RMON-2. The feature
	is assumed to include a matrix table as well. A balance must
	be found between hard-wired protocol tables and generic tables.
	Implementation proposals from Hewlett-Packard, AXON, TU Delft, and 
	Tech. Elite were discussed. 

	The challenge is to provide enough extensibility and flexibility
	to support most protocols (layer 3 and above)--without future
	MIB changes--and still maintain high inter-operability and 
	low complexity.
    Interest:
	Strong consensus to add. 
    Probable Implementation:
	The group seemed to favor a model that used protocol-specific soft 
	counters (e.g. ECAM MIB). A universal directory of protocol
	IDs would be needed, as well as a table of protocol IDs
	supported by the probe.
	No consensus was reached on the best way to define the soft
	counters for a given protocol, or the protocols to be
	supported. (This will be a major topic at the San Jose meeting)

A5) Protocol-type distribution through all 7 layers of the ISO model
	[ In/Out/Errors or more? Per Host? Per Conversation?
	  no MIB ]
    Summary:
	Provide protocol distribution statistics (octets, pkts, errors?)
	for the protocols seen on a given interface.
    Interest:
	Strong consensus to add. No consensus to provide per-host or
	per-conversation protocol distribution because of the possible
	data table explosion that could occur at this level of
	granularity.
    Probable Implementation:
	No consensus on an implementation

A6) Consider how RMON could benefit network security for example:
    Using the RMON History  to provide an accountability and audit
    trail through the Transport Layer.  
        [ presentation on auditing was done in Toronto -- no MIB ]
    Summary:
	Monitor Connections in the Network.  Open and Close of connections.
	Add a table to just provide the stats.
	Connections to/from a resource on the network.
    Interest:
	Consensus to delete -- feature dropped. Seen to be to expensive to
	implement on an RMON probe. Hopefully, data from item A4 can
	be used to help in this area.
    Probable Implementation:
	N/A

A7) More performance metrics in RMON to meet the needs of the 
    client-server environment. 
        [ no examples, no MIB ]
    Summary:
	Monitor transaction response times
    Interest:
	Consensus to delete -- feature dropped. Seen to be to expensive to
	implement on an RMON probe.
    Probable Implementation:
	N/A

A8) Proposal for host and matrix protocol distribution
	[ Richard Kooijman (examples, MIB) ]
	[ AXON ECAM MIB ]
    Summary:
	Per host and per-conversation protocol distribution
	Related to the tables in items A4 and A5
    Interest:
	Consensus to delete -- feature dropped. Seen to be to expensive to
	implement on an RMON probe. Concern over data explosion.
    Probable Implementation:
	N/A

A9) Packet generation
	[ Karl Auerbach/Timon Sloane, others (examples, MIBs) ]
	[ - range of ideas: ping MIB...send raw MAC frame including CRC ]
    Summary:
	Allow a mgmt app to specify a raw packet for transmission
	by the probe on a specified interface. An alternative would be
	to allow the NMS app to specify portions of the packet, or to
	retransmit packets from a capture buffer.
    Interest:
	No consensus to add--group very divided on this issue. Proponents
	want the ability to support any protocol, or any protocol
	without impact on the probe. Opponents are concerned about
	possible misconfiguration, intentional misuse, and security
	implications. If the real intent of this feature is to 
	initiate transactions, then there would be a mechanism needed
	to capture, recognize, and report the results. 
	The group has decided to drop this feature but will allow further 
	discussion at the San Jose IETF	to possibly reverse this decision.
    Probable Implementation:
	N/A (Timon Sloane's packet generation MIB if revived)

A10) Connectivity Tests 
    Summary:
	Generate `ping' tests to determine addresses and capture the results 
	Such `Ping MIBs' have already been posted on different occasions.
	(Steve will provide a EchoTest MIB example to the working group.)
	Packet generation would be controlled by the probe. A mechanism
	to trigger generation with events is desired.
    Interest:
	Strong consensus to add, but some concern that this really 
	does not belong in RMON, but it is unlikely to be present in any
	other standard MIB. 
    Probable Implementation:
	TBD -- want to consider fielded implementations before 
	writing a new ping MIB.

A11) User-defined history collection
	[ Robin Iddon, no MIB ]
	[ combine historyControlTable and alarmTable functionality 
	  use historyControlTable plus bucketControlTable?
	  variable-length buckets or fixed number of objects?
	  want to fix alarmValue encoding problems and sample
	  discontinuity problems? ]
    Summary:
	allow an NMS app to specify objects to be collected in
	history buckets. 
    Interest:
	Strong consensus to add
    Probable Implementation:
	Combination of historyControlTable and alarmControlTable
	into a new control table, and a single data table.

A12) Capacity Planning--long term monitoring
	[ no consensus, no MIB ]
    Summary
	probe would provide long-term (i.e., weeks, months) polling
	of specified variables such as net utilization.
    Interest:
	Strong consensus to drop -- feature could be provided by a user
	history table (A11) -- feature dropped
    Probable implementation:
	N/A

B) Packet Filtering

The question was posed if packet filter was really `broken' and the
consensus was that it is sufficient for MAC layer monitoring, but
is difficult (or impossible) to configure higher-layer filters.
The current filter/channel mechanism is not considered 
`hardware-friendly,' requiring a software implementation.

B1) Filtering beyond variable-length fields in the packet
	[ Karl Auerbach/Timon Sloane -- filter stack 
	 (MIB proposal from Richard Kooijman, filter spec from Karl) ]
    Summary:
	Rule-based filter mechanism would allow the filters to
	be more sophisticated, which should result in less filters needed
	to capture a given packet, and allow filters to be 
	`protocol-aware.'

	Make MIB structure flexible to keep performance in check.
    Interest:
	Strong consensus to add some form of non-proprietary rule-based 
	filtering.
    Probable Implementation:
        Consensus to investigate possible use of the Berkeley 
	packet filter engine.

B2) Change filter mechanism to allow for efficient hardware implementation
	[ no examples, no MIB ]
    Summary
        The current filter/channel mechanism is very difficult
	to implement on high speed networks (100 MBit+). Some sort
	of `stream-lined' filter should be defined to make
	make implementation more likely.
    Interest:
        Strong interest in supporting high-speed networks
	but no consensus on what can be done. Some interest
	in allowing filters to be shared more easily.
    Probable Implementation:
        An `extended-error' eventType with standardized log entries in 
	the logTable (see item C2). 
	No consensus on any mechanism to indicate the limits of
	`hardware-able' filters with MIB objects.
    
B3) Pattern matching on sub-string anywhere in pkt (pkt-grep) 
	[ no MIB ]
    Summary
        Provide a mechanism to recognize a pattern anywhere in
	a packet.
    Interest:
        Strong interest to drop this feature because it is
	too expensive to implement--even on 10 MBit networks
	--feature dropped
    Probable Implementation:
        N/A

B4) New table allowing filters to be shared by different channels
	[ Richard Kooijman (examples, MIB) ]
    Summary:
        Agent implementations can be more efficient if filters
	could be shared by different channels.
	Need to include all operators (AND/OR) and filter exit.
	Problem of sharing ControlTable Entries.
	Could register access to ControlTable with renewal from client.
    Interest:
	Low consensus to fix this in the MIB, but the issue is not
	closed if new ideas emerge. There was some desire to create 
	a `glue-table' that would control the `many-to-many'
	filter/channel logic needed to share filters with MIB
	objects.
    Probable Implementation:
        None proposed

B5) Intermediate data table for Karl's filter-stack
	[ Karl Auerbach, alternate MIB by Richard Kooijman (MIB) ]
    Summary:
        Mechanism to make `intermediate-data' gathered while decoding
	packets available to management applications. This includes
	`interesting' offsets, checksums, etc. within the various
	headers in the packet.
    Interest:
        Strong consensus to delete because it would be too difficult
	to define the data semantics and not of enough use to 
	management applications--feature dropped
    Probable Implementation:
        N/A

B6) Operator-Based Filtering
	[ Richard Kooijman  (examples, MIB) ]
    Summary:
	Channel logic is limited to the implied OR-ing
	of all filters associated with the channel. A
	mechanism to allow other logical operators
	(AND, XOR?) to combine filter results could
	be provided.
    Interest:
        Low interest in implementing this feature with parse-able
	text strings. It is hoped that new filtering
	changes will be flexible enough to handle this
	level of filter logic, without implementing it
	in the channel logic--feature dropped
    Probable Implementation:
        N/A

B7) Filter Enhancements for WAN monitoring
	[ Jonathan White (example, MIB) ]
    Summary:
        (This item should really be in section C.)
	Add new status bits to the filterStatus object
	to indicate the direction of the packet on a
	WAN interface. Also desired general purpose
	(non-media specific) error bit definitions.
    Interest:
        Strong consensus to add a bit for WAN-packet
	direction. NMS applications need to check 
	the monitored interface type (with ifType)
	to determine if this bit is relevant.
	There was some interest in defining some
	general error condition bits.
    Probable Implementation:
        Add a `WAN packet direction' bit to the
	filterStatus object semantics.

C) Enhancements

C1) Packet distribution in the history data tables
	[ from charter, no MIB]
	[ assumed proposal: add etherHistoryXXtoXXPkts to
	  etherHistoryTable ]
    Summary:
        There is no packet-size distribution in the
	etherHistoryTable, but there is in the token
	ring history tables.
    Interest:
        Moderate to strong interest in adding this feature. 
    Probable Implementation:
        Add the etherStatXXtoXXPkts objects to the etherHistoryTable

C2) Standardize log table entries
	[ trap MIB had trap decode format specified ] 
    Summary:
        The standard event trap types (risingEvent, fallingEvent)
	have no standard log entry definition.
    Interest:
        Strong interest in providing a standard encoding for the
	risingEvent and fallingEvent trap types that includes
	an ASCII version of the trap.
	There was little interest in reviving the packetMatch
	trap for this use.
    Probable Implementation:
        Compressed format of trap-encoding formats as specified
	in trap log MIBs previously posted to the mailing list.

C3) Resolution of captureBufferPacketTime timestamp (mSec) 
	[ scaling factor to get microSec resolution? ]
    Summary:
        The timestamp resolution of the captureBufferPacketTime
	object is in milli-seconds, which inhibits inter-packet
	timing information. 10 or 100 micro-second resolution
	would be more useful.
    Interest:
        Moderate interest to consider finer granularity in
	this object. There was some concern over the semantics
	of this object--whether it was time-stamped as soon as 
	possible after reception (by hardware?) or when the packet
	was added to the capture buffer (consensus was ASAP
	after reception).

        No consensus to change the semantics of this object
	because the added utility was not worth the risk
	of breaking applications currently using this
	object. No consensus to add a new object
	--feature dropped
    Probable Implementation:
        N/A

C4) Timestamp in MatrixControlTable of last status change 
	[ some examples, no MIB ]
    Summary:
        An NMS application has no reliable way of knowing
        when data collection was started in certain RMON tables,
	A timestamp would make the following situations less
	of a problem:
	  * multi-manager access to a single control table
	  * interface change in agent causing data to be flushed
    Interest:
        Moderate consensus to support in the host and matrix groups.
        No interest in providing a time-of-day ASCII string.
    Probable Implementation:
        Add a sysUpTime-based timestamp object to the host and matrix 
	control tables, indicating the time that data collection
	was started (or restarted).

C5) Client/Server Trend Analysis 
	[ Nevil Brownlee accounting MIB (presentation, no MIB) ]
    Summary:
        Implement the Accounting `Meter MIB' 
	(draft-brownlee-acct-meter-mib-01.txt) within RMON.
    Interest:
        Some interest in the MIB, but not as a part of RMON. 
	Consensus to follow activity of the Accounting group and
	leave this alone for the time--feature dropped
    Probable Implementation:
        N/A

C6) Host to Physical Port Mapping
	[ Dan Romascanu/Lannet, Shay Naeh/ARMON (presentation, MIB) 
    Summary:
        Addition to the hostTable to provide the physical port
	from which a packet was received. This feature is very
	specific to repeaters and bridges, but can provide
	some required data for topology discovery (PHYS-MAC 
	bindings). 

        There was considerable discussion on this issue. Some address 
	tracking is provided in the Repeater MIB (RFC 1516), but
	the proposed mechanism provides the last port ID for each SA,
	instead of the last SA seen on each port. There was some
	concern that a different MIB should address topology discovery
	issues instead of using bits and pieces from various sources
	(current practice).

	(From discussion on RMON for switched VLANs:
	Switches - consider a 32 port switch.  Need to look at a 
	single view of all these 32 Collision Domains.  How should RMON 
	look at this implementation.  If there is a single backplane which 
	all the 32 ports move traffic onto, we must be able to view 
	this information and provide monitoring data. 
	Could use an `entity MIB' to identify placeholder objects
	such as real or virtual backplanes, then point dataSource at 
	this OID--or the dataSource for this could come from the 
	connection MIB (if ever completed) to link RMON control tables.)
    Interest:
	Moderate consensus to add. No consensus on a key implementation
	issue: number of identifier components for the physical port.
	(proposed # is 2, some want up to 4)
    Probable Implementation:
        Will be based on the proposed MIB fragment from Lannet and ARMON

C7) EtherStats modifications for traffic characteristics
    including NetUtilization added to EtherStats 
        [ Richard Kooijman (MIB) ]
    Summary:
        proposed MIB included timing characteristics added to the
	ethernet statistics group, and a network utilization object.
	A static netUtilization object would allow thresholds
	to be based on bandwidth utilization.
    Interest:
        Low interest in the timing aspect, but strong consensus to add
	2 or 3 netUtilization objects to the etherStatsTable.
	Need consensus on the intervals: 1 sec, 5 sec, 1 min, 5 min
    Probable Implementation:
        Objects added to the etherStatsTable with similar semantics
	as the etherHistoryNetUtilization object--except the
	interval is specified.

C8) Acceptable DataSource values
        [ Richard Kooijman (Beholder2) ]
    Summary:
        The dataSource OID pointer is currently restricted to
	a value of `ifIndex.N', where N represents a physical
	interface (ethernet or token ring). Proposal to
	allow other entities to be used as data sources, such as:
	* repeater ports (rptrPortGroupIndex.GROUP.PORT)
	  The repeater instance is determined by checking
	  the dataSource
	* channel ID (channelIndex.INDEX)
    Interest:
        Strong interest to expand the dataSource capabilities and
	to identify the rules for expansion in order to maintain
	inter-operability.
	There was strong consensus that SNMPv1 did not provide
	enough error codes to help an NMS `debug' resource-related
	problems. 
	Open Issues:
	* How does NMS know the configuration capability of the device?
	* How does NMS know the resource impact of a specific 
          configuration?

    Probable Implementation:
        for table redirection:
        * channelIndex.INDEX will be allowed, others are TBD
	for resource management issues:
	* new MIB objects: 2 gauges indicating percentage of current
	  memory and CPU usage
	* Use the Event/Log mechanism for detailed errors on RMON agent 
	  genError and badValue.

D) Bug Fixes

D1) Align EtherStatsJabbers with IEEE/Repeater MIB definition
    Summary:
        The RMON definition of a jabber condition is incorrect.
	IEEE Jabber is any frame greater than 20ms - 115ms.
	RMON Jabber is frame longer than 1518 with bad FCS.

	To fix this, etherStatsJabbers could be left alone
	or deprecated, and an additional object would provide
	a jabber condition counter consistent with the Repeater
	MIB definition (rptrMonitorPortVeryLongEvents)
    Interest:
        No interest in changing because the gain would not be
        worth the effort. NMS applications should use the
        repeater MIB jabber counter for accuracy--feature dropped
    Probable Implementation:
        N/A
    
D2) Separate ethernet-specific tables from `generic-RMON'
    Summary:
        RFC 1271 contains media-specific (etherStats, etherHistory)
	features among the mostly generic control tables. (filterPktStatus
	excluded). Proposal to split the ethernet-specific portions
	into a different document.
    Interest:
        No consensus that this is even a bug, bug strong consensus
	that it is not worth fixing in any case--feature dropped.
    Probable Implementation:
        N/A

D3) EtherStatsCollisions inaccurate -- cannot be counted properly with 
      hardware.
    Summary:
        Collision counter definition not really an accurate account
	of the collisions on a backplane.
    Interest:
        Moderate consensus that this is a problem.
        Strong consensus that it is not worth fixing--feature dropped.
    Probable Implementation:
        N/A

E) SNMPv2 Alignment 

E1) RowStatus versus EntryStatus
	[ from charter, consensus to add ]
    Summary:
        The RowStatus textual convention for managing conceptual
	row creation, modification, and deletion is preferred
	over the RMON-specific EntryStatus. Proposal is to
	use RowStatus instead.
    Interest:
        Strong interest in using RowStatus for new tables.
    Probable Implementation:
        The RowStatus TC will be used for new tables.
	The objects already defined with the EntryStatus TC
	will be unchanged.
	
E2) Support for SNMPv2 macros 
	[ which ones? -- is this the same as E4 ]
    Summary:
        The RMON MIB uses the `old' SMI macros. Proposal to
	update the MIB with the appropriate macros from the 
	SNMPv2 SMI.
    Interest:
        Mandatory for new MIB objects, but moderate consensus not
	to update RFC 1271 and RFC 1513.
    Probable Implementation:
        New MIB modules (not part of 1271 or 1513) will be
	defined with the SNMPv2 SMI macros.

E3) Alarms/Events from M2M MIB
	[ from charter, consensus to add ]
    Summary:
        The Manager To Manager MIB (RFC 1451) provides a more robust
	implementation of alarms and events (but no logging) as
	defined in the RMON MIB. Proposal to deprecate the existing
	alarms and events groups and use the M2M MIB instead.
    Interest:
        Since the M2M MIB relies on SNMPv2, it cannot replace
	alarms and events in existing applications. Strong
	consensus not to deprecate the current solution.
	Some consensus to add text advising the use of the M2M MIB
	in SNMPv2 environments--feature dropped
    Probable Implementation:
        N/A

E4) Align with SNMPv2 SMI
	[ from charter, consensus to add ]
	[ DUPLICATE OF E2 -- REMOVED ]
    

F) Probe Configuration

F1) RMON Probe Configuration including modem configuration
	[ AXON/Hewlett-Packard (MIB) -- for consideration as a 
          separate document from the RMON-2 spec ]
    Summary:
        Many RMON probes have proprietary configuration MIBs
	to configure agent behavior. Proposal to create
	separate document or group within RMON MIB to 
	help standardize agent configuration.
    Interest:
        * Strong interest in adding a trap destination table to RMON
	* No consensus to provide acknowledged traps or modem configuration.
	* Consensus not to overlap existing functionality in other
	  standard MIBs.
    Probable Implementation:
        Determine interest from the NM area AD in:
	* creating a new working group to handle agent configuration, 
	  including out-of-band configuration
	* modifying the RS-232 MIB (RFC 1317), MIB-II (RFC 1213), 
	  and the Modem MIB (RFC # ??) to support agent configuration
        As a last resort, some probe configuration features will
	be developed by the RMONMIB Working Group, derived from the 
        Hewlett-Packard/AXON MIB.

F2) Probe Resource Capacity Table
    Summary:
        Many probes can be user-configured to allocate memory resources
	to specific tables. A table indicating the ``memory ration''
	for each table (specified in KBytes or number of entries) 
	and memory usage could help NMS apps better utilize RMON
	probe resources. Only the probe may create or delete entries
	and write access to the ration amount is optional. An additional
	gauge indicating total remaining RMON resources may also be useful.
	(Also CPU Usage gauge).
    Interest:
        No consensus that this could be effectively implemented--even
	as a read-only table--because of the different ways that
	RMON resources are managed in various applications
	--feature dropped
    Probable Implementation:
        N/A

F3) Probe Reset Issues
    Summary:
        After a probe resets, all the NMS-configured control 
	entries disappear, and must be re-configured by the NMS.
	There is no standard way to configure non-volatile
	storage usage of these tables.
    Interest:
        * Concern over limited NV-storage on a probe--
	  probe would have to prioritize which control entries
	  to save or limit control entries to what could fit
	  in NV-storage.
	* NMS may not want all entries restored after a reset.
	Moderate interest in adding a storage status object
	to each control row, (e.g. xxObject from the Party MIB?)
	There was concern over stale entries in the tables,
	left behind by sloppy or crashed NMS apps. 
    Probable Implementation:
    * storage status object added to each control row:
	- other(1)
	- volatile(2)		-- RAM
	- non-volatile(3)	-- NVRAM
	- permanent(4)		-- ROM
    * DEFVAL would be volatile(2).
    * Deleting a row via the Entry/Row-Status object deletes
      from all storage areas.

G) Hardware Considerations

G1) A concern on the extrapolation of dropped events as the speed of
    networks increase, i.e., 100BaseT
        [ what can the working group do about this? ]
    Summary:
        The RMON MIB is difficult to implement on high-speed networks.
	The working group needs to explore ways to make high-speed RMON
	implementation more cost-effective.
	There was concern whether RMON should try to provide 
	logic-analyzer quality exception handling on high-speed
	networks (zero or few droppedEvents). 
	Some items that may help:
	1) statistical sampling to pre-filter data (this is not
	   useful for exception handling)
	2) stream-line packet filter specifications (see item B2)
	3) remove packet size distribution counters from the
	   etherStats group (i.e., keep the counter set limited
	   to what common hardware can count)
    Interest:
        Moderate consensus that this is really a problem--line-speed
	monitoring (e.g. LA-quality) is not mandatory because networks
	rarely run at full utilization. New probe technology will keep up
	with increasing line-speeds (specifically 100 MB)
	Moderate Interest in suggestions 1 and 2 above.
	Strong consensus that high-speed and switched environments
	have to be supported.

G2) Concern for distributed RMON
    Summary:
        RMON is difficult to implement in some `non-standard'
	environments, such as:
	* multiple sub-agents
	* multiple processors
	The RMON resources are usually interface-related, 
	determined by the dataSource object--need to know 
	the dataSource to pick correct sub-agent. 
	Some suggestions to help solve this problem:
        * possibly add text to enforce dataSource to be set ASAP 
	* possible DEFVAL for dataSource of ifIndex.1
	* RowStatus==createAndGo, dataSource in first PDU ]
    Interest:
        There was no consensus that this was really a problem.
	There was no interest in changing any row creation semantics.
	--feature dropped
    Probable Implementation:
        N/A


Summary of Proposed Changes/Additions to Existing Tables

   o Statistics:  add network utilization objects to etherStatsTable (C7)

   o History:  add packet-size distribution counters to
     etherHistoryTable (C1)

   o Host:  add physical-port indication to hostTable (C6) add
     data-collection timestamp to hostControlTable (C4)

   o Matrix:  add data-collection timestamp to matrixControlTable (C4)

   o Filter/capture:  possibly add channelDescription object to hold
     NMS-supplied text string -- the filter group may be deprecated as a
     result of new work.

     Add a bit to the filterPktStatus to indicate WAN packet direction. (B7)

   o Event:  define standard logEntry formats for risingEvent and
     fallingEvent trap-types. (C2)