From majordomo@mil.doit.wisc.edu Tue Mar 1 01:06:04 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23531 for ; Tue, 1 Mar 2005 01:06:03 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D608P-0006Px-00 for ipfix-list@mil.doit.wisc.edu; Mon, 28 Feb 2005 23:41:29 -0600 Received: from fmr20.intel.com ([134.134.136.19] helo=orsfmr005.jf.intel.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D608N-0006Pq-00 for ipfix@net.doit.wisc.edu; Mon, 28 Feb 2005 23:41:28 -0600 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j215fRVT001496 for ; Tue, 1 Mar 2005 05:41:27 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j215euVx026647 for ; Tue, 1 Mar 2005 05:41:26 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005030113412630557 for ; Tue, 01 Mar 2005 13:41:26 +0800 Received: from pdsmsx404.ccr.corp.intel.com ([172.16.12.64]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Mar 2005 13:41:25 +0800 Received: from sgsmsx402.gar.corp.intel.com ([10.241.192.43]) by pdsmsx404.ccr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Mar 2005 13:41:20 +0800 Received: from bgsmsx402.gar.corp.intel.com ([10.224.48.3]) by sgsmsx402.gar.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Mar 2005 13:41:16 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51E21.488914ED" Subject: [ipfix] ipfix Date: Tue, 1 Mar 2005 11:11:15 +0530 Message-ID: <3D8B16F753179D4588D4B0C8FF7EAC45017CEDF5@bgsmsx402.gar.corp.intel.com> Thread-Topic: ipfix thread-index: AcUeIUiqm7cQoCm6Q1iNPS9cTiQ2fQ== From: "Aligave, Heramba" To: X-OriginalArrivalTime: 01 Mar 2005 05:41:16.0816 (UTC) FILETIME=[49A3E900:01C51E21] X-Scanned-By: MIMEDefang 2.44 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------_=_NextPart_001_01C51E21.488914ED Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, I am heramb working with Ethernet group in Intel. I am working on IPFIX hardware implementation in our router. We are thinking of implementing this feature as a single IPFIX device with a single observation point(I.e router), one metering and single exporting. After reading the RFC and the drafts, I had a few doubts about certain points mentioned. Shall appreciate your reply for these. =20 1) Packet Sampling- IPFIX architecture mentions about packet count sampling to be done before Filtering function.=20 Doubt: 1) Is packet sampling to be implemented as a static sampling or=20 we should have random sampling? `2) Is the order of execution important, i.e Sampling first followed by filtering. =20 2) Multiple sampling, filtering: Is it fine to implement just a single filtering and single sampling in the metering process? 3) Export Criteria- We have thought of using Min/Max properties to trigger export as has been mentioned in the information model. 4) Counters -- There is doubt about how to implement MulticastOcetCount and Droppedpacketcount. i) DroppedInOctet Counter: This requires packet received on a flow but dropped due to Packet treatment. Here packet treatment means functions like Ingress filter, L2 check? Similarly, for DroppedOutOctetCounter:What does drop mean in this context? Do they mean drops related to resource crunch(Discards) , Egress filtering? ii)MulticastOctet Count: Kindly elaborate on the definition of this counter. Regards, heramb ------_=_NextPart_001_01C51E21.488914ED Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

 I = am heramb working with Ethernet group in Intel.

I am working on IPFIX hardware implementation in our router.

We are thinking of implementing = this feature as a single IPFIX device with

a single observation point(I.e = router), one metering and single exporting.

After reading the RFC and the = drafts, I had a few doubts about certain points mentioned.

Shall appreciate your reply for = these.

 

1)  Packet = Sampling—

          &= nbsp; IPFIX architecture mentions about packet count sampling to be = done

      =             &= nbsp;           &n= bsp;           &nb= sp;     before Filtering function.

      =             &= nbsp;           &n= bsp;           &nb= sp;     Doubt: 1) Is packet sampling to be implemented as a static sampling or =

      =             &= nbsp;           &n= bsp;           &nb= sp;     we should have random sampling?

      =             &= nbsp;           &n= bsp;           &nb= sp;     `2) Is the order of execution important, i.e Sampling first followed by filtering.

 

      =             &= nbsp;                 2) = Multiple sampling, filtering: Is it fine to implement just a single filtering and = single sampling in the metering process?

      =             &= nbsp;           &n= bsp;     3) Export Criteria- We have thought of using Min/Max properties to = trigger export as has been mentioned in

      =             &= nbsp;           &n= bsp;           &nb= sp;     the information model.

      =             &= nbsp;           &n= bsp;     4) Counters --        There is = doubt about how to implement MulticastOcetCount and = Droppedpacketcount.

      =             &= nbsp;           &n= bsp;           &nb= sp;     i) DroppedInOctet Counter: This requires packet received on a flow but = dropped due to

      =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;     Packet  treatment. Here packet treatment means functions like = Ingress filter, L2 check?

      =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;     Similarly, for DroppedOutOctetCounter:What does drop mean in this = context?

      =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;     Do they mean drops related to resource crunch(Discards) , Egress = filtering?

      =             &= nbsp;           &n= bsp;           &nb= sp;     ii)MulticastOctet Count: Kindly elaborate on the definition of this = counter.

Regards,

heramb

------_=_NextPart_001_01C51E21.488914ED-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Mar 1 08:24:59 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23609 for ; Tue, 1 Mar 2005 08:24:59 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D67H0-0001dD-00 for ipfix-list@mil.doit.wisc.edu; Tue, 01 Mar 2005 07:18:50 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D67Gz-0001d4-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 01 Mar 2005 07:18:49 -0600 Received: from [193.175.133.240] (kaitos [193.175.133.240]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j21DIl524522 for ; Tue, 1 Mar 2005 14:18:47 +0100 (MET) Message-ID: <42246BB6.9090104@fokus.fraunhofer.de> Date: Tue, 01 Mar 2005 14:18:46 +0100 From: Lutz Mark User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] Restarting Interrupted Connections X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > 13.4.1.3 Restarting Interrupted Connections > > ... In the default configuration, a Collecting > Process MUST NOT attempt to establish a connection more frequently > than once per minute. I think this is a typo. It should read: In the default configuration, an Exporting Process MUST NOT attempt to establish a connection more frequently than once per minute. Regards, Lutz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Mar 1 10:49:26 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08220 for ; Tue, 1 Mar 2005 10:49:26 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D69Kq-0002pm-00 for ipfix-list@mil.doit.wisc.edu; Tue, 01 Mar 2005 09:30:56 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D69Ko-0002ph-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 01 Mar 2005 09:30:55 -0600 Received: from [64.103.12.86] (dhcp-64-103-12-86.cisco.com [64.103.12.86]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id j21FUh102907; Tue, 1 Mar 2005 16:30:44 +0100 (CET) Message-ID: <42248AA3.4020108@cisco.com> Date: Tue, 01 Mar 2005 16:30:43 +0100 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lutz Mark CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Restarting Interrupted Connections References: <42246BB6.9090104@fokus.fraunhofer.de> In-Reply-To: <42246BB6.9090104@fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Lutz, Thanks for the review. The typo will be corrected in the next version. Regards, Benoit. > > > 13.4.1.3 Restarting Interrupted Connections > > > > ... In the default configuration, a Collecting > > Process MUST NOT attempt to establish a connection more frequently > > than once per minute. > > I think this is a typo. It should read: > In the default configuration, an Exporting Process > MUST NOT attempt to establish a connection more frequently > than once per minute. > > Regards, > Lutz > > > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Mar 1 15:10:52 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06177 for ; Tue, 1 Mar 2005 15:10:51 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D6Dbl-0006Oz-00 for ipfix-list@mil.doit.wisc.edu; Tue, 01 Mar 2005 14:04:41 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D6Dbk-0006Ok-00 for ipfix@net.doit.wisc.edu; Tue, 01 Mar 2005 14:04:40 -0600 Received: from [129.132.210.109] (vpn-global-dhcp3-109.ethz.ch [129.132.210.109]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j21K4c525154 for ; Tue, 1 Mar 2005 21:04:39 +0100 (MET) Message-ID: <4224CBB1.50506@fokus.fraunhofer.de> Date: Tue, 01 Mar 2005 21:08:17 +0100 From: Elisa Boschi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Subject: [ipfix] new version of IPFIX per packet information X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, we have submitted a new version of our draft: "export of per-packet information using IPFIX". The latest version can be found here: http://www.ietf.org/internet-drafts/draft-pohl-perpktinfo-02.txt It has been improved taking into consideration the comments we have received so far and includes a section addressing the management of the "FlowIDs" we have introduced. Since it describes an extension to the protocol aimed at providing a more efficient way to export packet information (without requiring any modification to IPFIX), we propose to merge our draft with the IPFIX protocol draft. (find our suggestion at the end of this email) We would like to hear the opinion of the group about this. Since the export of per-packet information is a relevant issue for PSAMP, and all IPFIX doocuments are currently in last call, merging the current proposal with a PSAMP protocol draft is, to our opinion, a valide alternative. In both cases the FlowID field should be added in the IPFIX information model (as a numeric identifier for the flow) The IPFIX prootocol draft could be modified as follow: > Table of Contents > > 1. Points of Discussion.........................................4 > 2. Introduction.................................................5 > 3. Terminology..................................................6 > 4. Criteria for Flow Expiration and Export.....................12 > 5. Message Format..............................................13 > 6. IPFIX Message Format........................................15 > 7. Specific Reporting Requirements.............................26 One section could be added here describing the special case of export of packet information (the section could eventually be between 6 and 7 too. > 8. "Export Time" Computation and Flow Record Time..............29 > 9. Linkage with the Information Model..........................31 > 10. Variable Length Information Element........................32 > 11. Template Management........................................33 > 12. The Collecting Process's Side..............................36 > 13. Transport Protocol.........................................38 > 14. Security Considerations....................................47 > 15. IANA Considerations........................................51 > 16. Examples...................................................52 Add here the example in the last section of our draft. > 17. References.................................................58 > 18. Acknowledgments............................................6 Regards, Elisa -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Mar 1 15:51:48 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09821 for ; Tue, 1 Mar 2005 15:51:48 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D6EGV-0003NH-00 for ipfix-list@mil.doit.wisc.edu; Tue, 01 Mar 2005 14:46:47 -0600 Received: from zeppo.itss.auckland.ac.nz ([130.216.190.14] helo=smtpd.itss.auckland.ac.nz) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D6EGU-0003M0-00 for ipfix@net.doit.wisc.edu; Tue, 01 Mar 2005 14:46:46 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id E0E88349B2; Wed, 2 Mar 2005 09:46:44 +1300 (NZDT) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31214-11; Wed, 2 Mar 2005 09:46:44 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id A859234749; Wed, 2 Mar 2005 09:46:44 +1300 (NZDT) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id j21Kkic25867; Wed, 2 Mar 2005 09:46:44 +1300 Received: from n.brownlee1.enarc.auckland.ac.nz (n.brownlee1.enarc.auckland.ac.nz [130.216.4.32]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Wed, 2 Mar 2005 09:46:44 +1300 Message-ID: <1109710004.bf77a3d5c30d0@webmail.auckland.ac.nz> Date: Wed, 2 Mar 2005 09:46:44 +1300 From: Nevil Brownlee To: agenda@ietf.org Cc: ipfix@net.doit.wisc.edu Subject: [ipfix] Agenda for IPFIX at IETF-62 (Minneapolis) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.4.32 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all: *** I've just realised that the IPFIX meeting agenda, which I emailed to the list on 22 Feb, didn;t get through because I'd changed my own email address. Here it is again ... Nevil *** The IPFIX working group meeting at the Minneapolis (62nd) IETF is scheduled for 1530-1630 on Thursday, 10 Mar 05 Please note that this time we have a one-hour meeting slot. Also, all four IPFIX drafts have been revised at least once since our last meeting. We intend to start a WG Last Call on most - if not all - of them in about a week. Do please read the latest drafts and send your feedback to the list! Below is the current version of our agenda. If you have additional items or corrections, please let us know. Nevil & Dave ---------------------------------------------------------------------- 1) Agenda Review 5 min 2) IPFIX Architecture Changes (draft-ietf-ipfix-architecture-06) [Nevil] 15 min 3) IPFIX Protocol Changes (draft-ietf-ipfix-protocol-08) [Benoit Claise] 10 min 4) IPFIX Information Model (draft-ietf-ipfix-info-06) [Juergen Quittek] 5 min 5) IPFIX Applicability Statement (draft-ietf-ipfix-as-04) [Tanja Zseby] 10 min 6) IPFIX Aggregation Techniques (draft-dressler-ipfix-aggregation-00.txt) [Falko Dressler] 5 min 6) Per-Packet Information Export [Elisa Boschi] 5 min 7) Review / Update WG milestones (?) ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 3 12:22:40 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20510 for ; Thu, 3 Mar 2005 12:22:40 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D6th4-00030Z-00 for ipfix-list@mil.doit.wisc.edu; Thu, 03 Mar 2005 11:00:58 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D6th2-00030U-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 03 Mar 2005 11:00:57 -0600 Received: from [10.61.64.227] (ams-clip-vpn-dhcp227.cisco.com [10.61.64.227]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id j23H0t115740 for ; Thu, 3 Mar 2005 18:00:55 +0100 (CET) Message-ID: <422742C7.9090702@cisco.com> Date: Thu, 03 Mar 2005 18:00:55 +0100 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] Template Set -> Flow Template Set AND Template Record -> Flow Template Record? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, While reviewing [IPFIX-PROTO] with Thomas Dietz, Thomas had the following suggestion. Why not rename the following two terms? Template Set -> Flow Template Set Template Record -> Flow Template Record The terminology was so far: +------------------+---------------------------------------------+ | | Contents | | +--------------------+------------------------+ | Set | Template Record | data record | +------------------+--------------------+------------------------+ | | | Flow Data Record(s) | | Data Set | / | or | | | | Options Data Record(s) | +------------------+--------------------+------------------------+ | Template Set | Template Record(s) | / | +------------------+--------------------+------------------------+ | Options Template | Options Template | / | | Set | Record(s) | | +------------------+--------------------+------------------------+ Template Record A Template Record defines the structure and interpretation of fields in a Flow Data Record. Options Template Record An Options Template Record defines the structure and interpretation of fields in an Options Data Record, including defining how to scope the applicability of the Options Data Record. The terminology would become Template Set A Template Set is a collection of one or more Template Records that have been grouped together in an IPFIX Message. Options Template Set An Options Template Set is a collection of one or more Options Template Records that have been grouped together in an IPFIX Message. The new terminology would become: +------------------+---------------------------------------------+ | | Contents | | +--------------------+------------------------+ | Set | Template Record | data record | +------------------+--------------------+------------------------+ | | | Flow Data Record(s) | | Data Set | / | or | | | | Options Data Record(s) | +------------------+--------------------+------------------------+ | Flow | Flow | | | Template Set | Template Record(s) | / | +------------------+--------------------+------------------------+ | Options Template | Options Template | / | | Set | Record(s) | | +------------------+--------------------+------------------------+ My view is: even if IPFIX was developed with the notion of flow in mind, the templates and options templates are specified in a generic way, allowing the export of any information elements: even non-flow related So why limit the Template Set to Flow Template Set. Moreover, I'm somehow reluctant to do this terminology change during the last-call, since we've been working with those terms for a long time. However, as draft editor, I will follow the mailing list consensus. Feedback? Note: sometimes, copying figures into email leads to misaligned figures. To be able to correctly read the figures, I use "email forward"... it works for me! Regards, Benoit. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 3 14:24:57 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03998 for ; Thu, 3 Mar 2005 14:24:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D6voh-0006Cp-00 for ipfix-list@mil.doit.wisc.edu; Thu, 03 Mar 2005 13:16:59 -0600 Received: from franclinus.red.cert.org ([192.88.209.16]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D6vog-0006Ck-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 03 Mar 2005 13:16:58 -0600 Received: from ioannes.indigo.cert.org (ioannes.indigo.cert.org [10.60.10.57]) by franclinus.red.cert.org (8.12.10/8.12.10/2.13) with ESMTP id j23JGuNY021457 for ; Thu, 3 Mar 2005 14:16:56 -0500 Received: from [128.237.247.89] (vpn-10-25-4-12.remote.cert.org [10.25.4.12]) by ioannes.indigo.cert.org (8.12.8/8.12.8/2.42.1.1) with ESMTP id j23JGuSc009185 for ; Thu, 3 Mar 2005 14:16:56 -0500 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <40215b7cf1b97f4a6c0ec1c00790e995@cert.org> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-573706660" To: ipfix-protocol@net.doit.wisc.edu From: Brian Trammell Subject: Fwd: [ipfix-protocol] Template Set -> Flow Template Set AND Template Record -> Flow Template Record? Date: Thu, 3 Mar 2005 14:16:49 -0500 X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.51 on 192.88.209.16 Precedence: bulk Sender: majordomo listserver --Apple-Mail-1-573706660 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Mar 3, 2005, at 12:00 PM, Benoit Claise wrote: > Dear all, > > While reviewing [IPFIX-PROTO] with Thomas Dietz, Thomas had the > following suggestion. > Why not rename the following two terms? > Template Set -> Flow Template Set > Template Record -> Flow Template Record > My view is: even if IPFIX was developed with the notion of flow in > mind, the templates and options templates are specified in a generic > way, allowing the export of any information elements: even non-flow > related So why limit the Template Set to Flow Template Set. > Moreover, I'm somehow reluctant to do this terminology change during > the last-call, since we've been working with those terms for a long > time. However, as draft editor, I will follow the mailing list > consensus. > Feedback? I'll unlurk for a moment to agree with you... Here at CERT, we're planning on using IPFIX as the basis for network event data transport and storage system, and flows are only one type of event we'll be supporting. - Brian -- Brian H. Trammell / MTS, CERT/NetSA / / 412.268.9748 --Apple-Mail-1-573706660 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCJ2Kn4/8LCZ4pwvYRAnagAJ9Z/URWTkx+KBF0g/dOvu2x14/CPACeOiAZ Cf4XW7Hqr90kJmVgaLrlKeQ= =MnW2 -----END PGP SIGNATURE----- --Apple-Mail-1-573706660-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 4 03:34:14 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12995 for ; Fri, 4 Mar 2005 03:34:13 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D77yK-0000MX-00 for ipfix-list@mil.doit.wisc.edu; Fri, 04 Mar 2005 02:15:44 -0600 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D77yI-0000MQ-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 04 Mar 2005 02:15:42 -0600 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id A62B410B3B; Fri, 4 Mar 2005 09:17:34 +0100 (CET) Received: from [10.1.1.171] ([10.1.1.171]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Mar 2005 09:15:40 +0100 Date: Fri, 04 Mar 2005 09:16:07 +0100 From: Juergen Quittek To: Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Template Set -> Flow Template Set AND Template Record -> Flow Template Record? Message-ID: <1BD1E65ADE163CA6264C700B@[10.1.1.171]> In-Reply-To: <422742C7.9090702@cisco.com> References: <422742C7.9090702@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 04 Mar 2005 08:15:41.0002 (UTC) FILETIME=[5AC3C2A0:01C52092] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit, I support Thomas's proposal. So far we have Flow Data Record Option data Record Template Record Option template Record So, for the Data records we have one with prefix "Flow" and one with prefix "Option". For the Template record we have one without prefix and one with prefix "Option". The two ones with prefix "Option" correspond to each other: "Option Data Record" and "Option Template Record". The other two also correspond to each other but do not share the same prefix: "Flow Data Record" and "Template Record". This seems to be inconsistent and Thomas's suggestion would make the terminology consistent. Another advantage of Thomas's termonology would be that you can use the term "template records" for addressing both, flow template records and option template records (as you can do already for the data records. Below you argue that IPFIX is basically about flows and therefore "Template Record" does not need a prefix "Flow". Following this line of argumentation we can also achieve consistency of the terminology by renaming "Flow Data Record" into "Data Record". Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 03.03.2005 18:00 h +0100 Benoit Claise wrote: > Dear all, > > While reviewing [IPFIX-PROTO] with Thomas Dietz, Thomas had the following suggestion. > Why not rename the following two terms? > Template Set -> Flow Template Set > Template Record -> Flow Template Record > > The terminology was so far: > > > +------------------+---------------------------------------------+ > | | Contents | > | +--------------------+------------------------+ > | Set | Template Record | data record | > +------------------+--------------------+------------------------+ > | | | Flow Data Record(s) | > | Data Set | / | or | > | | | Options Data Record(s) | > +------------------+--------------------+------------------------+ > | Template Set | Template Record(s) | / | > +------------------+--------------------+------------------------+ > | Options Template | Options Template | / | > | Set | Record(s) | | > +------------------+--------------------+------------------------+ > > Template Record > > A Template Record defines the structure and interpretation of fields > in a Flow Data Record. > > Options Template Record > > An Options Template Record defines the structure and interpretation > of fields in an Options Data Record, including defining how to scope > the applicability of the Options Data Record. The terminology would become > > Template Set > > A Template Set is a collection of one or more Template Records that > have been grouped together in an IPFIX Message. > > Options Template Set > An Options Template Set is a collection of one or more Options > Template Records that have been grouped together in an IPFIX > Message. > > > > > The new terminology would become: > > +------------------+---------------------------------------------+ > | | Contents | > | +--------------------+------------------------+ > | Set | Template Record | data record | > +------------------+--------------------+------------------------+ > | | | Flow Data Record(s) | > | Data Set | / | or | > | | | Options Data Record(s) | > +------------------+--------------------+------------------------+ > | Flow | Flow | | > | Template Set | Template Record(s) | / | > +------------------+--------------------+------------------------+ > | Options Template | Options Template | / | > | Set | Record(s) | | > +------------------+--------------------+------------------------+ > > My view is: even if IPFIX was developed with the notion of flow in mind, the templates and options templates are specified in a generic way, allowing the export of any information elements: even non-flow related So why limit the Template Set to Flow > Template Set. Moreover, I'm somehow reluctant to do this terminology change during the last-call, since we've been working with those terms for a long time. > However, as draft editor, I will follow the mailing list consensus. > Feedback? > > Note: sometimes, copying figures into email leads to misaligned figures. To be able to correctly read the figures, I use "email forward"... it works for me! > > Regards, Benoit. > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 4 04:14:39 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17381 for ; Fri, 4 Mar 2005 04:14:39 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D78cH-0003ep-00 for ipfix-list@mil.doit.wisc.edu; Fri, 04 Mar 2005 02:57:01 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D78cF-0003ea-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 04 Mar 2005 02:56:59 -0600 Received: from [10.61.82.72] (ams-clip-vpn-dhcp4681.cisco.com [10.61.82.72]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id j248uw105254; Fri, 4 Mar 2005 09:56:58 +0100 (CET) Message-ID: <422822D8.9010300@cisco.com> Date: Fri, 04 Mar 2005 09:56:56 +0100 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Template Set -> Flow Template Set AND Template Record -> Flow Template Record? References: <422742C7.9090702@cisco.com> <1BD1E65ADE163CA6264C700B@[10.1.1.171]> In-Reply-To: <1BD1E65ADE163CA6264C700B@[10.1.1.171]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen, > Benoit, > > I support Thomas's proposal. > > So far we have > > Flow Data Record > Option data Record > Template Record > Option template Record > > So, for the Data records we have one with prefix "Flow" > and one with prefix "Option". > > For the Template record we have one without prefix > and one with prefix "Option". > > The two ones with prefix "Option" correspond to each other: > "Option Data Record" and "Option Template Record". > > The other two also correspond to each other but do not share > the same prefix: "Flow Data Record" and "Template Record". > > This seems to be inconsistent and Thomas's suggestion would > make the terminology consistent. > > Another advantage of Thomas's termonology would be that you > can use the term "template records" for addressing both, > flow template records and option template records (as you can > do already for the data records. > > > Below you argue that IPFIX is basically about flows and > therefore "Template Record" does not need a prefix "Flow". > Following this line of argumentation we can also achieve > consistency of the terminology by renaming "Flow Data Record" > into "Data Record". Replacing "Flow Data Record" by "Data Record" is a good idea that will bring consistency of the terminology. I support this idea. Regards, Benoit. > > Thanks, > > Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 4 04:37:32 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19459 for ; Fri, 4 Mar 2005 04:37:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D799l-000727-00 for ipfix-list@mil.doit.wisc.edu; Fri, 04 Mar 2005 03:31:37 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D799j-000722-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 04 Mar 2005 03:31:36 -0600 Received: from [193.175.133.240] (kaitos [193.175.133.240]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j249VU502783 for ; Fri, 4 Mar 2005 10:31:30 +0100 (MET) Message-ID: <42282AF2.9060409@fokus.fraunhofer.de> Date: Fri, 04 Mar 2005 10:31:30 +0100 From: Lutz Mark User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Template Set -> Flow Template Set AND Template Record -> Flow Template Record? References: <422742C7.9090702@cisco.com> <1BD1E65ADE163CA6264C700B@[10.1.1.171]> <422822D8.9010300@cisco.com> In-Reply-To: <422822D8.9010300@cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit >> Below you argue that IPFIX is basically about flows and >> therefore "Template Record" does not need a prefix "Flow". >> Following this line of argumentation we can also achieve >> consistency of the terminology by renaming "Flow Data Record" >> into "Data Record". > > Replacing "Flow Data Record" by "Data Record" is a good idea that will > bring consistency of the terminology. > I support this idea. so I vote for the terms: Template Set, Template Record, Date Record Regards, Lutz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From Judita@kendallgroup.com Fri Mar 4 05:06:54 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23274 for ; Fri, 4 Mar 2005 05:06:53 -0500 (EST) Received: from pd9573f78.dip.t-dialin.net ([217.87.63.120] helo=kendallgroup.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1D79db-0001dK-00 for ipfix-list@mil.doit.wisc.edu; Fri, 04 Mar 2005 04:02:27 -0600 From: "Rolande Paulsen" To: "Theda Blackburn" Subject: BBJ 49-Pharmaaccy Date: Fri, 4 Mar 2005 13:15:57 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C51E97.4228B0D1" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-RBL-Warning: (dnsbl.njabl.org) Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C51E97.4228B0D1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Have a nice day. ------=_NextPart_000_004D_01C51E97.4228B0D1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello, Visit Our PharmMail=20 SH0P.
 
SP  OF  Vi ra $200(120p.) Ci is $300(150p.) Lev ra $300(50p.)
ECIAL FER: ag al it
And Many Other!
 
With each purchase you = get:
  • Home delivery
  • Total confidentiality
  • FDAApproved
  • Highest Quality
    •  
    Have a nice = day.
    ------=_NextPart_000_004D_01C51E97.4228B0D1-- From majordomo@mil.doit.wisc.edu Fri Mar 4 05:35:18 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26473 for ; Fri, 4 Mar 2005 05:35:18 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D7A3K-0003hR-00 for ipfix-list@mil.doit.wisc.edu; Fri, 04 Mar 2005 04:29:02 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D7A3I-0003hJ-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 04 Mar 2005 04:29:00 -0600 Received: from [10.61.82.72] (ams-clip-vpn-dhcp4681.cisco.com [10.61.82.72]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id j24ASo110100; Fri, 4 Mar 2005 11:28:50 +0100 (CET) Message-ID: <42283860.50402@cisco.com> Date: Fri, 04 Mar 2005 11:28:48 +0100 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lutz Mark CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Template Set -> Flow Template Set AND Template Record -> Flow Template Record? References: <422742C7.9090702@cisco.com> <1BD1E65ADE163CA6264C700B@[10.1.1.171]> <422822D8.9010300@cisco.com> <42282AF2.9060409@fokus.fraunhofer.de> In-Reply-To: <42282AF2.9060409@fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Lutz Mark wrote: >>> Below you argue that IPFIX is basically about flows and >>> therefore "Template Record" does not need a prefix "Flow". >>> Following this line of argumentation we can also achieve >>> consistency of the terminology by renaming "Flow Data Record" >>> into "Data Record". >> >> >> Replacing "Flow Data Record" by "Data Record" is a good idea that >> will bring consistency of the terminology. >> I support this idea. > > > so I vote for the terms: Template Set, Template Record, Date Record Too make sure we all agree, the new terminology table would look like: +------------------+---------------------------------------------+ | | Contents | | +--------------------+------------------------+ | Set | Template Record | data record | +------------------+--------------------+------------------------+ | Data Set | / | Data Record(s) | +------------------+--------------------+------------------------+ | Template Set | Template Record(s) | / | +------------------+--------------------+------------------------+ | Options Template | Options Template | / | | Set | Record(s) | | +------------------+--------------------+------------------------+ Regards, Benoit. Regards, Benoit. > > Regards, > Lutz > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 4 06:00:34 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28679 for ; Fri, 4 Mar 2005 06:00:33 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D7ATI-0005va-00 for ipfix-list@mil.doit.wisc.edu; Fri, 04 Mar 2005 04:55:52 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D7ATH-0005vV-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 04 Mar 2005 04:55:51 -0600 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 04 Mar 2005 12:15:17 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j24Atllu026072; Fri, 4 Mar 2005 11:55:47 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp65.cisco.com [10.61.64.65]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA06253; Fri, 4 Mar 2005 10:55:46 GMT Message-ID: <42283EB1.1090703@cisco.com> Date: Fri, 04 Mar 2005 10:55:45 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Template Set -> Flow Template Set AND Template Record -> Flow Template Record? References: <422742C7.9090702@cisco.com> <1BD1E65ADE163CA6264C700B@[10.1.1.171]> <422822D8.9010300@cisco.com> In-Reply-To: <422822D8.9010300@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > Replacing "Flow Data Record" by "Data Record" is a good idea that will > bring consistency of the terminology. > I support this idea. and me. Stewart -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 4 06:04:57 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29065 for ; Fri, 4 Mar 2005 06:04:56 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D7AXE-0005yN-00 for ipfix-list@mil.doit.wisc.edu; Fri, 04 Mar 2005 04:59:56 -0600 Received: from c3p0.cc.swin.edu.au ([136.186.1.30] helo=swin.edu.au) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D7AXC-0005yB-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 04 Mar 2005 04:59:55 -0600 Received: from swin.edu.au (szander.caia.swin.edu.au [136.186.229.100]) by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id VAA556488; Fri, 4 Mar 2005 21:59:41 +1100 (EST) Message-ID: <42283FA8.6030504@swin.edu.au> Date: Fri, 04 Mar 2005 21:59:52 +1100 From: Sebastian Zander Organization: Swinburne University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Template Set -> Flow Template Set AND Template Record -> Flow Template Record? References: <422742C7.9090702@cisco.com> <1BD1E65ADE163CA6264C700B@[10.1.1.171]> <422822D8.9010300@cisco.com> In-Reply-To: <422822D8.9010300@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, i don't think it's a good idea to replace 'flow data record' with data record. afterall ipfix is about transporting flow data. data record is already used as a more general term for flow data records and options data records (see Figure A). if you change 'flow data record' to 'data record' 'options data record' would also be a data record and it is not clear anymore what data record means. i like the idea to use more general terms and more specific terms as appropriate and to describe their relation as it is done in Figure A. there are some inconsistencies in the terminology section: - 'data record' is not defined as far as i can see (but used in Figure A) (i noticed the difference of using upper and lower case words but it is very confusing in my opinion.) - 'Template Set' and 'Template Records(s)' should change to 'Flow Template Set' and 'Flow Template Records(s)' IMO as pointed out by Thomas (here is the problem i mentioned earlier: a template record is a template record but an option template record is also a template record according to the table, which is confusing) - is there a reason why there is only Data Set and not Flow Data Set and Options Data Set? can't i have separated sets in the ipfix messages? would be good to alphabetically sort the terminology at the end. Cheers, Sebastian Benoit Claise wrote: > Juergen, > >> Benoit, >> >> I support Thomas's proposal. >> >> So far we have >> >> Flow Data Record >> Option data Record >> Template Record >> Option template Record >> >> So, for the Data records we have one with prefix "Flow" >> and one with prefix "Option". >> >> For the Template record we have one without prefix >> and one with prefix "Option". >> >> The two ones with prefix "Option" correspond to each other: >> "Option Data Record" and "Option Template Record". >> >> The other two also correspond to each other but do not share >> the same prefix: "Flow Data Record" and "Template Record". >> >> This seems to be inconsistent and Thomas's suggestion would >> make the terminology consistent. >> >> Another advantage of Thomas's termonology would be that you >> can use the term "template records" for addressing both, >> flow template records and option template records (as you can >> do already for the data records. >> >> >> Below you argue that IPFIX is basically about flows and >> therefore "Template Record" does not need a prefix "Flow". >> Following this line of argumentation we can also achieve >> consistency of the terminology by renaming "Flow Data Record" >> into "Data Record". > > > Replacing "Flow Data Record" by "Data Record" is a good idea that will > bring consistency of the terminology. > I support this idea. > > Regards, Benoit. > >> >> Thanks, >> >> Juergen > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Sebastian Zander http://caia.swin.edu.au -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 4 06:37:44 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03369 for ; Fri, 4 Mar 2005 06:37:44 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D7B2k-000228-00 for ipfix-list@mil.doit.wisc.edu; Fri, 04 Mar 2005 05:32:30 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D7B2j-00020u-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 04 Mar 2005 05:32:29 -0600 Received: from [10.61.82.72] (ams-clip-vpn-dhcp4681.cisco.com [10.61.82.72]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id j24BVk120131; Fri, 4 Mar 2005 12:31:46 +0100 (CET) Message-ID: <42284720.8070600@cisco.com> Date: Fri, 04 Mar 2005 12:31:44 +0100 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sebastian Zander CC: Juergen Quittek , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Template Set -> Flow Template Set AND Template Record -> Flow Template Record? References: <422742C7.9090702@cisco.com> <1BD1E65ADE163CA6264C700B@[10.1.1.171]> <422822D8.9010300@cisco.com> <42283FA8.6030504@swin.edu.au> In-Reply-To: <42283FA8.6030504@swin.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Sebastian, > Hi Benoit, > > i don't think it's a good idea to replace 'flow data record' with data > record. afterall ipfix is about transporting flow data. data record is > already used as a more general term for flow data records and > options data records (see Figure A). if you change 'flow data record' to > 'data record' 'options data record' would also be a data record and it > is not clear anymore what data record means. I see an advantage in having the generic term "Data Record" because: from a Collecting Process point of view, there is no differences between an Options Data Record and an Flow Data Record. It's only whenever you analyze the associate (Options) Template Record that you know whether this is an Options Data Record or an Flow Data Record > > i like the idea to use more general terms and more specific terms as > appropriate and to describe their relation as it is done in Figure A. > > there are some inconsistencies in the terminology section: > - 'data record' is not defined as far as i can see (but used in Figure A) > (i noticed the difference of using upper and lower case words but it is > very confusing in my opinion.) It would have to be if we use the term in Figure A. I would see a definition such as: Data Record A Data Record is a record that contains values of the parameters corresponding to a Template Record or an Options Template Record. +------------------+---------------------------------------------+ | | Contents | | +--------------------+------------------------+ | Set | Template | Record | +------------------+--------------------+------------------------+ | Data Set | / | Data Record(s) | +------------------+--------------------+------------------------+ | Template Set | Template Record(s) | / | +------------------+--------------------+------------------------+ | Options Template | Options Template | / | | Set | Record(s) | | +------------------+--------------------+------------------------+ > - 'Template Set' and 'Template Records(s)' should change to 'Flow > Template > Set' and 'Flow Template Records(s)' IMO as pointed out by Thomas (here > is the problem i mentioned earlier: a template record is a template > record > but an option template record is also a template record according to > the table, which is confusing) Yes, but a special Template Record. Isn't it the case? > - is there a reason why there is only Data Set and not Flow Data Set and > Options Data Set? can't i have separated sets in the ipfix messages? See my explanation before: from a coding point of view, there are no differences between what you call "Flow Data Set" and "Options Data Set." > > would be good to alphabetically sort the terminology at the end. When publishing RFC3954, I had the specific comment from IESG that I should group the terms in a logical order, to increase the readability As the terminology is almost similar, I think it applies to this draft also. Regards, Benoit. > > Cheers, > > Sebastian > > Benoit Claise wrote: > >> Juergen, >> >>> Benoit, >>> >>> I support Thomas's proposal. >>> >>> So far we have >>> >>> Flow Data Record >>> Option data Record >>> Template Record >>> Option template Record >>> >>> So, for the Data records we have one with prefix "Flow" >>> and one with prefix "Option". >>> >>> For the Template record we have one without prefix >>> and one with prefix "Option". >>> >>> The two ones with prefix "Option" correspond to each other: >>> "Option Data Record" and "Option Template Record". >>> >>> The other two also correspond to each other but do not share >>> the same prefix: "Flow Data Record" and "Template Record". >>> >>> This seems to be inconsistent and Thomas's suggestion would >>> make the terminology consistent. >>> >>> Another advantage of Thomas's termonology would be that you >>> can use the term "template records" for addressing both, >>> flow template records and option template records (as you can >>> do already for the data records. >>> >>> >>> Below you argue that IPFIX is basically about flows and >>> therefore "Template Record" does not need a prefix "Flow". >>> Following this line of argumentation we can also achieve >>> consistency of the terminology by renaming "Flow Data Record" >>> into "Data Record". >> >> >> >> Replacing "Flow Data Record" by "Data Record" is a good idea that >> will bring consistency of the terminology. >> I support this idea. >> >> Regards, Benoit. >> >>> >>> Thanks, >>> >>> Juergen >> >> >> >> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >> message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 4 07:38:19 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10993 for ; Fri, 4 Mar 2005 07:38:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D7Bxc-0005kp-00 for ipfix-list@mil.doit.wisc.edu; Fri, 04 Mar 2005 06:31:16 -0600 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D7Bxb-0005k6-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 04 Mar 2005 06:31:15 -0600 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 5DF9EFF36; Fri, 4 Mar 2005 13:33:10 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipfix-protocol] Template Set -> Flow Template Set AND Template Record -> Flow Template Record? Date: Fri, 4 Mar 2005 13:31:13 +0100 Content-Type: multipart/signed; boundary="----=_NextPart_000_0006_01C520BE.6F632210"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [ipfix-protocol] Template Set -> Flow Template Set AND Template Record -> Flow Template Record? Thread-Index: AcUgsBKKC9Y6JuqnQT2ZjtmytnIcSwABVzDQ From: "Thomas Dietz" To: "Benoit Claise" , "Sebastian Zander" Cc: "Juergen Quittek" , Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C520BE.6F632210 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Benoit, I have no objections to use Data Records instead of Flow Data Records and maybe stating that Option Data Records look the same as Data Records and are only interpreted differently according to their template. So we would leave Template Records and Option Template Records in place and achieve also a consistent scheme. Best Regards, Thomas -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Benoit Claise Sent: Friday, March 04, 2005 12:32 PM To: Sebastian Zander Cc: Juergen Quittek; ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Template Set -> Flow Template Set AND Template Record -> Flow Template Record? Hi Sebastian, > Hi Benoit, > > i don't think it's a good idea to replace 'flow data record' with data > record. afterall ipfix is about transporting flow data. data record is > already used as a more general term for flow data records and > options data records (see Figure A). if you change 'flow data record' to > 'data record' 'options data record' would also be a data record and it > is not clear anymore what data record means. I see an advantage in having the generic term "Data Record" because: from a Collecting Process point of view, there is no differences between an Options Data Record and an Flow Data Record. It's only whenever you analyze the associate (Options) Template Record that you know whether this is an Options Data Record or an Flow Data Record > > i like the idea to use more general terms and more specific terms as > appropriate and to describe their relation as it is done in Figure A. > > there are some inconsistencies in the terminology section: > - 'data record' is not defined as far as i can see (but used in Figure A) > (i noticed the difference of using upper and lower case words but it is > very confusing in my opinion.) It would have to be if we use the term in Figure A. I would see a definition such as: Data Record A Data Record is a record that contains values of the parameters corresponding to a Template Record or an Options Template Record. +------------------+---------------------------------------------+ | | Contents | | +--------------------+------------------------+ | Set | Template | Record | +------------------+--------------------+------------------------+ | Data Set | / | Data Record(s) | +------------------+--------------------+------------------------+ | Template Set | Template Record(s) | / | +------------------+--------------------+------------------------+ | Options Template | Options Template | / | | Set | Record(s) | | +------------------+--------------------+------------------------+ > - 'Template Set' and 'Template Records(s)' should change to 'Flow > Template > Set' and 'Flow Template Records(s)' IMO as pointed out by Thomas (here > is the problem i mentioned earlier: a template record is a template > record > but an option template record is also a template record according to > the table, which is confusing) Yes, but a special Template Record. Isn't it the case? > - is there a reason why there is only Data Set and not Flow Data Set and > Options Data Set? can't i have separated sets in the ipfix messages? See my explanation before: from a coding point of view, there are no differences between what you call "Flow Data Set" and "Options Data Set." > > would be good to alphabetically sort the terminology at the end. When publishing RFC3954, I had the specific comment from IESG that I should group the terms in a logical order, to increase the readability As the terminology is almost similar, I think it applies to this draft also. Regards, Benoit. > > Cheers, > > Sebastian > > Benoit Claise wrote: > >> Juergen, >> >>> Benoit, >>> >>> I support Thomas's proposal. >>> >>> So far we have >>> >>> Flow Data Record >>> Option data Record >>> Template Record >>> Option template Record >>> >>> So, for the Data records we have one with prefix "Flow" >>> and one with prefix "Option". >>> >>> For the Template record we have one without prefix >>> and one with prefix "Option". >>> >>> The two ones with prefix "Option" correspond to each other: >>> "Option Data Record" and "Option Template Record". >>> >>> The other two also correspond to each other but do not share >>> the same prefix: "Flow Data Record" and "Template Record". >>> >>> This seems to be inconsistent and Thomas's suggestion would >>> make the terminology consistent. >>> >>> Another advantage of Thomas's termonology would be that you >>> can use the term "template records" for addressing both, >>> flow template records and option template records (as you can >>> do already for the data records. >>> >>> >>> Below you argue that IPFIX is basically about flows and >>> therefore "Template Record" does not need a prefix "Flow". >>> Following this line of argumentation we can also achieve >>> consistency of the terminology by renaming "Flow Data Record" >>> into "Data Record". >> >> >> >> Replacing "Flow Data Record" by "Data Record" is a good idea that >> will bring consistency of the terminology. >> I support this idea. >> >> Regards, Benoit. >> >>> >>> Thanks, >>> >>> Juergen >> >> >> >> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >> message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ ------=_NextPart_000_0006_01C520BE.6F632210 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJGjCCA8Uw ggMuoAMCAQICEF8x7NoPUxKyR3Pwm4URBVEwDQYJKoZIhvcNAQEFBQAwdTEkMCIGCSqGSIb3DQEJ ARYVY29yZWFkbUBuZXRsYWIubmVjLmRlMQswCQYDVQQGEwJERTELMAkGA1UEBxMCSEQxGDAWBgNV BAoTD05FQyBFdXJvcGUgTHRkLjELMAkGA1UECxMCSEQxDDAKBgNVBAMTA05FQzAeFw0wNDA2MzAw OTMxNDFaFw0wNjA2MzAwOTQwMDNaMHUxJDAiBgkqhkiG9w0BCQEWFWNvcmVhZG1AbmV0bGFiLm5l Yy5kZTELMAkGA1UEBhMCREUxCzAJBgNVBAcTAkhEMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4x CzAJBgNVBAsTAkhEMQwwCgYDVQQDEwNORUMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKP4 YxqYa9dIECafjm3xdd6xiE4/0+qrXKhKWhgTZ0sAEV3dDsBJa+FU79wvAnqBfm/4PoGB/gaVbAi/ LhcHupDCivn9o+0KkKpqiAuS6B3n2ocw1Hjc7leethO6oTYWGkObA7HYdlkRzxs8aXPmAsiEX2VU kjRSwnXfi2ht5ItBAgMBAAGjggFUMIIBUDATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUUtmuJmrerNKKTKiUV2rjc+fa1JcwgecGA1Ud HwSB3zCB3DCBqqCBp6CBpIaBoWxkYXA6Ly8vQ049TkVDKDEpLENOPXNvbCxDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1vZmZp Y2U/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1 dGlvblBvaW50MC2gK6AphidodHRwOi8vc29sLm9mZmljZS9DZXJ0RW5yb2xsL05FQygxKS5jcmww EgYJKwYBBAGCNxUBBAUCAwEAATANBgkqhkiG9w0BAQUFAAOBgQChfPeuQ/VSeGerBIn42+NhaXfG reGjAW0ZRRnEG7YKQbVfMaIzuypc72+wsfkVdulX8g6MkLL5E7haj/1WY+6yAPQbj6jhvuitjkXm 71HyHU8Lb+3e2Co9xt/J8qeb2Y1VEfvyihpDcX9rQ/OYuXXIK2TA9Ongl8bsBNyctnLeODCCBU0w ggS2oAMCAQICCiRl7KQAAQAAARwwDQYJKoZIhvcNAQEFBQAwdTEkMCIGCSqGSIb3DQEJARYVY29y ZWFkbUBuZXRsYWIubmVjLmRlMQswCQYDVQQGEwJERTELMAkGA1UEBxMCSEQxGDAWBgNVBAoTD05F QyBFdXJvcGUgTHRkLjELMAkGA1UECxMCSEQxDDAKBgNVBAMTA05FQzAeFw0wNTAyMTQxMDAwNTFa Fw0wNjAyMTQxMDAwNTFaMGMxFjAUBgoJkiaJk/IsZAEZFgZvZmZpY2UxDjAMBgNVBAMTBVVzZXJz MQ4wDAYDVQQDEwVEaWV0ejEpMCcGCSqGSIb3DQEJARYaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANg8CTLAGigw+HgIFokohiMGo8K3Eeeb1whg HTrSh8Xlyfay3mamZn9T1VRGtCGbooYXqOwjVeNg88TTMyT4JPZCGKi87vxgjRDOg6bq8LmRZcM5 ZXQxddIrlMXs8f7Q5eMA2MUhrCsYWlodCGpWyU1Dun2rKIsvq8UJ2p6x6lQ3AgMBAAGjggL0MIIC 8DALBgNVHQ8EBAMCBaAwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcN AwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBT7FX0nNde2F0WNdDohyBNsyp/Q 9jAXBgkrBgEEAYI3FAIECh4IAFUAcwBlAHIwHwYDVR0jBBgwFoAUUtmuJmrerNKKTKiUV2rjc+fa 1JcwgeEGA1UdHwSB2TCB1jCB06CB0KCBzYaBoWxkYXA6Ly8vQ049TkVDKDEpLENOPXNvbCxDTj1D RFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz1vZmZpY2U/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNS TERpc3RyaWJ1dGlvblBvaW50hidodHRwOi8vc29sLm9mZmljZS9DZXJ0RW5yb2xsL05FQygxKS5j cmwwge0GCCsGAQUFBwEBBIHgMIHdMIGaBggrBgEFBQcwAoaBjWxkYXA6Ly8vQ049TkVDLENOPUFJ QSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9u LERDPW9mZmljZT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1 dGhvcml0eTA+BggrBgEFBQcwAoYyaHR0cDovL3NvbC5vZmZpY2UvQ2VydEVucm9sbC9zb2wub2Zm aWNlX05FQygxKS5jcnQwKQYDVR0lBCIwIAYKKwYBBAGCNwoDBAYIKwYBBQUHAwQGCCsGAQUFBwMC MEMGA1UdEQQ8MDqgHAYKKwYBBAGCNxQCA6AODAxkaWV0ekBvZmZpY2WBGlRob21hcy5EaWV0ekBu ZXRsYWIubmVjLmRlMA0GCSqGSIb3DQEBBQUAA4GBACt8XGDQ4kPlY2NT2jHjCqmo3eYBeZEPOwR1 k0t3aT8lkH0eAMZnLE5ix0GrBDuJp5nnjuigzXqPIqf9SWSbSTXgWz8d5jNsg4c307cKIHilyWYl ydaOy9p2hdqZ28pHrHjiAMKSe4Ds/dUVOrhc7MhSdlxJBnXNYXojX7HShdlnMYIDJDCCAyACAQEw gYMwdTEkMCIGCSqGSIb3DQEJARYVY29yZWFkbUBuZXRsYWIubmVjLmRlMQswCQYDVQQGEwJERTEL MAkGA1UEBxMCSEQxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjELMAkGA1UECxMCSEQxDDAKBgNV BAMTA05FQwIKJGXspAABAAABHDAJBgUrDgMCGgUAoIIB9jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNTAzMDQxMjMxMTNaMCMGCSqGSIb3DQEJBDEWBBT5x4PvG3Nf goQP4j/HI08wiHow1DBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTCBlAYJKwYBBAGCNxAEMYGGMIGDMHUxJDAiBgkqhkiG9w0BCQEWFWNvcmVhZG1AbmV0bGFi Lm5lYy5kZTELMAkGA1UEBhMCREUxCzAJBgNVBAcTAkhEMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0 ZC4xCzAJBgNVBAsTAkhEMQwwCgYDVQQDEwNORUMCCiRl7KQAAQAAARwwgZYGCyqGSIb3DQEJEAIL MYGGoIGDMHUxJDAiBgkqhkiG9w0BCQEWFWNvcmVhZG1AbmV0bGFiLm5lYy5kZTELMAkGA1UEBhMC REUxCzAJBgNVBAcTAkhEMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xCzAJBgNVBAsTAkhEMQww CgYDVQQDEwNORUMCCiRl7KQAAQAAARwwDQYJKoZIhvcNAQEBBQAEgYDFwe43pVe3lzbFlZNn+UCs BwuWK+iIR7SOpWVcugtBYnyc4DMjsdaAdKd0J/8nf/pkVLURpJxRdWUPHCWCtZ9RGH6JE2gLAM7W iqzl50oi16Jk9X0AE3QKgvOWTlGiI7WEk9e3cUlVm4WcAmG0r9rmsx10X5/3xRq3dIq+fK36yQAA AAAAAA== ------=_NextPart_000_0006_01C520BE.6F632210-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sun Mar 6 14:11:46 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11202 for ; Sun, 6 Mar 2005 14:11:45 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D80rF-0005IK-00 for ipfix-list@mil.doit.wisc.edu; Sun, 06 Mar 2005 12:52:05 -0600 Received: from chico.itss.auckland.ac.nz ([130.216.190.12] helo=smtpb.itss.auckland.ac.nz) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D80rE-0005IC-00 for ipfix@net.doit.wisc.edu; Sun, 06 Mar 2005 12:52:04 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id EC8D634D7D for ; Mon, 7 Mar 2005 07:52:02 +1300 (NZDT) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24779-15 for ; Mon, 7 Mar 2005 07:52:02 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id D4A19345D4 for ; Mon, 7 Mar 2005 07:52:02 +1300 (NZDT) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id j26Iq2v01151 for ipfix@net.doit.wisc.edu; Mon, 7 Mar 2005 07:52:02 +1300 Received: from wireless-130-129-135-58.ietf62.ietf.org (wireless-130-129-135-58.ietf62.ietf.org [130.129.135.58]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Mon, 7 Mar 2005 07:52:02 +1300 Message-ID: <1110135122.095526cd2c443@webmail.auckland.ac.nz> Date: Mon, 7 Mar 2005 07:52:02 +1300 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] Document Editors get-together at IETF 62 ?? MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.129.135.58 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all: We (Dave and I) would like to hold a session where all the draft editors, and anyone else who is interested, go through the drafts and sort out any changes needed to them before we submit them to IESG. How would Tuesday afternoon, starting after lunch at 1300, suit everyone, please? Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sun Mar 6 15:28:05 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22511 for ; Sun, 6 Mar 2005 15:28:05 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D82Gy-0006MP-00 for ipfix-list@mil.doit.wisc.edu; Sun, 06 Mar 2005 14:22:44 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D82Gx-0006MI-00 for ipfix-protocol@net.doit.wisc.edu; Sun, 06 Mar 2005 14:22:43 -0600 Received: from [10.83.97.55] (rtp-dial-1-55.cisco.com [10.83.97.55]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id j26KMf104181 for ; Sun, 6 Mar 2005 21:22:41 +0100 (CET) Message-ID: <422B47BD.2010304@cisco.com> Date: Sun, 06 Mar 2005 19:11:09 +0100 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] some more info regarding the scope in [IPFIX-INFO] Content-Type: multipart/alternative; boundary="------------030009000100070909000200" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------030009000100070909000200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, While reviewing the draft with Juergen Quittek and Thomas Dietz, we realized that we were lacking some information about the scope. We propose the following text. An IPFIX compliant implementation of the Collecting Process MUST support this minimum set of Information Element as scope: LineCardId, TemplateId, exporterIPv4Address, exporterIPv6Address, and ingressInterface. Note that other Information Elements such as meteringProcessId, exportingProcessId, sourceId, etc. are also valid scopes. The IPFIX protocol doesn't prevent the use of any Information Elements for scope. However some Information Element types don't make sense if specifed as scope. Example: the counters Information Elements. Regards, Benoit. --------------030009000100070909000200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

    While reviewing the draft with Juergen Quittek and Thomas Dietz, we realized that we were lacking some information about the scope.
    We propose the following text.

    An IPFIX compliant implementation of the Collecting Process MUST
    support this minimum set of Information Element as scope: 
    LineCardId, TemplateId, exporterIPv4Address, exporterIPv6Address, and ingressInterface. Note that other Information Elements such as meteringProcessId, exportingProcessId, sourceId, etc. are also valid scopes. The IPFIX protocol doesn't prevent the use of any Information Elements for scope. However some Information Element types don't make sense if specifed as scope. Example: the counters Information Elements.

    Regards, Benoit.
    --------------030009000100070909000200-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sun Mar 6 15:28:31 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22585 for ; Sun, 6 Mar 2005 15:28:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D82Gr-0006MF-00 for ipfix-list@mil.doit.wisc.edu; Sun, 06 Mar 2005 14:22:37 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D82Gq-0006MA-00 for ipfix-protocol@net.doit.wisc.edu; Sun, 06 Mar 2005 14:22:36 -0600 Received: from [10.83.97.55] (rtp-dial-1-55.cisco.com [10.83.97.55]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id j26KMW104107 for ; Sun, 6 Mar 2005 21:22:33 +0100 (CET) Message-ID: <422B448A.6000800@cisco.com> Date: Sun, 06 Mar 2005 18:57:30 +0100 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] Review of the "7. Specific Reporting Requirements" and of the ipfixOption Information Element Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, While reviewing IPFIX-PROTO with Juergen Quittek and Thomas Dietz, we realized that we don't need the ipfixOption Information Element, as specified in the section "7. Specific Reporting Requirements". A scope is already defined for all Option Templates: - The Metering Process Statistics Option Template - The Metering Process Reliability Statistics Option Template - The Exporting Process Reliability Statistics Option Template - The Flow Keys Option Template As a consequence, we don't need the ipfixOption Element to specify the option template type. Below is the new proposed text (see http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-08.txt for comparison) - I simply removed the notion of ipfixOption in the introduction - I moved the scope in the list of I.E, and replaced the ipfixOption - The rest is unchanged Note also that I clarified what the time is suppposed to be. Regards, Benoit ======================================= 7. Specific Reporting Requirements Some specific Options Templates and Options Templates Records are necessary to provide extra information about the Flow Records and about the Metering Process. The Option Template and Option Template Records defined in these sub-sections are not mandatory to implement as they impose some constraints about the Metering Process implementation: this document specifies the protocol to export the records, not the Metering Process implementation. However, if the specific Option Templates are implemented, they should ideally be implemented as specified in these sub-sections. The minimum set of Information Elements is always specified in these Specific IPFIX Options Templates. Nevertheless, extra Information Elements may be used in these specific Options Templates. 7.1 The Metering Process Statistics Option Template The Metering Process Statistics Option Template specifies the Metering Process Statistics. It contains the following Information Elements [IPFIX-INFO]: sourceID The Source ID. This Information Element MUST be defined as a Scope Field Type exportedOctetCount The number of all octets reported by the Exporting Process to the Collecting Process. exportedPacketCount The number of all packets reported by the exporting process to the Collecting Process. exportedFlowCount The number of all flows records reported by the Exporting Process to the Collecting Process. time One of the time-related Information Elements in [IPFIX-INFO], depending on the required time precision: TimeSeconds, MilliSeconds, MicroSeconds, or NanoSeconds The Exporting Process should export the Metering Process Statistics Option Template Record on a regular basis or based on some export policy. This periodicity or export policy should be configurable. The Metering Process Statistics Option Template could be extended with other Information Elements. Note that if several Metering Processes are available on the Exporter Observation Domain, an extra Scope Field MeteringProcessID must be added to this Option Template. 7.2 The Metering Process Reliability Statistics Option Template The Metering Process Reliability Option Template specifies information about lack of reliability in the Metering process. It contains the following Information Elements [IPFIX-INFO]: sourceID The Source ID. This Information Element MUST be defined as a Scope Field Type droppedFUPacketCount Packets dropped by Metering Process droppedFUOctetCount Bytes dropped by Metering Process timeFirstFUDropped Time of the first packet dropped at the Specified scope ID timeLastFUDropped Time of the last packet dropped at the Specified scope ID time One of the time-related Information Elements in [IPFIX-INFO], depending on the required time precision: TimeSeconds, MilliSeconds, MicroSeconds, or NanoSeconds The Exporting Process should export the Metering Process Reliability Statistics Option Template Record on a regular basis or based on some export policy. This periodicity or export policy should be configurable. The Metering Process Reliability Statistics Option Template could be extended with other Information Elements. Note that if several Metering Processes are available on the Exporter Observation Domain, an extra Scope Field MeteringProcessID must be added to this Option Template. 7.3 The Exporting Process Reliability Statistics Option Template The Exporting Process Reliability Option Template specifies information about lack of reliability in the Exporting process. It contains the following Information Elements [IPFIX-INFO]: exporterID Either the exporterIPv4Address or exporterIPv6Address [IPFIX-INFO]. This Information Element MUST be defined as a Scope Field Type droppedFlows Number of flow records not exported (due to resources starvation at Exporting Process or due to some flow records export policies) droppedFAPacketCount Packets in the dropped flows droppedFAByteCount Bytes in the dropped flows timeFirstFADropped Time of the first packet within the dropped flows timeLastFADropped Time of the last packet within the dropped flows time One of the time-related Information Elements in [IPFIX-INFO], depending on the required time precision: TimeSeconds, MilliSeconds, MicroSeconds, or NanoSeconds The Exporting Process should export the Exporting Process Reliability Statistics Option Template Record on a regular basis or based on some export policy. This periodicity or export policy should be configurable. The Exporting Process Reliability Statistics Option Template could be extended with other Information Elements. Note that if several Exporting Processes are available on the Exporter Observation Domain, an extra Scope Field exportingProcessID must be added to this Option Template. 7.4 The Flow Keys Option Template The Flow Keys Option Template specifies the flow keys used by the Metering Process for the Template ID definition. It contains the following Information Elements [IPFIX-INFO]: templateID The Template ID. This Information Element MUST be defined as a Scope Field Type keyList Bitmap with the positions of the flow keys in the template time One of the time-related Information Elements in [IPFIX-INFO], depending on the required time precision: TimeSeconds, MilliSeconds, MicroSeconds, or NanoSeconds -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sun Mar 6 21:14:37 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24424 for ; Sun, 6 Mar 2005 21:14:36 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D87f4-0002WC-00 for ipfix-list@mil.doit.wisc.edu; Sun, 06 Mar 2005 20:07:58 -0600 Received: from c3p0.cc.swin.edu.au ([136.186.1.30] helo=swin.edu.au) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D87f2-0002W7-00 for ipfix-protocol@net.doit.wisc.edu; Sun, 06 Mar 2005 20:07:57 -0600 Received: from swin.edu.au (szander.caia.swin.edu.au [136.186.229.100]) by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id NAA1011910; Mon, 7 Mar 2005 13:07:37 +1100 (EST) Message-ID: <422BB771.3050105@swin.edu.au> Date: Mon, 07 Mar 2005 13:07:45 +1100 From: Sebastian Zander Organization: Swinburne University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Template Set -> Flow Template Set AND Template Record -> Flow Template Record? References: <422742C7.9090702@cisco.com> <1BD1E65ADE163CA6264C700B@[10.1.1.171]> <422822D8.9010300@cisco.com> <42283FA8.6030504@swin.edu.au> <42284720.8070600@cisco.com> In-Reply-To: <42284720.8070600@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, i'm not against having the term Data Record (in fact we already had it in Figure A). i'm against completely replacing 'Flow Data Record' with Data Record. the term Data Record should be qualified with either Flow or Options when we specifically talk about one of them because currently there are separate defintions for them (e.g. section 6.4 and section 6.5.3). you are completely right that there is no difference between options data records and flow data record and the only difference between the templates is the scope field count (from the colltector's viewpoint). then why do we need to have separate defintions? we could easily reduce the protocol to one template format (the options template set format) and one data set format. in my opinion the 2 byte scope field count does not justify to duplicate the defintion. instead of trying to make the protocol look simpler and more general by changing terminology we should actually make it simpler and more general. Cheers, Sebastian Benoit Claise wrote: > Hi Sebastian, > >> Hi Benoit, >> >> i don't think it's a good idea to replace 'flow data record' with data >> record. afterall ipfix is about transporting flow data. data record is >> already used as a more general term for flow data records and >> options data records (see Figure A). if you change 'flow data record' to >> 'data record' 'options data record' would also be a data record and it >> is not clear anymore what data record means. > > > I see an advantage in having the generic term "Data Record" because: > from a Collecting Process point of view, there is no differences between > an Options Data Record and an Flow Data Record. > It's only whenever you analyze the associate (Options) Template Record > that you know whether this is an Options Data Record or an Flow Data Record > >> >> i like the idea to use more general terms and more specific terms as >> appropriate and to describe their relation as it is done in Figure A. >> >> there are some inconsistencies in the terminology section: >> - 'data record' is not defined as far as i can see (but used in Figure A) >> (i noticed the difference of using upper and lower case words but it is >> very confusing in my opinion.) > > > It would have to be if we use the term in Figure A. > I would see a definition such as: > > Data Record A Data Record is a record that contains values of the > parameters corresponding to a Template Record or an Options Template > Record. > +------------------+---------------------------------------------+ > | | Contents | > | +--------------------+------------------------+ > | Set | Template | Record | > +------------------+--------------------+------------------------+ > | Data Set | / | Data Record(s) | > +------------------+--------------------+------------------------+ > | Template Set | Template Record(s) | / | > +------------------+--------------------+------------------------+ | > Options Template | Options Template | / | > | Set | Record(s) | | > +------------------+--------------------+------------------------+ > >> - 'Template Set' and 'Template Records(s)' should change to 'Flow >> Template >> Set' and 'Flow Template Records(s)' IMO as pointed out by Thomas (here >> is the problem i mentioned earlier: a template record is a template >> record >> but an option template record is also a template record according to >> the table, which is confusing) > > > Yes, but a special Template Record. Isn't it the case? > >> - is there a reason why there is only Data Set and not Flow Data Set and >> Options Data Set? can't i have separated sets in the ipfix messages? > > > See my explanation before: from a coding point of view, there are no > differences between what you call "Flow Data Set" and > "Options Data Set." > >> >> would be good to alphabetically sort the terminology at the end. > > > When publishing RFC3954, I had the specific comment from IESG that I > should group the terms in a logical order, to increase the readability > As the terminology is almost similar, I think it applies to this draft > also. > > Regards, Benoit. > >> >> Cheers, >> >> Sebastian >> >> Benoit Claise wrote: >> >>> Juergen, >>> >>>> Benoit, >>>> >>>> I support Thomas's proposal. >>>> >>>> So far we have >>>> >>>> Flow Data Record >>>> Option data Record >>>> Template Record >>>> Option template Record >>>> >>>> So, for the Data records we have one with prefix "Flow" >>>> and one with prefix "Option". >>>> >>>> For the Template record we have one without prefix >>>> and one with prefix "Option". >>>> >>>> The two ones with prefix "Option" correspond to each other: >>>> "Option Data Record" and "Option Template Record". >>>> >>>> The other two also correspond to each other but do not share >>>> the same prefix: "Flow Data Record" and "Template Record". >>>> >>>> This seems to be inconsistent and Thomas's suggestion would >>>> make the terminology consistent. >>>> >>>> Another advantage of Thomas's termonology would be that you >>>> can use the term "template records" for addressing both, >>>> flow template records and option template records (as you can >>>> do already for the data records. >>>> >>>> >>>> Below you argue that IPFIX is basically about flows and >>>> therefore "Template Record" does not need a prefix "Flow". >>>> Following this line of argumentation we can also achieve >>>> consistency of the terminology by renaming "Flow Data Record" >>>> into "Data Record". >>> >>> >>> >>> >>> Replacing "Flow Data Record" by "Data Record" is a good idea that >>> will bring consistency of the terminology. >>> I support this idea. >>> >>> Regards, Benoit. >>> >>>> >>>> Thanks, >>>> >>>> Juergen >>> >>> >>> >>> >>> >>> >>> -- >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>> message body >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>> "unsubscribe ipfix" in message body >>> Archive http://ipfix.doit.wisc.edu/archive/ >>> >> > > -- Sebastian Zander http://caia.swin.edu.au -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sun Mar 6 21:30:28 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25172 for ; Sun, 6 Mar 2005 21:30:28 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D87sv-0002hD-00 for ipfix-list@mil.doit.wisc.edu; Sun, 06 Mar 2005 20:22:17 -0600 Received: from c3p0.cc.swin.edu.au ([136.186.1.30] helo=swin.edu.au) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D87st-0002h8-00 for ipfix-protocol@net.doit.wisc.edu; Sun, 06 Mar 2005 20:22:15 -0600 Received: from swin.edu.au (szander.caia.swin.edu.au [136.186.229.100]) by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id NAA1012294; Mon, 7 Mar 2005 13:22:11 +1100 (EST) Message-ID: <422BBAE0.8060407@swin.edu.au> Date: Mon, 07 Mar 2005 13:22:24 +1100 From: Sebastian Zander Organization: Swinburne University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] clarity of the ipfix spec Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, when reading the ipfix protocol spec it is sometimes not clear how much is specification and how much is example. two examples: figure H shows 'Template ID 256'. i suppose this does not mean that the first template ID in any template set is always 256 but template IDs must be >=256 right? such example values should be removed from the defintion (and btw there is no template ID example value in figure J). figure H shows 2 template records and figure J shows 1 template record but i guess option sets can have an arbitrary number of records right? maybe something like ABNF would help (see RFC2234) e.g. ipfix_message = ipfix_header 1*(data_set / template_set / options_template_set) ... Cheers, Sebastian -- Sebastian Zander http://caia.swin.edu.au -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sun Mar 6 23:26:06 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04428 for ; Sun, 6 Mar 2005 23:26:05 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D89ZK-0003yc-00 for ipfix-list@mil.doit.wisc.edu; Sun, 06 Mar 2005 22:10:10 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D89ZJ-0003yX-00 for ipfix-protocol@net.doit.wisc.edu; Sun, 06 Mar 2005 22:10:09 -0600 Received: from [10.82.217.175] (rtp-vpn3-429.cisco.com [10.82.217.175]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id j2749O114036; Mon, 7 Mar 2005 05:09:24 +0100 (CET) Message-ID: <422BD3F2.4010704@cisco.com> Date: Mon, 07 Mar 2005 05:09:22 +0100 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sebastian Zander CC: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] Re: clarity of the ipfix spec References: <422BBAE0.8060407@swin.edu.au> In-Reply-To: <422BBAE0.8060407@swin.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Sebastian, I fully agreed with you. This issue has been addressed already in the new draft version I will publish soon, thanks to Thomas Dietz that re-wrote the entire section. Regards, Benoit. > Hi Benoit, > > when reading the ipfix protocol spec it is sometimes not clear how > much is > specification and how much is example. two examples: > > figure H shows 'Template ID 256'. i suppose this does not mean that > the first > template ID in any template set is always 256 but template IDs must be > >=256 right? > such example values should be removed from the defintion (and btw > there is no > template ID example value in figure J). figure H shows 2 template > records and > figure J shows 1 template record but i guess option sets can have an > arbitrary > number of records right? maybe something like ABNF would help (see > RFC2234) e.g. > > ipfix_message = ipfix_header 1*(data_set / template_set / > options_template_set) > ... > > Cheers, > > Sebastian > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Mar 7 06:43:17 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02342 for ; Mon, 7 Mar 2005 06:43:17 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D8GXj-0002nK-00 for ipfix-list@mil.doit.wisc.edu; Mon, 07 Mar 2005 05:36:59 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D8GXi-0002nF-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 07 Mar 2005 05:36:58 -0600 Received: from [193.175.133.240] (kaitos [193.175.133.240]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j27Bau513150 for ; Mon, 7 Mar 2005 12:36:56 +0100 (MET) Message-ID: <422C3CD8.9020006@fokus.fraunhofer.de> Date: Mon, 07 Mar 2005 12:36:56 +0100 From: Lutz Mark User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] remove chapter 4 from protocol draft X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, the text from chapter 4 "Criteria for Flow Expiration and Export" o is related to the implementation of the metering process and has no direct relation to the IPFIX protocol. o is already included in the architecture draft (chapter 6.1.1) I suggest to remove this chapter from the protocol draft. Best regards, Lutz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Mar 7 18:26:21 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17503 for ; Mon, 7 Mar 2005 18:26:21 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D8RKm-0004Aw-00 for ipfix-list@mil.doit.wisc.edu; Mon, 07 Mar 2005 17:08:20 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D8RKl-0004Aq-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 07 Mar 2005 17:08:19 -0600 Received: from [10.82.240.123] (rtp-vpn2-123.cisco.com [10.82.240.123]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id j27N8F112611 for ; Tue, 8 Mar 2005 00:08:15 +0100 (CET) Message-ID: <422CDEDE.6040303@cisco.com> Date: Tue, 08 Mar 2005 00:08:14 +0100 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] draft-ietf-ipfix-protocol-09.txt available Content-Type: multipart/alternative; boundary="------------060409050502040001060706" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------060409050502040001060706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, A new version of the IPFIX protocol draft has been compiled. As we are in last-call, and as we might discuss some of these already resolved issues this week, allow me to share it with you. If you haven't started yet reviewing draft-ietf-ipfix-protocol-08.txt, start with draft-ietf-ipfix-protocol-09.txt as this is much more complete You can find the draft at ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-protocol-09.txt Here is the list of improvement: - there were inconsistencies in the packet formats of the previous draft. For example, the figure H was not exactly a generic format, and not exactly an example. Thomas Dietz rewrote the full sections 5 and 6. It now contains generic format + separate examples.25 <#_Toc97709690> - corrected a typo, reported by Mark Lutz "an Exporting Process MUST NOT attempt to establish a connection more frequently than once per minute. " - improved examples: * there were inconsistencies between hexa and non hexa value * [IPFIX-INFO] Information Elements ID are now used * the example now uses the lineCardId: PROTO-38 is closed: - new section 9.1 specifying the data types encoding. This was missing for time-related based types, for example. Thanks to Thomas Dietz for writing the text. - consistence of field versus information elements - improved abstract by Juergen Quittek - Corrected the source ID definition: remove Process in "Exporter_ Process_ Observation Domain" - removed ipfixOption in the specific Option Templates Integration of the changes proposed in my post "Review of the "7. Specific Reporting Requirements" and of the ipfixOption Information Element" - the "time" Information Element in the specific Options Templates has been clarified. - Integration of the changes proposed in my post "some more info regarding the scope in [IPFIX-INFO]" - Time related Information Element now in sync. with [IPFIX-INFO] [IPFIX-INFO] specifies: 5.6.15 flowStartDeltaUSeconds Description: The _positive _time offset of the first packet of this flow relative to a base time given in the IPFIX message header. 5.6.16 flowEndDeltaUSeconds Description: The _positive _time offset of the last packet of this flow relative to a base time given in the IPFIX message header. => this implies this change in [IPFIX-] (positive keyword was added) For a Data Set with Flow Records requiring microsecond precision, the IPFIX Message Header "Export Time" field SHOULD be calculated so that each Flow Records flowStartDeltaUsec [IPFIX-INFO] and flowEndDeltaUsec [IPFIX-INFO] would contain a 32 bit _positive_ microsecond offset from the "Export Time" base timestamp. In which case, if Flow Records with a different precision are needed (millisecond or nanosecond), these MUST be sent in different Data Sets. => This implies that the method called the "one-pass approach" is not valid anymore because the offset could also be negative. The following new text was introduced to cover the 2 phases approach For a Data Set with Flow Records requiring microsecond precision, an example of the "Export Time" calculation is the following: before exporting the Flow Records, the Exporting Process takes as "Export Time" the lowest start time of all the Flow Records to be exported in this Data Set. The only constraint is that the highest end time of the Flow Records in that Data Set can not exceed the "Export Time" plus 71 minutes. If a Flow Record end time exceeds this condition, this Flow Record must be exported in a subsequent IPFIX Message. => next definition also changed (second sentence added): Export Time Time in seconds since 0000 UTC 1970, at which the IPFIX Message Header leaves the Exporter. Alternatevily, the Export Time can be a computed value: see the sectin 8 "IPFIX Message Header "Export Time" and Flow Record Time" We are very close to completion, only a few remaining issues: PROTO-100: Flow Data Records would become Data Records (consensus on the mailing so far?) +------------------+---------------------------------------------+ | | Contents | | +--------------------+------------------------+ | Set | Template | Record | +------------------+--------------------+------------------------+ | Data Set | / | Data Record(s) | +------------------+--------------------+------------------------+ | Template Set | Template Record(s) | / | +------------------+--------------------+------------------------+ | Options Template | Options Template | / | | Set | Record(s) | | +------------------+--------------------+------------------------+ PROTO-101: Section 9.1.7 dateTimeMicroSeconds -> "Its encoding is not defined yet." PROTO-102: Duplicate chapter "the text from chapter 4 "Criteria for Flow Expiration and Export" with [IPFIX-ARCH]. Erase this one? Regards, Benoit. --------------060409050502040001060706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

    A new version of the IPFIX protocol draft has been compiled.
    As we are in last-call, and as we might discuss some of these already resolved issues this week, allow me to share it with you.
    If you haven't started yet reviewing draft-ietf-ipfix-protocol-08.txt, start with draft-ietf-ipfix-protocol-09.txt as this is much more complete
    You can find the draft at ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-protocol-09.txt
    Here is the list of improvement:
- there were inconsistencies in the packet formats of the previous draft.
  For example, the figure H was not exactly a generic format, and not exactly an example.
  Thomas Dietz rewrote the full sections 5 and 6. 
  It now contains generic format + separate examples.25
- corrected a typo, reported by Mark Lutz "an Exporting Process MUST NOT 
  attempt to establish a connection more frequently than once per minute. "
- improved examples:
  * there were inconsistencies between hexa and non hexa value 
  * [IPFIX-INFO] Information Elements ID are now used 
  * the example now uses the lineCardId: PROTO-38 is closed: 
- new section 9.1 specifying the data types encoding. This was missing for time-related based types, for example.
  Thanks to Thomas Dietz for writing the text.
- consistence of field versus information elements
- improved abstract by Juergen Quittek
- Corrected the source ID definition: remove Process in "Exporter Process Observation Domain"
- removed ipfixOption in the specific Option Templates
  Integration of the changes proposed in my post "Review of the "7. Specific Reporting
  Requirements" and of the ipfixOption Information Element"
- the "time" Information Element in the specific Options Templates has been clarified. 
- Integration of the changes proposed in my post "some more info regarding the scope in [IPFIX-INFO]"
- Time related Information Element now in sync. with [IPFIX-INFO]
 [IPFIX-INFO] specifies:
    5.6.15  flowStartDeltaUSeconds
       Description: The positive time offset of the first packet of this flow
          relative to a base time given in the IPFIX message header.

    5.6.16  flowEndDeltaUSeconds
       Description: The positive time offset of the last packet of this flow relative
          to a base time given in the IPFIX message header.
     => this implies this change in [IPFIX-] (positive keyword was added)
   For a Data Set with Flow Records requiring microsecond precision, 
   the IPFIX Message Header "Export Time" field SHOULD be calculated so 
   that each Flow Records flowStartDeltaUsec [IPFIX-INFO] and 
   flowEndDeltaUsec [IPFIX-INFO] would contain a 32 bit positive
   microsecond offset from the "Export Time" base timestamp. In which 
   case, if Flow Records with a different precision are needed 
   (millisecond or nanosecond), these MUST be sent in different Data 
   Sets. 
 
 => This implies that the method called the "one-pass approach" is not
    valid anymore because the offset could also be negative. 
    The following new text was introduced to cover the 2 phases approach

    For a Data Set with Flow Records requiring microsecond precision, an example of the "Export Time" calculation is the following: before exporting the Flow Records, the Exporting Process takes as "Export Time" the lowest start time of all the Flow Records to be exported in this Data Set. The only constraint is that the highest end time of the Flow Records in that Data Set can not exceed the "Export Time" plus 71 minutes. If a Flow Record end time exceeds this condition, this Flow Record must be exported in a subsequent IPFIX Message.

     => next definition also changed (second sentence added):
 Export Time 
           Time in seconds since 0000 UTC 1970, at which the IPFIX 
           Message Header leaves the Exporter. Alternatevily, the 
           Export Time can be a computed value: see the sectin 8
           "IPFIX Message Header "Export Time" and Flow Record Time"




We are very close to completion, only a few remaining issues:

  PROTO-100: Flow Data Records would become Data Records (consensus on 
   the mailing so far?)  
   +------------------+---------------------------------------------+  
   |                  |                    Contents                 |  
   |                  +--------------------+------------------------+  
   |       Set        |       Template     |        Record          |  
   +------------------+--------------------+------------------------+  
   |   Data Set       |          /         |     Data Record(s)     |  
   +------------------+--------------------+------------------------+  
   |   Template Set   | Template Record(s) |           /            |  
   +------------------+--------------------+------------------------+  
   | Options Template | Options Template   |           /            |  
   |       Set        |     Record(s)      |                        |  
   +------------------+--------------------+------------------------+  
 
     PROTO-101: Section 9.1.7 dateTimeMicroSeconds -> "Its encoding is 
     not defined yet." 
      
     PROTO-102: Duplicate chapter "the text from chapter 4 "Criteria for 
     Flow Expiration and Export" with [IPFIX-ARCH]. Erase this one? 

Regards, Benoit.
    --------------060409050502040001060706-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Mar 7 19:33:22 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29279 for ; Mon, 7 Mar 2005 19:33:21 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D8SaW-0005Dc-00 for ipfix-list@mil.doit.wisc.edu; Mon, 07 Mar 2005 18:28:40 -0600 Received: from harpo.itss.auckland.ac.nz ([130.216.190.13] helo=smtpc.itss.auckland.ac.nz) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D8SaV-0005DW-00 for ipfix@net.doit.wisc.edu; Mon, 07 Mar 2005 18:28:39 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id AB25A34D9B; Tue, 8 Mar 2005 13:28:35 +1300 (NZDT) Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12637-29; Tue, 8 Mar 2005 13:28:35 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 411DC347FD; Tue, 8 Mar 2005 13:28:35 +1300 (NZDT) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id j280SYA00527; Tue, 8 Mar 2005 13:28:34 +1300 Received: from wired-130-129-67-109.ietf62.ietf.org (wired-130-129-67-109.ietf62.ietf.org [130.129.67.109]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Tue, 8 Mar 2005 13:28:34 +1300 Message-ID: <1110241714.cab0e0e0e4302@webmail.auckland.ac.nz> Date: Tue, 8 Mar 2005 13:28:34 +1300 From: Nevil Brownlee To: ipfix-editors@doit.wisc.edu Cc: ipfix@net.doit.wisc.edu Subject: [ipfix] Document editors get-together: Ramsey, 1300-1500 Tuesday MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.129.67.109 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all: Apologies to those who get two copies of this, I'm just making sure all the document editors get to see it! > We (Dave and I) would like to hold a session where all the draft > editors, and anyone else who is interested, go through the drafts > and sort out any changes needed to them before we submit them to > IESG. We have a room allocated for this, it's Ramsey. See you there, Nevil :-) ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Mar 7 19:49:20 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00945 for ; Mon, 7 Mar 2005 19:49:20 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D8Sp2-0005P4-00 for ipfix-list@mil.doit.wisc.edu; Mon, 07 Mar 2005 18:43:40 -0600 Received: from franclinus.red.cert.org ([192.88.209.16]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D8Sp1-0005Oz-00; Mon, 07 Mar 2005 18:43:39 -0600 Received: from ioannes.indigo.cert.org (ioannes.indigo.cert.org [10.60.10.57]) by franclinus.red.cert.org (8.12.10/8.12.10/2.13) with ESMTP id j280hbNY031368; Mon, 7 Mar 2005 19:43:37 -0500 Received: from [172.17.146.254] (vpn-10-25-4-8.remote.cert.org [10.25.4.8]) by ioannes.indigo.cert.org (8.12.8/8.12.8/2.42.1.1) with ESMTP id j280haED011882; Mon, 7 Mar 2005 19:43:37 -0500 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <9378b4eab7a1e3b402b824a14a7f836b@cert.org> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-938908971" To: ipfix-protocol@net.doit.wisc.edu, ipfix-arch@net.doit.wisc.edu From: Brian Trammell Subject: [ipfix-arch] protocol and architecture terminology nitpick Date: Mon, 7 Mar 2005 18:43:31 -0600 X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.51 on 192.88.209.16 Precedence: bulk Sender: majordomo listserver --Apple-Mail-1-938908971 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I have one terminology nit to pick concerning draft-ietf-ipfix-protocol-08.txt: In section 3, Terminology, "Metering Process", on page 7, I suggest changing: "Input to the process are packet headers observed at an Observation Point and packet treatment at the Observation Point..." to: "Inputs to the process are packet headers and characteristics observed at an Observation Point and packet treatment at the Observation Point..." as the current wording doesn't take into account "IP Traffic Flow" values part 2 on page 6: "2. one or more characteristics of the packet itself" if those characteristics are not, available in or derived from the network, transport, or application layer headers. (The specific application I'm thinking of for shipping more than headers to the Metering Process is first-N-octet payload hashing used in some darkspace sensors to classify worm propagation and scanning attempts.) In fact, Section 14, para 5, on Page 45, implies that payload information beyond the header may be passed forward to the Collecting Process by the Metering Process: "When an Information Element containing end-user payload information is exported, it SHOULD be transmitted to the Collecting Process using a means that secures its contents against eavesdropping." I realize that the coupling between the Observation Point and the Metering Process is an implementation detail outside the scope of the protocol documents; nevertheless, for the sake of consistency, I'd suggest changing the relevant portion of the Terminology definition for Metering Process as above. This suggested change also affects the terminology definition in draft-ietf-ipfix-architecture-06.txt, also in section 3, on page 7 of that document. Regards, Brian -- Brian H. Trammell / MTS, CERT/NetSA / / 412.268.9748 --Apple-Mail-1-938908971 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCLPU34/8LCZ4pwvYRAvmtAKDIeu2RYKpS3ieujCXMKlJ2w4/R/wCeLWIn d4Pq+SEFu9mQokaTtAO2c4w= =/X1a -----END PGP SIGNATURE----- --Apple-Mail-1-938908971-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Mar 7 20:14:19 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03142 for ; Mon, 7 Mar 2005 20:14:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D8TDt-0005n2-00 for ipfix-list@mil.doit.wisc.edu; Mon, 07 Mar 2005 19:09:21 -0600 Received: from franclinus.red.cert.org ([192.88.209.16]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D8Sp1-0005Oz-00; Mon, 07 Mar 2005 18:43:39 -0600 Received: from ioannes.indigo.cert.org (ioannes.indigo.cert.org [10.60.10.57]) by franclinus.red.cert.org (8.12.10/8.12.10/2.13) with ESMTP id j280hbNY031368; Mon, 7 Mar 2005 19:43:37 -0500 Received: from [172.17.146.254] (vpn-10-25-4-8.remote.cert.org [10.25.4.8]) by ioannes.indigo.cert.org (8.12.8/8.12.8/2.42.1.1) with ESMTP id j280haED011882; Mon, 7 Mar 2005 19:43:37 -0500 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <9378b4eab7a1e3b402b824a14a7f836b@cert.org> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-938908971" To: ipfix-protocol@net.doit.wisc.edu, ipfix-arch@net.doit.wisc.edu From: Brian Trammell Subject: [ipfix-protocol] protocol and architecture terminology nitpick Date: Mon, 7 Mar 2005 18:43:31 -0600 X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.51 on 192.88.209.16 Precedence: bulk Sender: majordomo listserver --Apple-Mail-1-938908971 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I have one terminology nit to pick concerning draft-ietf-ipfix-protocol-08.txt: In section 3, Terminology, "Metering Process", on page 7, I suggest changing: "Input to the process are packet headers observed at an Observation Point and packet treatment at the Observation Point..." to: "Inputs to the process are packet headers and characteristics observed at an Observation Point and packet treatment at the Observation Point..." as the current wording doesn't take into account "IP Traffic Flow" values part 2 on page 6: "2. one or more characteristics of the packet itself" if those characteristics are not, available in or derived from the network, transport, or application layer headers. (The specific application I'm thinking of for shipping more than headers to the Metering Process is first-N-octet payload hashing used in some darkspace sensors to classify worm propagation and scanning attempts.) In fact, Section 14, para 5, on Page 45, implies that payload information beyond the header may be passed forward to the Collecting Process by the Metering Process: "When an Information Element containing end-user payload information is exported, it SHOULD be transmitted to the Collecting Process using a means that secures its contents against eavesdropping." I realize that the coupling between the Observation Point and the Metering Process is an implementation detail outside the scope of the protocol documents; nevertheless, for the sake of consistency, I'd suggest changing the relevant portion of the Terminology definition for Metering Process as above. This suggested change also affects the terminology definition in draft-ietf-ipfix-architecture-06.txt, also in section 3, on page 7 of that document. Regards, Brian -- Brian H. Trammell / MTS, CERT/NetSA / / 412.268.9748 --Apple-Mail-1-938908971 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCLPU34/8LCZ4pwvYRAvmtAKDIeu2RYKpS3ieujCXMKlJ2w4/R/wCeLWIn d4Pq+SEFu9mQokaTtAO2c4w= =/X1a -----END PGP SIGNATURE----- --Apple-Mail-1-938908971-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Mar 7 20:34:22 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05014 for ; Mon, 7 Mar 2005 20:34:22 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D8TXq-000646-00 for ipfix-list@mil.doit.wisc.edu; Mon, 07 Mar 2005 19:29:58 -0600 Received: from diotima.switch.ch ([130.59.4.87]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D8TXp-000641-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 07 Mar 2005 19:29:57 -0600 Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.13.3+Sun/8.13.3) with ESMTP id j281Tl4S017433; Tue, 8 Mar 2005 02:29:47 +0100 (CET) Received: (from leinen@localhost) by diotima.switch.ch (8.13.3+Sun/8.13.3/Submit) id j281TiWS017432; Tue, 8 Mar 2005 02:29:44 +0100 (CET) To: Lutz Mark Cc: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] remove chapter 4 from protocol draft X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: <422C3CD8.9020006@fokus.fraunhofer.de> (Lutz Mark's message of "Mon, 07 Mar 2005 12:36:56 +0100") References: <422C3CD8.9020006@fokus.fraunhofer.de> Date: Tue, 08 Mar 2005 02:29:44 +0100 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk Sender: majordomo listserver Lutz Mark writes: > the text from chapter 4 "Criteria for Flow Expiration and Export" > o is related to the implementation of the metering process > and has no direct relation to the IPFIX protocol. > o is already included in the architecture draft > (chapter 6.1.1) > I suggest to remove this chapter from the protocol draft. I agree. -- Simon. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From Eukene@johnbenson.com Tue Mar 8 03:44:43 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28607 for ; Tue, 8 Mar 2005 03:44:43 -0500 (EST) Received: from [61.100.165.214] (helo=johnbenson.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1D8a3M-0003VI-00 for ipfix-list@mil.doit.wisc.edu; Tue, 08 Mar 2005 02:26:56 -0600 From: "Femie Hooper" To: "Rebeka Person" Subject: Re: 77-WXV-Mediccations Date: Tue, 8 Mar 2005 03:58:48 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C52252.422D6F3A" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?61.100.165.214 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C52252.422D6F3A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, brokers could do business, in the face of cut-throat schemes whic Yes, father. know you'll have something. John--to the servitor---see if you well enough when he did think. He had considerable money investe touched by the witnesses in making oath, and to say, Step this city treasurer became interested in it, and the State treasurer. section of the city which was almost as new as that in which Butl hundred thousand dollars which had been placed to his credit by Did any one drive Sissy this mornin'? asked Butler of Aileen, political investigations, and the like. He had many influential Have a nice day. ------=_NextPart_000_001D_01C52252.422D6F3A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello , = Visit our = Pharm-Mail=20 SH0P and save up to 80%.
     
    Vi ra Am en Ci is Le tra,  And
    ag bi al vi  many other!
     
    Have a nice = day.
    ------=_NextPart_000_001D_01C52252.422D6F3A-- From majordomo@mil.doit.wisc.edu Tue Mar 8 08:15:16 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21498 for ; Tue, 8 Mar 2005 08:15:16 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D8eKM-00002T-00 for ipfix-list@mil.doit.wisc.edu; Tue, 08 Mar 2005 07:00:46 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D8eKL-00002L-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 08 Mar 2005 07:00:45 -0600 Received: from [193.175.133.240] (kaitos [193.175.133.240]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j28D0h504843 for ; Tue, 8 Mar 2005 14:00:43 +0100 (MET) Message-ID: <422DA1FA.4020906@fokus.fraunhofer.de> Date: Tue, 08 Mar 2005 14:00:42 +0100 From: Lutz Mark User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] draft-ietf-ipfix-protocol-09.txt available References: <422CDEDE.6040303@cisco.com> In-Reply-To: <422CDEDE.6040303@cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > => This implies that the method called the "one-pass approach" is not > valid anymore because the offset could also be negative. > The following new text was introduced to cover the 2 phases approach I see that the proposed method saves some bytes on the wire, but from an implementors point of view chapter 8 is quite ugly. Keeping the 'one-pass approach' make the implementation a little bit easier. I prefer not to limit the offset to positive values. If there was already a decision not to allow negative offsets we can omit negative offsets via sending these data in a separate message: 8<---------------------------------------------- By default, the IPFIX Message Header... For a Data Set with Data Records requiring microsecond or nanosecond precision, the IPFIX Message Header "Export Time" field SHOULD be calculated so that each time related Information Elements of the Data Records would contain a 32 bit positive offset from the "Export Time" base timestamp. For a Data Set with Data Records requiring microsecond or nanosecond precision, an example of the "Export Time" calculation is the following: The "Export Time" is set to the second portion of the first time related Information Element of the Data Set. Each subsequent Information Elements containing timestamps are translated into offsets. If an offset is negative or does not fit into 32 bit, the relevant Data Record must be exported in a subsequent IPFIX message. The Flow Records time precision will be implied from the Information Element definitions [IPFIX-INFO]. -------------------------------------------------->8 changes: - Flow Record changed to Data Record - allow export of microsecond and nanosecond precision IEs in the same ipfix message - make section more generic via removing terms like flowStartDeltaUsec, flowEndDeltaUsec etc. Best Regards, Lutz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Mar 8 21:24:09 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14252 for ; Tue, 8 Mar 2005 21:24:09 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D8qXr-0002cB-00 for ipfix-list@mil.doit.wisc.edu; Tue, 08 Mar 2005 20:03:31 -0600 Received: from c3p0.cc.swin.edu.au ([136.186.1.30] helo=swin.edu.au) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D8qXq-0002c6-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 08 Mar 2005 20:03:30 -0600 Received: from swin.edu.au (szander.caia.swin.edu.au [136.186.229.100]) by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id NAA930616; Wed, 9 Mar 2005 13:03:24 +1100 (EST) Message-ID: <422E5967.1010107@swin.edu.au> Date: Wed, 09 Mar 2005 13:03:19 +1100 From: Sebastian Zander Organization: Swinburne University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] draft-ietf-ipfix-protocol-09.txt available References: <422CDEDE.6040303@cisco.com> In-Reply-To: <422CDEDE.6040303@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, some comments on the draft up to and including section 10. i hope i have time to read the rest tomorrow... Section 3: "Should there be any apparent discrepancy in definitions between these two documents, the definitions defined in this document take precedence." we must make sure that the same terms have the same defintion in both documents. shouldn't be too difficult. Defintion of Information Element fields and scope fields are both attributes (terminology issue)? Flow Record should be replaced by Data Record (even with the current defintion) Section 3.1: this section needs to be changed anyway. the text should be more concise e.g. "A Template Set is composed of Template Record(s). No Flow or Options Data Record is included." should be replace by "A Template Set contains only Template Record(s) [and no other records]." Section 4: 4.1 seems off topic. 4.2 describes the behaviour of the exporting process and seems relevant for implementers. however, it only uses should instead of SHOULD etc. so is it supposed to be part of the spec or purely informative? in the later case it could be removed, especially if it is in ipfix-arch. Section 5 and 6: why do we need 2 different sections 'Message Format' and 'IPFIX Message Format'? integrate the 2 sections. Section 5: first paragraph below figure B: should be removed because the set ID is defined in a later section. "The format of the Data, Template and Options Template Sets will be discussed later in this document." i would remove that sentence, if you really wanna keep it add 'message header' and the section numbers where the different things are actually specified. "The Exporter MUST code all binary ... remove that sentence because this is explained in detail in section 9. Section 6: Message Header Field Descriptions, Length: 'message Header' -> 'Message Header' Section 6.2, 1st paragraph: ", both the Template Set and the Option Template Set." remove that part of the sentence Section 6.2, 2nd paragraph: "The Field Ids used to identify Information Elements are represented by the Field Type." i propose to replace Field Type by Field Id in the protocol draft. having two terms for the same thing is confusing and field type could be easily confused with the data type (ipfix-info) e.g. "A numeric value that represents the type of the Information Element. Refer to [IPFIX-INFO]." Section 9 also uses type with the meaning of data type. rename to 'Enterprise Bit'. Enterprise Field Type would be a Field Type with the E bit set. Field Length: replace 'bytes' by 'octets'. add: The field length may be smaller than the defintion in ipfix-info if reduced size encoding is used (see section 9.2). Section 6.3.2: simplify and fix the length definition: Total length of the Set in octets including the Set Header, all records and the optional padding. Because an individual Set MAY contain multiple records, the Length value MUST be used to determine the position of the next Set. Section 6.4: heading must be changed to 'Record Formats' "Templates greatly enhance the flexibility of the record format because they allow the Collecting Process to process records without necessarily knowing the interpretation of all the data in the record." 'process' sounds misleading. the record could be received and stored but it can't be really used without knowing the template defintion. "A Template Record MAY exclusively contain IETF defined Information Elements. A Template Record MAY contain Enterprise Specific Information Elements from one or more vendors. A Template Record MAY contain IETF and Enterprise Specific Information Elements." can we make it simpler? A Template Record can contain any combination of IETF and Enterprise Specific Information Elements. "There are no constraints regarding the order the Template ID allocation." ... the order _of_ the ... again, why do we need a separate defintion for template records? an options template with scope field count = 0 is basically a template record so the defintion is redundant. Section 6.4.2.1 can you please clarify if the scope fields are within the same field id space as the information elements. if not where are the scope ids defined? for some of the fields listed i cannot find a definition in ipfix-info e.g. TemplateId. where are these fields defined? Section 6.4.2.2 can we make the 1st paragraph simpler (see above)? Section 8 "contain a 32 positive bit signed microsecond offset". what does that mean? i don't understand why you want to change the meaning of Export Time? sounds like a hack :) why can't Export Time still be the Export Time as defined in section 6 and the micro second offsets are negative offsets (coded as positive integers)? Section 9.1 strings should use the length encoding as specified in section 10. is there an octet/character array type? Cheers, Sebastian Benoit Claise wrote: > Dear all, > > A new version of the IPFIX protocol draft has been compiled. > As we are in last-call, and as we might discuss some of these already > resolved issues this week, allow me to share it with you. > If you haven't started yet reviewing draft-ietf-ipfix-protocol-08.txt, > start with draft-ietf-ipfix-protocol-09.txt as this is much more complete > You can find the draft at > ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-protocol-09.txt > > Here is the list of improvement: > - there were inconsistencies in the packet formats of the previous draft. > For example, the figure H was not exactly a generic format, and not exactly an example. > Thomas Dietz rewrote the full sections 5 and 6. > It now contains generic format + separate examples.25 <#_Toc97709690> > - corrected a typo, reported by Mark Lutz "an Exporting Process MUST NOT > attempt to establish a connection more frequently than once per minute. " > - improved examples: > * there were inconsistencies between hexa and non hexa value > * [IPFIX-INFO] Information Elements ID are now used > * the example now uses the lineCardId: PROTO-38 is closed: > - new section 9.1 specifying the data types encoding. This was missing for time-related based types, for example. > Thanks to Thomas Dietz for writing the text. > - consistence of field versus information elements > - improved abstract by Juergen Quittek > - Corrected the source ID definition: remove Process in "Exporter Process Observation Domain" > - removed ipfixOption in the specific Option Templates > Integration of the changes proposed in my post "Review of the "7. Specific Reporting > Requirements" and of the ipfixOption Information Element" > - the "time" Information Element in the specific Options Templates has been clarified. > - Integration of the changes proposed in my post "some more info regarding the scope in [IPFIX-INFO]" > - Time related Information Element now in sync. with [IPFIX-INFO] > [IPFIX-INFO] specifies: > > 5.6.15 flowStartDeltaUSeconds > Description: The positive time offset of the first packet of this > flow > relative to a base time given in the IPFIX message header. > > 5.6.16 flowEndDeltaUSeconds > Description: The positive time offset of the last packet of this > flow relative > to a base time given in the IPFIX message header. > > => this implies this change in [IPFIX-] (positive keyword was added) > For a Data Set with Flow Records requiring microsecond precision, > the IPFIX Message Header "Export Time" field SHOULD be calculated so > that each Flow Records flowStartDeltaUsec [IPFIX-INFO] and > flowEndDeltaUsec [IPFIX-INFO] would contain a 32 bit positive > microsecond offset from the "Export Time" base timestamp. In which > case, if Flow Records with a different precision are needed > (millisecond or nanosecond), these MUST be sent in different Data > Sets. > > => This implies that the method called the "one-pass approach" is not > valid anymore because the offset could also be negative. > The following new text was introduced to cover the 2 phases approach > > For a Data Set with Flow Records requiring microsecond precision, an > example of the "Export Time" calculation is the following: before > exporting the Flow Records, the Exporting Process takes as "Export Time" > the lowest start time of all the Flow Records to be exported in this > Data Set. The only constraint is that the highest end time of the Flow > Records in that Data Set can not exceed the "Export Time" plus 71 > minutes. If a Flow Record end time exceeds this condition, this Flow > Record must be exported in a subsequent IPFIX Message. > > => next definition also changed (second sentence added): > Export Time > Time in seconds since 0000 UTC 1970, at which the IPFIX > Message Header leaves the Exporter. Alternatevily, the > Export Time can be a computed value: see the sectin 8 > "IPFIX Message Header "Export Time" and Flow Record Time" > > > > > We are very close to completion, only a few remaining issues: > > PROTO-100: Flow Data Records would become Data Records (consensus on > the mailing so far?) > +------------------+---------------------------------------------+ > | | Contents | > | +--------------------+------------------------+ > | Set | Template | Record | > +------------------+--------------------+------------------------+ > | Data Set | / | Data Record(s) | > +------------------+--------------------+------------------------+ > | Template Set | Template Record(s) | / | > +------------------+--------------------+------------------------+ > | Options Template | Options Template | / | > | Set | Record(s) | | > +------------------+--------------------+------------------------+ > > PROTO-101: Section 9.1.7 dateTimeMicroSeconds -> "Its encoding is > not defined yet." > > PROTO-102: Duplicate chapter "the text from chapter 4 "Criteria for > Flow Expiration and Export" with [IPFIX-ARCH]. Erase this one? > > Regards, Benoit. > > -- Sebastian Zander http://caia.swin.edu.au -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Mar 9 11:58:13 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24999 for ; Wed, 9 Mar 2005 11:58:13 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D94Dw-0007Ng-00 for ipfix-list@mil.doit.wisc.edu; Wed, 09 Mar 2005 10:39:52 -0600 Received: from beniaminus.red.cert.org ([192.88.209.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D94Dv-0007NY-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 09 Mar 2005 10:39:51 -0600 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.12.10/8.12.10/2.13) with ESMTP id j29GdmP6029318 for ; Wed, 9 Mar 2005 11:39:48 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.12.10/8.12.10/Submit/1.1) id j29GdDFp029298 for ; Wed, 9 Mar 2005 11:39:13 -0500 Received: from ioannes.indigo.cert.org (ioannes.indigo.cert.org [10.60.10.57]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id j29GdBP6029296; Wed, 09 Mar 2005 11:39:13 -0500 (EST) Received: from [130.129.135.177] (vpn-10-25-4-5.remote.cert.org [10.25.4.5]) by ioannes.indigo.cert.org (8.12.8/8.12.8/2.42.1.1) with ESMTP id j29GdAED029317; Wed, 9 Mar 2005 11:39:10 -0500 In-Reply-To: <422DA1FA.4020906@fokus.fraunhofer.de> References: <422CDEDE.6040303@cisco.com> <422DA1FA.4020906@fokus.fraunhofer.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4--1064835872" Message-Id: Content-Transfer-Encoding: 7bit Cc: ipfix-protocol@net.doit.wisc.edu From: Brian Trammell Subject: Re: [ipfix-protocol] draft-ietf-ipfix-protocol-09.txt available Date: Wed, 9 Mar 2005 10:39:10 -0600 To: Lutz Mark X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619.2) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=2.64 X-Scanned-By: MIMEDefang 2.51 on 192.88.209.10 Precedence: bulk Sender: majordomo listserver --Apple-Mail-4--1064835872 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Mar 8, 2005, at 7:00 AM, Lutz Mark wrote: > >> => This implies that the method called the "one-pass approach" is not >> valid anymore because the offset could also be negative. The >> following new text was introduced to cover the 2 phases approach > > I see that the proposed method saves some bytes on the wire, > but from an implementors point of view chapter 8 is quite ugly. > > Keeping the 'one-pass approach' make the implementation a little > bit easier. I prefer not to limit the offset to positive values. > > If there was already a decision not to allow negative offsets > we can omit negative offsets via sending these data in a separate > message: As I read ipfix-info, we can't do negative offsets because we don't have signed integers. In addition, negative offsets complicate the implementation of analysis systems that index incoming ipfix streams by message export time (you're still doing two passes, you're just shifting the second pass over to the analysis application). However, the separate message solution seems like a good compromise... Regards, Brian -- Brian H. Trammell / MTS, CERT/NetSA / / 412.268.9748 --Apple-Mail-4--1064835872 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCLyau4/8LCZ4pwvYRAhq7AKCJTqvCypIxt0TEIbFlkwPh1/lEGQCeNEF+ vWWTqMsEYxNaVmY+/6Ldcsw= =+aTv -----END PGP SIGNATURE----- --Apple-Mail-4--1064835872-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Mar 9 12:47:51 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00983 for ; Wed, 9 Mar 2005 12:47:51 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D958M-0000Vn-00 for ipfix-list@mil.doit.wisc.edu; Wed, 09 Mar 2005 11:38:10 -0600 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D958L-0000Vi-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 09 Mar 2005 11:38:09 -0600 Received: from localhost (unknown [130.129.67.221]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 1D0DD1BAC4D; Wed, 9 Mar 2005 18:38:07 +0100 (CET) Date: Wed, 09 Mar 2005 18:38:05 +0100 From: Juergen Quittek To: Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] draft-ietf-ipfix-info-07-pre.txt available Message-ID: <5F921BD0CED52A9443FB1DC0@localhost> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, Please also find an improved version of the IPFIX data model at . I will post a list of changes compared to the previous version later today. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 3/8/05 12:08 AM +0100 Benoit Claise wrote: > Dear all, > > A new version of the IPFIX protocol draft has been compiled. > As we are in last-call, and as we might discuss some of these already resolved issues this week, allow me to share it with you. > If you haven't started yet reviewing draft-ietf-ipfix-protocol-08.txt, start with draft-ietf-ipfix-protocol-09.txt as this is much more complete > You can find the draft at ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-protocol-09.txt > > Here is the list of improvement: [...] -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Mar 9 15:43:53 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18789 for ; Wed, 9 Mar 2005 15:43:53 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D97wc-0003C0-00 for ipfix-list@mil.doit.wisc.edu; Wed, 09 Mar 2005 14:38:14 -0600 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D97wb-0003Bu-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 09 Mar 2005 14:38:13 -0600 Received: from localhost (unknown [130.129.67.221]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B2C8C1BAC4D; Wed, 9 Mar 2005 21:38:11 +0100 (CET) Date: Wed, 09 Mar 2005 21:38:09 +0100 From: Juergen Quittek To: Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] draft-ietf-ipfix-info-07-pre.txt available Message-ID: In-Reply-To: <5F921BD0CED52A9443FB1DC0@localhost> References: <5F921BD0CED52A9443FB1DC0@localhost> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, Here is the list of changes applied to the IPFIX info model since version -05. Below also find the list of still open issues. Changes from version -05 to -07-pre: ==================================== - Terminology compliant to protocol document - Added section 2.2 Scope of Information Elements - added section 2.3 Naming Conventions for Information Elements - added data type 'macAddress' to section 3.1 - Made introduction of section 4 on Information Element identifiers compliant to protocol document - added new section 5.9 on Component Identifiers - completed all old 'to be cone' issues in the text (and added three new ones) - solved all 'Editor's notes' - added several Information Elements: - sourceMacAddress - postDestinationMacAddr - vlanId - postVlanId - destinationMacAddress - postSourceMacAddress - fragmentOffsetIpV4 - lineCardId - flowStartDeltaUSeconds - flowEndDeltaUSeconds - portId - meteringProcessId - exportingProcessId - sourceId - flowId - templateId - wlanChannelId - wlanSsid - flowStartDeltaUSeconds - flowEndDeltaUSeconds - flowStartMilliSeconds - flowEndMilliMSeconds - flowStartMicroSeconds - flowEndMicroSeconds - flowStartNanoSeconds - flowEndNanoSeconds - postClassOfServiceIpV6 List of open issues in version -07-pre: ======================================= Issues that need discussion: o time base for relative time stamps We have time stamp elements that specify the absolute time and time stamp elements that specify an offset to the time given in the IPFIX message header. Currently, the time offset is of type unsigned. This implies that the base time in the IPFIX header must be older than or equal to the earliest flow start time stamp contained in the message. Is this the right way to go? o Do we need an Information Element "flowDuration" ? o Shall we have more 'post-' Information Elements for middleboxes? Editorial issues: o Add reference for USASCII in section 3.1.9 o Is GMT the right time base for absolute time types? (sections 3.1.10- 3.1.13) o Add and update references section. Include - RFC768, RFC791 RFC792, RFC793, RFC1771, RFC1930, - RFC2236, RFC2402, RFC2406, RFC2460, RFC2463, RFC2863, - RFC2960, RFC3032 - 8802-3:2000 ISO/IEC Information Technology - LAN/MAN - IEEE Std 802.1Q - 802.11: SSID, channel no. o Add description to wlanSsid o Add Information Elements for specific reporting requirements (IPFIX-PROTO, section 7: - Metering Process Statistics - Metering Process Reliability Statistics - Exporting Process Reliability Statistics - Flow Keys Thanks, Juergen --On 3/9/05 6:38 PM +0100 Juergen Quittek wrote: > Dear all, > > Please also find an improved version of the IPFIX data model at > > . > > I will post a list of changes compared to the previous version later today. > > Thanks, > > Juergen > -- > Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de > > > --On 3/8/05 12:08 AM +0100 Benoit Claise wrote: > >> Dear all, >> >> A new version of the IPFIX protocol draft has been compiled. >> As we are in last-call, and as we might discuss some of these already resolved issues this week, allow me to share it with you. >> If you haven't started yet reviewing draft-ietf-ipfix-protocol-08.txt, start with draft-ietf-ipfix-protocol-09.txt as this is much more complete >> You can find the draft at ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-protocol-09.txt >> >> Here is the list of improvement: > [...] > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Mar 9 15:45:41 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18877 for ; Wed, 9 Mar 2005 15:45:41 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D97yy-0003EG-00 for ipfix-list@mil.doit.wisc.edu; Wed, 09 Mar 2005 14:40:40 -0600 Received: from diotima.switch.ch ([130.59.4.87]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D97yx-0003E9-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 09 Mar 2005 14:40:39 -0600 Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.13.3+Sun/8.13.3) with ESMTP id j29KeOaY024110; Wed, 9 Mar 2005 21:40:25 +0100 (CET) Received: (from leinen@localhost) by diotima.switch.ch (8.13.3+Sun/8.13.3/Submit) id j29KeOFj024109; Wed, 9 Mar 2005 21:40:24 +0100 (CET) To: Lutz Mark Cc: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] draft-ietf-ipfix-protocol-09.txt available X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: <422DA1FA.4020906@fokus.fraunhofer.de> (Lutz Mark's message of "Tue, 08 Mar 2005 14:00:42 +0100") References: <422CDEDE.6040303@cisco.com> <422DA1FA.4020906@fokus.fraunhofer.de> Date: Wed, 09 Mar 2005 21:40:23 +0100 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk Sender: majordomo listserver Lutz Mark writes: [Benoit had written:] >> => This implies that the method called the "one-pass approach" is >> not valid anymore because the offset could also be negative. A one-pass approach is possible even if you mandate non-negative relative timestamps, as long as you don't (as -09 unfortunately does) mandate that the base time in the message header is EQUAL TO the minimum of the (flow start) timestamps over all data records in the message. When the exporter starts a new IPFIX message (i.e. the first flow is queued for export in a fresh message, it can set the base time by estimating the lower bound for the oldest timestamp that can still be in present in the flow cache. In practice, it is easy to compute a good and safe estimate for this based on flow expiry configuration. Alternatively, you can derive the base timestamp if you can estimate the HIGHEST timestamp that may occur in the new message, for example by limiting the time between starting a new message and exporting it. You can then simply use that maximum time minus the ~71 minutes (2*32 microseconds) as your base timestamp. >> The following new text was introduced to cover the 2 phases >> approach > I see that the proposed method saves some bytes on the wire, > but from an implementors point of view chapter 8 is quite ugly. > Keeping the 'one-pass approach' make the implementation a little > bit easier. I prefer not to limit the offset to positive values. As I said, I claim you can have both (one-pass implementation and only non-negative relative timestamps). So I don't think what you propose is useful. Note that I cannot relate to the application of relative timestamps for nanosecond resolution, as you'd only have a window of four seconds (2*32 nanoseconds) for all the timestamps in a message in that case. Regards, -- Simon. > If there was already a decision not to allow negative offsets > we can omit negative offsets via sending these data in a separate > message: > 8<---------------------------------------------- > By default, the IPFIX Message Header... > For a Data Set with Data Records requiring microsecond or > nanosecond precision, the IPFIX Message Header "Export Time" > field SHOULD be calculated so that each time related Information > Elements of the Data Records would contain a 32 bit positive > offset from the "Export Time" base timestamp. > For a Data Set with Data Records requiring microsecond or > nanosecond precision, an example of the "Export Time" calculation > is the following: The "Export Time" is set to the second > portion of the first time related Information Element of the > Data Set. Each subsequent Information Elements containing > timestamps are translated into offsets. If an offset > is negative or does not fit into 32 bit, the relevant Data > Record must be exported in a subsequent IPFIX message. > The Flow Records time precision will be implied from the Information > Element definitions [IPFIX-INFO]. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Mar 9 16:20:42 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21363 for ; Wed, 9 Mar 2005 16:20:42 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D98Vo-0003mG-00 for ipfix-list@mil.doit.wisc.edu; Wed, 09 Mar 2005 15:14:36 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D98Vn-0003mA-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 09 Mar 2005 15:14:35 -0600 Received: from [192.168.113.33] (dsl-084-059-050-116.arcor-ip.net [84.59.50.116]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j29LEWa20194 for ; Wed, 9 Mar 2005 22:14:32 +0100 (MET) Message-ID: <422F6768.6040106@fokus.fraunhofer.de> Date: Wed, 09 Mar 2005 22:15:20 +0100 From: Lutz Mark User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] draft-ietf-ipfix-protocol-09.txt available References: <422CDEDE.6040303@cisco.com> <422DA1FA.4020906@fokus.fraunhofer.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Simon, > A one-pass approach is possible even if you mandate non-negative > relative timestamps, as long as you don't (as -09 unfortunately does) > mandate that the base time in the message header is EQUAL TO the > minimum of the (flow start) timestamps over all data records in the > message. > > When the exporter starts a new IPFIX message (i.e. the first flow is > queued for export in a fresh message, it can set the base time by > estimating the lower bound for the oldest timestamp that can still be > in present in the flow cache. In practice, it is easy to compute a > good and safe estimate for this based on flow expiry configuration. > > Alternatively, you can derive the base timestamp if you can estimate > the HIGHEST timestamp that may occur in the new message, for example > by limiting the time between starting a new message and exporting it. > You can then simply use that maximum time minus the ~71 minutes (2*32 > microseconds) as your base timestamp. nice idea, in this case you are right. But I have an exporting process in mind, which is separated from the metering process and which has no access to any data (like queues or flow timestamps) of the metering process. Especially your method does not work if we want to allow the export of non-flow data via IPFIX. Best regards, Lutz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Mar 9 20:28:53 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12971 for ; Wed, 9 Mar 2005 20:28:53 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D9CLy-0007Ft-00 for ipfix-list@mil.doit.wisc.edu; Wed, 09 Mar 2005 19:20:42 -0600 Received: from c3p0.cc.swin.edu.au ([136.186.1.30] helo=swin.edu.au) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D9CLw-0007Fl-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 09 Mar 2005 19:20:40 -0600 Received: from swin.edu.au (szander.caia.swin.edu.au [136.186.229.100]) by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id MAA609720; Thu, 10 Mar 2005 12:20:29 +1100 (EST) Message-ID: <422FA0DC.3080002@swin.edu.au> Date: Thu, 10 Mar 2005 12:20:28 +1100 From: Sebastian Zander Organization: Swinburne University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] draft-ietf-ipfix-protocol-09.txt available References: <422CDEDE.6040303@cisco.com> In-Reply-To: <422CDEDE.6040303@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, more comments: Section 11: "The Template Withdraw Message MUST not be sent until sufficient time has elapsed to allow the Collecting Process to receive and process the last data record using this Template information." "The Template ID from a withdrawn Template MUST NOT be reused until sufficient time has elapsed to allow for the Collecting Process to receive and process the Template withdraw message." how would an exporter be able to estimate this especially if different exporters export to the same collector? any recommendations for implementors? Figure T: from the text I understand that the message can contain multiple