Subject: DRAFT charter for proposed RTFM2 WG

From: Nevil Brownlee <[email-masked]>
Date: Tue, 30 Jan 2001 15:38:04 +1300 (New Zealand Daylight Time)

Hello all:

Back in December we held a well-attended BOF session at the San Diego 
IETF meeting.  Consensus of the meeting was that not only were there 
worthwhile things for a new Working Group to do, but there were people 
at the meeting who were preapred to do the work.

The BOF minutes (on the RTFM home page at 
www.auckland.ac.nz/net/Internet/rtfm) record our consensus that 
we should work on a draft charter on the RTFM email list.

I've been waiting for some guidance on a proposed charter from our Area 
Directors, but I see that scheduling is open now for the next IETF 
meeting in Minneapolis next March.  If we want a session there, we need 
to get moving.  To kick off discussion, I've attached a draft WG 
charter below.  Would you please read it, and:

 a) If you think the draft charter is badly worded, doesn't say
    the right things, or leaves out things which you think are
    important, send your comments to the list.

 b) If you (and/or your company) would be prepared to work on documents,
    please, please send a note saying which ones either to the list,
    or directly to me.

If a new WG is to be chartered, we need to demonstrate strong support
for it, and well-defined goals.  Tell us what you think!
 
Cheers, Nevil

+---------------------------------------------------------------------+
| Nevil Brownlee                     Director, Technology Development |
| Phone: +64 9 373 7599 x8941        ITSS, The University of Auckland |
|   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand |
+---------------------------------------------------------------------P

       Charter for a Proposed RTFM2 Working Group

           **** DRAFT **** Fri 15 Dec 00 ****

In October 1999 RFCs 2720-2724 were published, specifying the RTFM
Traffic Measurement Architecture.  Since then many sites have been
using the NeTraMet implementation for production traffic data
collection, and others have used it as the basis of further
developments in the field of network traffic measurement.  From
this development work a need has arisen to extend the RTFM
Architecture.

Furthermore, over the last few years interest in flow measurement
has steadily increased, and many commercial products for this are
now available.  Experience in this field indicates that although
the current RTFM architecture provides a very general definition
of flows and an effective method of collecting flow data, there is
a clear need for new, standard approaches to this problem. 

As well as extending the original RTFM architecture, the Working
Group will develop new approaches to traffic flow measurement,
as follows ..

Goals:

 1 Develop a standard for describing traffic flows, and for
   reporting them from a meter to a flow flow data collection
   system.  Such a standard would meet a clearly-expressed
   need for many system vendors.

 2 Define a distributed metering architecture to support metrics
   defined within the IPPM framework, e.g. one-way delay,
   connectivity, one-way loss rate.  This architecture will
   include remote packet capture, and will addres privacy
   concerns such as the inadvertant disclosure of user
   information and the need to authenticate and authorise
   access to captured data. 

 3.1 Develop a high-level interface to the current RTFM system,
   so as to make RTFM capabilities easily and directly accessible
   to new application programs.

 3.2 Standardise some of the 'new attributes' described in
   RFC 2724.  Extend the RTFM architecture, e.g. by adding
   'list-valued' attributes to the RTFM meter. 

Milestones:

Documents 
 [questions, comments/suggestion please..
    - what other documents will be needed?
    - what should be in the documents (ideas for a 
        'contents' list for each would be very welcome!)
    - who's volunteering to contribute to them?
    - when could first drafts be ready?
    ]

 * RTFM2 Flow Definition and Reporting Scheme
       Defines a flexible description of flows which all vendors
       can use when configuring meters.  The flow definitions
       should be flexible enough to handle layer 2, 3 and 4/5
       attributes, making them suitable for traffic engineering,
       accounting, and network operations for at least all
       IETF-specified protocols.
       Specifies protocol for reporting flow data from meters.

 * Requirements for Distributed Metering

 * Architecture for Distributed Metering

 * Remote Packet Capture Protocol

 * Distributing Metering Control Protocol

 * High-Level Interface to RTFM

 * Revised RTFM Architecture
 * RTFM Meter MIB Extensions

-------------------------------------------------------------------------------