Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/rmonmib/rmonmib-minutes-94nov.txt

Text File | 1995-02-28 | 30KB | 791 lines

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)