From owner-rtfm@auckland.ac.nz Wed Jul 19 22:19:49 2000 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29990 for ; Wed, 19 Jul 2000 22:19:47 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id MAA24255; Thu, 20 Jul 2000 12:18:44 +1200 (NZST) Received: from compaq-nb.auckland.ac.nz (n.brownlee-4-211.itss.auckland.ac.nz [130.216.4.211]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id MAA24172 for ; Thu, 20 Jul 2000 12:18:26 +1200 (NZST) From: Nevil Brownlee To: rtfm@auckland.ac.nz Subject: RTFM get-together at Pittsburgh IETF Message-ID: Date: Thu, 20 Jul 2000 13:19:37 +1300 (DST) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.5 Build (43) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello all: We will be holding our now-traditional RTFM get-together during the Pittsburgh IETF. We've normally done this on Wednesday lunchtime; I'll organise a time and meeting place early in IETF week, and will post details to this mailing list (as well as put a notice on the IETF notice board). Agenda items: 1. I have some interesting experience in implementing distributions of data from IP streams which I'd like to share. Also some plots of turnaround time for DNS request packets. 2. Re-activating the RTFM working group. There are two activities for which this could be considered - a) Develop a standard method (protocol, API, whatever) for changing rulests in an RTFM meter 'on the fly,' i.e. while they are running (e.g. to add/delete networks from a list of networks for which flow data is being collected). b) Review the 'New Attributes' RFC (2274) so as to decide which of these turn out to be really useful, and produce an 'RTFM Meter extensions' RFC so as to allow standardised implementation. To reactivate the WG we'd need to run a BOF; the first step towards that is to produce Internet Drafts setting out what needs to be done. We'll need to decide who will work on two I-Ds, one for each of the above goals (and any others we want to pursue). We should aim to get these published as individual I-Ds by the end of September. Then we can ask our ADs for a BOF at the San Diego IETF in December. Does anyone have any other items? If so, please post them to the list. See you in Pittsburgh ! Cheers, Nevil +---------------------------------------------------------------------+ | Nevil Brownlee Director, Technology Development | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | FAX: +64 9 373 7425 Private Bag 92019, Auckland, New Zealand | +---------------------------------------------------------------------C From owner-rtfm@auckland.ac.nz Mon Jul 31 13:08:15 2000 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11102 for ; Mon, 31 Jul 2000 13:08:09 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id DAA25105; Tue, 1 Aug 2000 03:35:58 +1200 (NZST) Received: from compaq-nb.ietf.marconi.com (bluebottle.itss.auckland.ac.nz [130.216.4.28]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id DAA25097 for ; Tue, 1 Aug 2000 03:35:53 +1200 (NZST) From: Nevil Brownlee To: rtfm@auckland.ac.nz Subject: RTFM meeting: S3 Wed lunchtime Message-ID: Date: Tue, 1 Aug 2000 04:38:08 +1300 (DST) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.5 Build (43) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello all: The informal RTFM get-together will be held in South 3 (entrance to the right as you head towards South 4) at lunchtime on Wednesday, starting at 1140. Agenda items: 1. Re-activating the RTFM working group. There are two activities for which this could be considered - a) Develop a standard method (protocol, API, whatever) for changing rulests in an RTFM meter 'on the fly,' i.e. while they are running (e.g. to add/delete networks from a list of networks for which flow data is being collected). b) Review the 'New Attributes' RFC (2274) so as to decide which of these turn out to be really useful, and produce an 'RTFM Meter extensions' RFC so as to allow standardised implementation. To reactivate the WG we'd need to run a BOF; the first step towards that is to produce Internet Drafts setting out what needs to be done. We'll need to decide who will work on two I-Ds, one for each of the above goals (and any others we want to pursue). We should aim to get these published as individual I-Ds by the end of September. Then we can ask our ADs for a BOF at the San Diego IETF in December. 2. A need has arisen for 'list-valued' attributes. These are for things like DSCP and next-hop which are different for each direction of a flow, but each packet only has a value for one direction. The list would contain (attribute value, packet count) pairs. 3. I have some interesting experience in implementing distributions of data from IP streams which I'd like to share. Also some plots of turnaround time for DNS request packets. Does anyone have any other items? If so, please post them to the list. Cheers, Nevil +---------------------------------------------------------------------+ | Nevil Brownlee Director, Technology Development | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | FAX: +64 9 373 7425 Private Bag 92019, Auckland, New Zealand | +---------------------------------------------------------------------C --- End Forwarded Message --- +---------------------------------------------------------------------+ | Nevil Brownlee Director, Technology Development | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | FAX: +64 9 373 7425 Private Bag 92019, Auckland, New Zealand | +---------------------------------------------------------------------C