OPS Area
RMONMIB WG Meeting Minutes
43rd IETF 
Orlando, FL USA
December 7, 1998
Minutes by Andy Bierman

Review Material
---------------

(A)  draft-ietf-rmonmib-rmonprot-v2-03.txt
(A1) draft-ietf-rmonmib-rmonprot-ref-00.txt
(A2) draft-ietf-rmonmib-rmonprot-mac-00.txt
(B)  draft-ietf-rmonmib-smon-04.txt
(C)  draft-ietf-rmonmib-hcrmon-03.txt
(D)  draft-warth-rmon2-artmib-00.txt
(E)  draft-bierman-dsmon-mib-00.txt

Agenda
------

1) Discuss any WG Last Call open issues with I-Ds (A) - (C).

2) Discuss any implementation experience comments for
   RFC 1513 and RFC 1757. 

3) Discuss proposal for new WG charter.

4) Short presentations of feature proposal I-Ds.
   - 10 minutes for I-D (D)
   - 10 minutes for I-D (E)

5) Short presentations of new charter feature proposals.
   - limited to 10 minutes each
   - contact the Chair to reserve 1 of N limited timeslots
    
6) Discuss functional requirements for most popular of the
   new feature proposals.

Minutes
-------

1) Comments on all Current Work Item I-Ds

Several documents have been through a last review cycle.
Open issues were discussed, one document at a time.

1.1) SMON MIB

Some minor issues with I-D (B) were discussed and resolved 
at the meeting:

 - smonDataSource: VLAN ID restrictions are mentioned in
   introductory text; this text will be added to the TC 
   definition itself.

 - smonCapabilities: The BIT numbering is not dense, i.e.,
   BIT 3 is skipped.  The WG decided not to change this
   object at this late date. BIT 3 will remain unused.

 - smonVlanStatsId sub-range: The VLAN-ID sub-range
   needs to be clarified to be consistent with the
   latest Bridge MIB (draft-ietf-bridge-bridgemib-03.txt).
   The local VLAN-IDs (above 4095) are not properly supported.

 - smonMIBCompliances numbering collision:  The Object Identifier
   assignments { rmonConformance 3 } and { rmonConformance 4 }
   were both used by the HC-RMON MIB (C) and the SMON MIB.
   The HC-RMON MIB will renumber to fix the problem.
   
The updated document has already been published as
<draft-ietf-rmonmib-smon-05.txt> and a WG Last Call
has been started for this document.  It will soon be
forwarded to the Area Director for publication as
a Proposed Standard RFC.

1.2) RMON Protocol Identifier documents 

There were no comments on I-Ds (A1) and (A2). I-D (A) is
now obsolete. These drafts (A1 and A2) have been forwarded 
to the Area Director for publication.

The PI Reference document (A1) is intended to remain on the
standards track at Proposed Draft status, and the PI Macros 
document will be removed from the standards track and
published as an Informational RFC.

1.3) HC-RMON MIB

There were no comments on this I-D (C), other than the
OID numbering collision with the SMON MIB.

The HC-RMON MIB will be republished with correct OID
assignments.  This minor modification does not warrant
a WG Last Call review period, so the new documented
will be forwarded directly to the Area Director for
publication as a Proposed Standard RFC.

2) RFC 1513 and RFC 1757 Implementation Experience 

The WG Chair is compiling an implementation report to
support standards advancement of the Token Ring RMON MIB
and (Ethernet) RMON MIB. Several vendors have responded
and it appears all objects in both MIBs have been
implemented (in an interoperable way) by several vendors.

Both documents will be reissued in SMIv2 format.
No other changes will be made, with the exception
of minor clarifications of known problems.

The updated documents will go through a 2 week WG Last Call
when they are published. After any and all issues are resolved,
the documents and the Implementation Reports will be forwarded 
to the Area Directors for publication.  The RFC 1513 update I-D 
should be published as a Draft Standard RFC and the RFC 1757
update I-D should be published as a (Full) Internet Standard RFC.

3) Discussion of new WG Charter Proposal

The WG has been surveying members for new feature proposals
for several months, and at the last IETF meeting, an outline
of a charter proposal was drafted. The WG Chair presented
an expanded version of that outline, and other new WG
items were discussed as well.

3.1) Network Service Level Monitoring

The WG discussed this feature in some detail, and Russell
Dietz presented some measurement issues and some suggested
solution approaches. This feature is very popular among
several vendors of RMON and RMON-like products, and
there is strong demand for an RMON-2 based standard
in this area.

3.2) Persistent Label to Address Mapping

The WG discussed the need for a mapping function between
persistent labels (e.g., user login names) and addresses
(usually network addresses). This is especially needed
in DHCP environments, because the IP address assignments
are dynamic. 

3.3) Differentiated Services Statistics Collection

The WG discussed a feature proposal (I-D (E)) to support
RMON-2 like statistics, with an additional index
component for the Differentiated Services Code Point (DSCP)
value. 

3.4) Protocol Directory Optimizations

The WG discussed the need for a quick lookup mechanism
for ProtocolDirTable entries, indexed only by the 
protocolDirLocalIndex value. The WG also discussed the
need for application wildcarding in the protocolDirTable,
to reduce the size of the protocol directory, and reduce
polling costs for an NMS application.

3.5) Physical Port TopN Table

The WG discussed the need for a simple TopN mechanism
for an entire dataSource. This is especially useful
for an RMON agent with many possible dataSources (e.g., an 
embedded switch environment).

3.6) Frame Relay RMON (* not discussed at WG meeting *)

A late feature was discussed on the mailing list
just after the RMONMIB WG meeting in Orlando, regarding
RMON support for Frame Relay interfaces.

There is a demonstrated need to identify a standard
approach to DLCI-to-dataSource mappings, as well as
the specification of a standard set of RMON features
which should (or may) be supported on Frame Relay 
interfaces.

There were three emails to the list in strong support
of this feature, and no emails opposed to this feature.

3.7) Proposed Schedule for New Work

A proposed schedule was presented by the WG Chair:

1/99: Activation of WG, call for suggested MIB modules.

3/99: Reach agreement on the functional scope of the charter,
      and the number and nature of all document deliverables.

6/99: Submit initial Internet Drafts for all document
      deliverables.

9/99: Begin WG Last Call for all drafts in progress.

11/99: Complete WG Last Call for all drafts in progress.

12/99: Submit Internet Drafts to IESG for standards
       track action.

3.8) Summary

The WG charter text was discussed, and some minor changes
were made at the meeting. The updated version will include
all work items in this section.  It is expected that all
current work (i.e., RMON PI Reference, SMON MIB, HC-RMON MIB,
Interoperability Reports, and SMIv2 updates) will be 
forwarded to the Area Director before this new work begins.
The updated charter proposal will be released soon, but only
to allow the IESG time to review it. It is hoped that
this new work can begin in February.

4) Feature Proposal Presentations

4.1) ART MIB

This presentation was made at the 'New SNMP Work' BOF
instead of this meeting. There was no discussion of I-D (D).

4.2) DS-MON MIB I-D

The WG Chair presented a solution proposal for the
new DIFFSERV statistics work item (I-D (E)). 
There was some interest in pursuing this design further.  
The WG will discuss this I-D on the mailing list after the
new charter is finalized.

5) Feature Presentation Proposals

Russell Dietz of Technically Elite presented a MIB for
monitoring service level metrics such as response time 
and availability.  This MIB will be presented to the
WG as an I-D in the near future.  [Ed. - detailed
notes of this presentation were not received by
the publication deadline.]

There was a great deal of interest in this type of
approach, especially the notion that response time
is not the only metric which must be measured.
The WG also feels strongly that the RMON-2 type of
protocol, host, and host-address-pair classification 
is essential to provide a powerful service level 
monitoring function. The RMON-2 protocolDirectory
can be used to identify protocols associated with
network services, and some existing RMON-2 groups
can be extended to support this new feature.

The WG will discuss this feature in depth on the 
mailing list.

6) Functional Requirements of Popular Feature Proposals

There was no time left at the end of the meeting for
this agenda item, but there was a great deal of Q&A 
discussion during each presentation.  Functional
requirements of all features will be discussed on the
mailing list, if and when the new charter is approved
by the IESG.