From Fernando@javaneers.com Sat Feb 5 04:01:23 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 EAA13527 for ; Sat, 5 Feb 2005 04:01:22 -0500 (EST) Received: from alg130.internetdsl.tpnet.pl ([83.17.36.130] helo=javaneers.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1CxLWK-0002HG-00 for ipfix-list@mil.doit.wisc.edu; Sat, 05 Feb 2005 02:42:24 -0600 From: "Harkaitz Pagan" To: "Javier Tripp" Subject: Good Ppharmacy for you Date: Sat, 5 Feb 2005 03:49:39 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_0C4913B4.0127899D" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?83.17.36.130 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0008_0C4913B4.0127899D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable father would be glad to see him make thirty dollars. He only wanted to borrow the for a day. "What's the trouble, Frank?" asked his father, looking up from hi. desk when he appeared, breathless and red faced. "I want you to loan me thirty-two dollars! Will you?". "Why, yes, I might. What do you want to do with it?" "I want to buy some soap--seven boxes of Castile soap. I know Have a nice day! ------=_NextPart_000_0008_0C4913B4.0127899D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello, Welcome to Health = Suite!
 
Vi ra  al Xa x  cod
ag Ci is  na Vi in
 
And many other at http://www.overmantel/
 
Save Yourself a Huge 70% Off = All 0rders With us.
Have a nice = day!
 
NCPA (National = Community=20 Pharmacists Association)=20 Sertified.
------=_NextPart_000_0008_0C4913B4.0127899D-- From Keiko@kernsmfg.com Sun Feb 6 12:14:08 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 MAA09576 for ; Sun, 6 Feb 2005 12:14:08 -0500 (EST) Received: from [220.64.98.209] (helo=kernsmfg.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1CxpgQ-0000md-00 for ipfix-list@mil.doit.wisc.edu; Sun, 06 Feb 2005 10:54:51 -0600 From: "Elfrieda Schaefer" To: "Heddwyn Walsh" Subject: Great Pharmmacy to you Date: Sun, 6 Feb 2005 11:55:41 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_05661BDA.63632D12" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0008_05661BDA.63632D12 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable relate to her duty to God and the Church and her family and her. mother and him. She realized that all these were important in their way; but Cowperwood and his point of view had given her. another outlook on life. They had discussed this matter of families--parents, children, husbands, wives, brothers, sisters--. from almost every point of view. Cowperwood's laissez-faire attitude had permeated and colored her mind completely. She saw Have a nice day! ------=_NextPart_000_0008_05661BDA.63632D12 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello, Welcome to Health = Suite!
 
Vi ra  al Xa x  cod
ag Ci is  na Vi in
 
And many other at http://www.rectal/
 
Save Yourself a Huge 70% Off = All 0rders With us.
Have a nice = day!
 
NCPA (National = Community=20 Pharmacists Association)=20 Sertified.
------=_NextPart_000_0008_05661BDA.63632D12-- From Irmgard@keywestirish.com Tue Feb 8 16:47:30 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 QAA01053 for ; Tue, 8 Feb 2005 16:47:28 -0500 (EST) Received: from ool-182c7d06.dyn.optonline.net ([24.44.125.6] helo=keywestirish.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1CycuE-00054c-00 for ipfix-list@mil.doit.wisc.edu; Tue, 08 Feb 2005 15:28:22 -0600 From: "Jacobo Humphries" To: "Rebeka Mayer" Subject: Great Pharmmacy you can trust Date: Tue, 8 Feb 2005 16:27:29 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_06510199.B2931B9C" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-RBL-Warning: (dnsbl.njabl.org) Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0004_06510199.B2931B9C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Name?" asked the bailiff, for the benefit of the court stenograp. "Frank Algernon Cowperwood." "Residence?". "1937 Girard Avenue." "Occupation?". "Banker and broker." Steger stood close beside him, very dignified, very forceful, rea. Have a nice day! ------=_NextPart_000_0004_06510199.B2931B9C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello, welcome to Health Suite http://www.vox/=
 
Vi ra  al Xa x  cod
ag Ci is  na Vi in
and many other for very good = pricess!
 
Save yourself up to 70% 0ff All Orders = with=20 us.
 
Have a nice = day.
------=_NextPart_000_0004_06510199.B2931B9C-- From Jocelyn@fugar.com Thu Feb 10 22:25: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 WAA23562 for ; Thu, 10 Feb 2005 22:25:57 -0500 (EST) Received: from [61.103.106.21] (helo=fugar.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1CzQw8-0000W3-00 for ipfix-list@mil.doit.wisc.edu; Thu, 10 Feb 2005 20:53:40 -0600 From: "Faruq Vernon" To: "Asherah Thao" Subject: Valuable Phaarrmacy Date: Thu, 10 Feb 2005 21:21:30 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_0485088A.9BD94C87" 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.103.106.21 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0002_0485088A.9BD94C87 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Welcome to the best online ST0RE With each purchase you get: >Top quality medicationn. >Low prices. >Reputable manufacturers. >Secure pay system. >Discreet packaging. >Home delivery. >Total confidentiality. >24 toll-free customer service hotline. Have a nice day. ------=_NextPart_000_0002_0485088A.9BD94C87 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello,  Welcome = to the best=20 online ST0RE
 
Vi ra  al Xa x  cod
ag (109$ / 30p) = Ci is (324$ /=20 90p)  na (299$ / 90p) = Vi in (178$ /=20 90p)
 
With each purchase you get:
 
>Top quality medicationn.
>Low=20 prices.
>Reputable manufacturers.
>Secure pay=20 system.
>Discreet packaging.
>Home delivery.
>Total=20 confidentiality.
>24 toll-free customer service = hotline.
 
Have a nice day.
------=_NextPart_000_0002_0485088A.9BD94C87-- From majordomo@mil.doit.wisc.edu Mon Feb 14 12:47:08 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 MAA26494 for ; Mon, 14 Feb 2005 12:47:08 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D0k29-0002Cw-00 for ipfix-list@mil.doit.wisc.edu; Mon, 14 Feb 2005 11:29:17 -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 1D0k28-0002Cq-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 14 Feb 2005 11:29:16 -0600 Received: from [10.59.24.6] ([10.59.24.6]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id j1EHTC108291 for ; Mon, 14 Feb 2005 18:29:13 +0100 (CET) Message-ID: <4210D33D.6020703@cisco.com> Date: Mon, 14 Feb 2005 17:35: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] PROTO-48: sequence number improvement - any objection? Content-Type: multipart/alternative; boundary="------------060606010504030504080606" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------060606010504030504080606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Regarding this open issue in the IPFIX protocol draft, I'm wondering if someone objects this proposal. PROTO-48: Should the "sequence number" be improved to contains the number of flow records, like proposed in http://ipfix.doit.wisc.edu/archive/2587.html? If someone does, this is the right time to discuss it! Otherwise, it will change in the next version of the draft. Regards, Benoit. --------------060606010504030504080606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Regarding this open issue in the IPFIX protocol draft, I'm wondering if someone objects this proposal.

PROTO-48: Should the "sequence number" be improved to contains the number of flow records, like proposed in http://ipfix.doit.wisc.edu/archive/2587.html?

If someone does, this is the right time to discuss it!
Otherwise, it will change in the next version of the draft.

Regards, Benoit.
--------------060606010504030504080606-- -- 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 Feb 14 12:58: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 MAA27524 for ; Mon, 14 Feb 2005 12:58:43 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D0k24-0002Co-00 for ipfix-list@mil.doit.wisc.edu; Mon, 14 Feb 2005 11:29:12 -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 1D0k23-0002Cj-00 for ipfix@net.doit.wisc.edu; Mon, 14 Feb 2005 11:29:11 -0600 Received: from [10.59.24.6] ([10.59.24.6]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id j1EHT9108240 for ; Mon, 14 Feb 2005 18:29:10 +0100 (CET) Message-ID: <4210D2B6.9060505@cisco.com> Date: Mon, 14 Feb 2005 17:32:54 +0100 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix Subject: [ipfix] UDP, TCP, and SCTP port request with IANA Content-Type: multipart/alternative; boundary="------------060404080102080003060008" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------060404080102080003060008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dave, Nevil, I will posting a new version of the IPFIX protocol draft before the deadline. PROTO-44: UDP, TCP, and SCTP ports XXXX should be replaced once assigned by IANA. Proposal: 4739 I'm wondering if we have already started the process to request the ports with IANA? Regards, Benoit. --------------060404080102080003060008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dave, Nevil,

I will posting a new version of the IPFIX protocol draft before the deadline.

PROTO-44: UDP, TCP, and SCTP ports XXXX should be replaced once assigned by IANA. Proposal: 4739

I'm wondering if we have already started the process to request the ports with IANA?

Regards, Benoit.
--------------060404080102080003060008-- -- 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 Feb 15 04:37:07 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 EAA10236 for ; Tue, 15 Feb 2005 04:37:07 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D0ylK-0000yj-00 for ipfix-list@mil.doit.wisc.edu; Tue, 15 Feb 2005 03:12:54 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D0ylJ-0000ye-00 for ipfix@net.doit.wisc.edu; Tue, 15 Feb 2005 03:12:53 -0600 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 15 Feb 2005 10:27:02 +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 j1F9Cnlu013826; Tue, 15 Feb 2005 10:12:49 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp448.cisco.com [10.61.65.192]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA05697; Tue, 15 Feb 2005 09:12:47 GMT Message-ID: <4211BD0F.7010504@cisco.com> Date: Tue, 15 Feb 2005 09:12:47 +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: ipfix Subject: Re: [ipfix] UDP, TCP, and SCTP port request with IANA References: <4210D2B6.9060505@cisco.com> In-Reply-To: <4210D2B6.9060505@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: > Dave, Nevil, > > I will posting a new version of the IPFIX protocol draft before the > deadline. > > PROTO-44: UDP, TCP, and SCTP ports XXXX should be replaced once assigned > by IANA. Proposal: 4739 > > I'm wondering if we have already started the process to request the > ports with IANA? > Doesn't this normally happen as part of the RFC production process - which is why you have an IANA section. Stewart > 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 Tue Feb 15 12:58: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 MAA28810 for ; Tue, 15 Feb 2005 12:58:44 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D16nU-0000U5-00 for ipfix-list@mil.doit.wisc.edu; Tue, 15 Feb 2005 11:47:40 -0600 Received: from mailhub2.lawrence.edu ([143.44.65.114] helo=lawrence.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D16nT-0000Tz-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 15 Feb 2005 11:47:39 -0600 Received: from [143.44.97.19] (account lower HELO lawrence.edu) by lawrence.edu (CommuniGate Pro SMTP 4.2.7) with ESMTP id 8562976; Tue, 15 Feb 2005 11:47:38 -0600 Message-ID: <4212368F.5050209@lawrence.edu> Date: Tue, 15 Feb 2005 11:51:11 -0600 From: Robert Lowe Organization: Lawrence 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] PROTO-48: sequence number improvement - any objection? References: <4210D33D.6020703@cisco.com> In-Reply-To: <4210D33D.6020703@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: Benoit, > Regarding this open issue in the IPFIX protocol draft, I'm wondering if > someone objects this proposal. > > PROTO-48: Should the "sequence number" be improved to contains the > number of flow records, like proposed in > http://ipfix.doit.wisc.edu/archive/2587.html? > > If someone does, this is the right time to discuss it! > Otherwise, it will change in the next version of the draft. The idea is nice, but what does it really do? If an IPFIX message contains sets other than data sets (some of which may be periodically resent, and thus not permanently lost), then what do you know about how much has been permanently lost? I assume this is only for detection and notification that data has really been lost. Or are you suggesting that since the ratio of non-data sets to data sets is so low as to make that distinction unimportant, and this is just a simple measure of congestion and/or reliability of the transport? -Robert -- 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 Feb 17 09:17: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 JAA26933 for ; Thu, 17 Feb 2005 09:17:50 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D1m6Z-00028C-00 for ipfix-list@mil.doit.wisc.edu; Thu, 17 Feb 2005 07:54:07 -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 1D1m6Y-000286-00 for ipfix@net.doit.wisc.edu; Thu, 17 Feb 2005 07:54:06 -0600 Received: from [144.254.81.111] (dhcp-pret-user-81-111.cisco.com [144.254.81.111]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id j1HDs2122428; Thu, 17 Feb 2005 14:54:02 +0100 (CET) Message-ID: <4214A1F8.3010406@cisco.com> Date: Thu, 17 Feb 2005 14:54:00 +0100 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Ji CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] one comment about draft-ietf-ipfix-info-05.txt References: <41F9E6D7.7090406@informatik.uni-erlangen.de> <41FA88AF.1060702@yahoo-inc.com> In-Reply-To: <41FA88AF.1060702@yahoo-inc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Eric, And what if you have a collector (receiver) that calculates the prefix and wants to export the information? Sometimes, redundant fields are interesting! Regards, Benoit. > I subscribed this list only weeks ago, so there may be info I missed. > There are two header fields sourceIPv4Prefix, destinationIPv4Prefix, > I think may need be removed. As a general rule, we should not define > redundant fields in protocol packet. Now that we have the address > and mask, it's up to the receiver to calculate the prefix if needed. > > Regards, > Eric > > -- > 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 Feb 18 04:40:27 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 EAA10388 for ; Fri, 18 Feb 2005 04:40:27 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D24FK-00017L-00 for ipfix-list@mil.doit.wisc.edu; Fri, 18 Feb 2005 03:16:22 -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 1D24FJ-00017G-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 18 Feb 2005 03:16:21 -0600 Received: from [10.61.66.10] (ams-clip-vpn-dhcp522.cisco.com [10.61.66.10]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id j1I9G2102077; Fri, 18 Feb 2005 10:16:03 +0100 (CET) Message-ID: <42150161.8010004@cisco.com> Date: Thu, 17 Feb 2005 21:41:05 +0100 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Lowe CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] PROTO-48: sequence number improvement - any objection? References: <4210D33D.6020703@cisco.com> <4212368F.5050209@lawrence.edu> In-Reply-To: <4212368F.5050209@lawrence.edu> Content-Type: multipart/alternative; boundary="------------080407090203020504070604" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------080407090203020504070604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Robert, > Benoit Claise wrote: > > Benoit, > >> Regarding this open issue in the IPFIX protocol draft, I'm wondering >> if someone objects this proposal. >> >> PROTO-48: Should the "sequence number" be improved to contains the >> number of flow records, like proposed in >> http://ipfix.doit.wisc.edu/archive/2587.html? >> >> If someone does, this is the right time to discuss it! >> Otherwise, it will change in the next version of the draft. > > > The idea is nice, but what does it really do? If an IPFIX message > contains sets other than data sets (some of which may be periodically > resent, and thus not permanently lost), then what do you know about how > much has been permanently lost? I assume this is only for detection > and notification that data has really been lost. Or are you suggesting > that since the ratio of non-data sets to data sets is so low as to make > that distinction unimportant, and this is just a simple measure of > congestion and/or reliability of the transport? First of all, let's say that this improvement is mainly for SCTP, the MUST implement transport protocol Let's however analyze the 3 transport protocols. 1. In case of SCTP, we have in the protocol draft: An Exporting Process MUST request at least two outbound streams per association. The first stream (referred to as stream zero in the rest of this document), is used to send the Template Set and the Options Template Set. Stream zero MUST be fully reliable. Data Sets MUST NOT be sent on stream zero. So we don't have the problem of mixed non-data sets and data sets with SCTP, and retransmission of non-data sets. Creating multiple streams, one for each template ID, would return the number of records per template. BTW, "loss of flow records during the data transfer" is requirement from RFC 3917: 6.3.2. Reliability Loss of flow records during the data transfer from the exporting process to the collecting process must be indicated at the collecting process. This indication must allow the collecting process to gauge the number of flow records lost. 2. TCP is reliable protocol and will keep retransmitting. So, even if we have the issue of "mixed non-data sets and data sets", this is not important! 3. UDP. I think that your comments were mainly about UDP, right? As you observed (as specified in section 13.3.6 of[IPFIX-PROTO], we might have the issue of "mixed non-data sets and data sets" in the same IPFIX Message. Basically, there are 2 different cases: 3.1 We loose one IPFIX Message with "mixed non-data sets and data sets", then the collectors knows from the gap in data records sequence that there is something wrong (at least one IPFIX Message lost). You are right: "since the ratio of non-data sets to data sets is so low as to make that distinction unimportant, and this is just a simple measure of congestion and/or reliability of the transport" 3.2 We loose all the IPFIX Messages that contain the template and options template Set, by a strange coincidence (a kind of payload inspection access-list). This is the only serious case where I see a potential drawback compared to the current situation. However, in both case 3.1 and 3.2, the collector might still monitor the condition of not refreshed templates. >From [IPFIX-PROTO]: Templates not refreshed by the Exporting Process within the timeout are expired at the Collecting Process. If the template is not refreshed by the Exporting Process before that lifetime has expired, the Collecting Process MUST discard the Template, and any current and future associated Flow or Option Data Records. We could complete the sentence "and an alarm MAY be logged" Regards, Benoit. --------------080407090203020504070604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Robert,
Benoit Claise wrote:

Benoit,

Regarding this open issue in the IPFIX protocol draft, I'm wondering if someone objects this proposal.

PROTO-48: Should the "sequence number" be improved to contains the number of flow records, like proposed in http://ipfix.doit.wisc.edu/archive/2587.html?

If someone does, this is the right time to discuss it!
Otherwise, it will change in the next version of the draft.

The idea is nice, but what does it really do? If an IPFIX message
contains sets other than data sets (some of which may be periodically
resent, and thus not permanently lost), then what do you know about how
much has been permanently lost? I assume this is only for detection
and notification that data has really been lost.  Or are you suggesting
that since the ratio of non-data sets to data sets is so low as to make
that distinction unimportant, and this is just a simple measure of
congestion and/or reliability of the transport? 
First of all, let's say that this improvement is mainly for SCTP, the MUST implement transport protocol
Let's however analyze the 3 transport protocols.

1. In case of SCTP, we have in the protocol draft:
An Exporting Process MUST request at least two outbound streams per
association. The first stream (referred to as stream zero in the
rest of this document), is used to send the Template Set and the
Options Template Set. Stream zero MUST be fully reliable. Data
Sets MUST NOT be sent on stream zero. 
So we don't have the problem of mixed non-data sets and data sets with SCTP, and retransmission of non-data sets.
Creating multiple streams, one for each template ID, would return the number of records per template. 

BTW, "loss of flow records during the data transfer" is requirement from RFC 3917:
6.3.2. Reliability

Loss of flow records during the data transfer from the exporting
process to the collecting process must be indicated at the collecting
process. This indication must allow the collecting process to gauge
the number of flow records lost.  
2. TCP is reliable protocol and will keep retransmitting. 
So, even if we have the issue of "mixed non-data sets and data sets", this is not important!

3. UDP. I think that your comments were mainly about UDP, right?
As you observed (as specified in section 13.3.6 of[IPFIX-PROTO], we might have the issue of 
"mixed non-data sets and data sets" in the same IPFIX Message.
Basically, there are 2 different cases:
3.1 We loose one IPFIX Message with "mixed non-data sets and data sets", then the collectors knows 
from the gap in data records sequence that there is something wrong (at least one IPFIX Message lost).
You are right: "since the ratio of non-data sets to data sets is so low as to make
that distinction unimportant, and this is just a simple measure of congestion and/or reliability of the transport"
3.2 We loose all the IPFIX Messages that contain the template and options template Set, by a strange coincidence (a kind of payload inspection access-list).
This is the only serious case where I see a potential drawback compared to the current situation. 

However, in both case 3.1 and 3.2, the collector might still monitor the condition of not refreshed templates.
>From [IPFIX-PROTO]:
Templates not refreshed by the Exporting Process within the timeout are expired at
the Collecting Process. If the template is not refreshed by the
Exporting Process before that lifetime has expired, the Collecting
Process MUST discard the Template, and any current and future
associated Flow or Option Data Records. 
We could complete the sentence "and an alarm MAY be logged"

Regards, Benoit.

--------------080407090203020504070604-- -- 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 Feb 18 17:12: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 RAA06348 for ; Fri, 18 Feb 2005 17:12:53 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D2G3E-0005OY-00 for ipfix-list@mil.doit.wisc.edu; Fri, 18 Feb 2005 15:52:40 -0600 Received: from mailhub2.lawrence.edu ([143.44.65.114] helo=lawrence.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D2G3D-0005OR-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 18 Feb 2005 15:52:39 -0600 Received: from [143.44.97.19] (account lower HELO lawrence.edu) by lawrence.edu (CommuniGate Pro SMTP 4.2.7) with ESMTP id 8628097; Fri, 18 Feb 2005 15:52:34 -0600 Message-ID: <42166470.6050508@lawrence.edu> Date: Fri, 18 Feb 2005 15:56:00 -0600 From: Robert Lowe Organization: Lawrence 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] PROTO-48: sequence number improvement - any objection? References: <4210D33D.6020703@cisco.com> <4212368F.5050209@lawrence.edu> <42150161.8010004@cisco.com> In-Reply-To: <42150161.8010004@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: Hi Benoit, >>> Regarding this open issue in the IPFIX protocol draft, I'm wondering >>> if someone objects this proposal. >>> >>> PROTO-48: Should the "sequence number" be improved to contains the >>> number of flow records, like proposed in >>> http://ipfix.doit.wisc.edu/archive/2587.html? >>> >>> If someone does, this is the right time to discuss it! >>> Otherwise, it will change in the next version of the draft. >> >> >> The idea is nice, but what does it really do? If an IPFIX message >> contains sets other than data sets (some of which may be periodically >> resent, and thus not permanently lost), then what do you know about how >> much has been permanently lost? I assume this is only for detection >> and notification that data has really been lost. Or are you suggesting >> that since the ratio of non-data sets to data sets is so low as to make >> that distinction unimportant, and this is just a simple measure of >> congestion and/or reliability of the transport? > > First of all, let's say that this improvement is mainly for SCTP, the MUST implement transport protocol > Let's however analyze the 3 transport protocols. > > 1. In case of SCTP, we have in the protocol draft: > > An Exporting Process MUST request at least two outbound streams per > association. The first stream (referred to as stream zero in the > rest of this document), is used to send the Template Set and the > Options Template Set. Stream zero MUST be fully reliable. Data > Sets MUST NOT be sent on stream zero. > > So we don't have the problem of mixed non-data sets and data sets with SCTP, and retransmission of non-data sets. > Creating multiple streams, one for each template ID, would return the number of records per template. Yes, and the collecting process would know not only that something is missing, but of what type. > BTW, "loss of flow records during the data transfer" is requirement from RFC 3917: > > 6.3.2. Reliability > > Loss of flow records during the data transfer from the exporting > process to the collecting process must be indicated at the collecting > process. This indication must allow the collecting process to gauge > the number of flow records lost. Perhaps it's a bit unfortunate that the definition of "flow record" is not completely precise in RFC3917, but I infer from the context of [IPFIX-PROTO] that it really means flow data record (or perhaps includes options data record, thereby covering the possibilities for a data set). This now means, in the strictest sense, that this requirement cannot be met with UDP, unless of course, gauge means only an estimate. ;-) Perhaps a caveat is in order? > 2. TCP is reliable protocol and will keep retransmitting. > So, even if we have the issue of "mixed non-data sets and data sets", this is not important! > > 3. UDP. I think that your comments were mainly about UDP, right? Sure, but don't take that to mean anything other than a quest for accuracy in the document. > As you observed (as specified in section 13.3.6 of[IPFIX-PROTO], we might have the issue of > "mixed non-data sets and data sets" in the same IPFIX Message. > Basically, there are 2 different cases: > 3.1 We loose one IPFIX Message with "mixed non-data sets and data sets", then the collectors knows > from the gap in data records sequence that there is something wrong (at least one IPFIX Message lost). > You are right: "since the ratio of non-data sets to data sets is so low as to make > that distinction unimportant, and this is just a simple measure of congestion and/or reliability of the transport" > 3.2 We loose all the IPFIX Messages that contain the template and options template Set, by a strange coincidence (a kind of payload inspection access-list). > This is the only serious case where I see a potential drawback compared to the current situation. > > However, in both case 3.1 and 3.2, the collector might still monitor the condition of not refreshed templates. >>From [IPFIX-PROTO]: > > Templates not refreshed by the Exporting Process within the timeout > are expired at > the Collecting Process. If the template is not refreshed by the > Exporting Process before that lifetime has expired, the Collecting > Process MUST discard the Template, and any current and future > associated Flow or Option Data Records. > > We could complete the sentence "and an alarm MAY be logged" I would agree that something should be added (perhaps stronger than MAY) if all that's necessary for an attacker to force the discarding of flow [data] records is to inhibit the arrival of the template set. -Robert -- 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 Feb 18 18:53: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 SAA25731 for ; Fri, 18 Feb 2005 18:53:26 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D2HqD-0005TT-00 for ipfix-list@mil.doit.wisc.edu; Fri, 18 Feb 2005 17:47:21 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D2HqB-0005TO-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 18 Feb 2005 17:47:20 -0600 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 19 Feb 2005 01:02:35 +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 j1INlFlu010891; Sat, 19 Feb 2005 00:47:15 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp4200.cisco.com [10.61.80.103]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA09068; Fri, 18 Feb 2005 23:47:14 GMT Message-ID: <42167E81.1040602@cisco.com> Date: Fri, 18 Feb 2005 23:47:13 +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: Robert Lowe CC: Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] PROTO-48: sequence number improvement - any objection? References: <4210D33D.6020703@cisco.com> <4212368F.5050209@lawrence.edu> <42150161.8010004@cisco.com> <42166470.6050508@lawrence.edu> In-Reply-To: <42166470.6050508@lawrence.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Robert Lowe wrote: > > > Benoit Claise wrote: > > Hi Benoit, > >>>> Regarding this open issue in the IPFIX protocol draft, I'm wondering >>>> if someone objects this proposal. >>>> >>>> PROTO-48: Should the "sequence number" be improved to contains the >>>> number of flow records, like proposed in >>>> http://ipfix.doit.wisc.edu/archive/2587.html? >>>> >>>> If someone does, this is the right time to discuss it! >>>> Otherwise, it will change in the next version of the draft. >>> >>> >>> >>> The idea is nice, but what does it really do? If an IPFIX message >>> contains sets other than data sets (some of which may be periodically >>> resent, and thus not permanently lost), then what do you know about how >>> much has been permanently lost? I assume this is only for detection >>> and notification that data has really been lost. Or are you suggesting >>> that since the ratio of non-data sets to data sets is so low as to make >>> that distinction unimportant, and this is just a simple measure of >>> congestion and/or reliability of the transport? >> >> >> First of all, let's say that this improvement is mainly for SCTP, the >> MUST implement transport protocol >> Let's however analyze the 3 transport protocols. >> >> 1. In case of SCTP, we have in the protocol draft: >> >> An Exporting Process MUST request at least two outbound streams per >> association. The first stream (referred to as stream zero in the >> rest of this document), is used to send the Template Set and the >> Options Template Set. Stream zero MUST be fully reliable. Data >> Sets MUST NOT be sent on stream zero. >> >> So we don't have the problem of mixed non-data sets and data sets with >> SCTP, and retransmission of non-data sets. >> Creating multiple streams, one for each template ID, would return the >> number of records per template. > > > Yes, and the collecting process would know not only that something is > missing, > but of what type. With SCTP the templates are sent over the a reliable channel so they will not get lost, or at least if they do, there will be a transport reset to tell you. > >> BTW, "loss of flow records during the data transfer" is requirement >> from RFC 3917: >> >> 6.3.2. Reliability >> >> Loss of flow records during the data transfer from the exporting >> process to the collecting process must be indicated at the collecting >> process. This indication must allow the collecting process to gauge >> the number of flow records lost. > > > Perhaps it's a bit unfortunate that the definition of "flow record" is not > completely precise in RFC3917, but I infer from the context of > [IPFIX-PROTO] > that it really means flow data record (or perhaps includes options data > record, thereby covering the possibilities for a data set). This now > means, > in the strictest sense, that this requirement cannot be met with UDP, > unless > of course, gauge means only an estimate. ;-) Perhaps a caveat is in > order? Sure, but in the UDP specific section, as this is a UDP specific issue. > >> 2. TCP is reliable protocol and will keep retransmitting. So, even if >> we have the issue of "mixed non-data sets and data sets", this is not >> important! >> >> 3. UDP. I think that your comments were mainly about UDP, right? > > > Sure, but don't take that to mean anything other than a quest for > accuracy in the document. > >> As you observed (as specified in section 13.3.6 of[IPFIX-PROTO], we >> might have the issue of "mixed non-data sets and data sets" in the >> same IPFIX Message. >> Basically, there are 2 different cases: >> 3.1 We loose one IPFIX Message with "mixed non-data sets and data >> sets", then the collectors knows from the gap in data records sequence >> that there is something wrong (at least one IPFIX Message lost). >> You are right: "since the ratio of non-data sets to data sets is so >> low as to make >> that distinction unimportant, and this is just a simple measure of >> congestion and/or reliability of the transport" >> 3.2 We loose all the IPFIX Messages that contain the template and >> options template Set, by a strange coincidence (a kind of payload >> inspection access-list). >> This is the only serious case where I see a potential drawback >> compared to the current situation. >> However, in both case 3.1 and 3.2, the collector might still monitor >> the condition of not refreshed templates. >> >>> From [IPFIX-PROTO]: >> >> >> Templates not refreshed by the Exporting Process within the timeout >> are expired at >> the Collecting Process. If the template is not refreshed by the >> Exporting Process before that lifetime has expired, the Collecting >> Process MUST discard the Template, and any current and future >> associated Flow or Option Data Records. >> >> We could complete the sentence "and an alarm MAY be logged" > > > I would agree that something should be added (perhaps stronger > than MAY) if all that's necessary for an attacker to force the > discarding of flow [data] records is to inhibit the arrival of > the template set. MUST sounds OK. Stewart > > -Robert > > > > -- > 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 Feb 18 19:29:50 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 TAA00899 for ; Fri, 18 Feb 2005 19:29:50 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D2IPr-0006kl-00 for ipfix-list@mil.doit.wisc.edu; Fri, 18 Feb 2005 18:24:11 -0600 Received: from mailhub2.lawrence.edu ([143.44.65.114] helo=lawrence.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1D2IPq-0006kg-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 18 Feb 2005 18:24:10 -0600 Received: from [143.44.97.19] (account lower HELO lawrence.edu) by lawrence.edu (CommuniGate Pro SMTP 4.2.7) with ESMTP id 8629726; Fri, 18 Feb 2005 18:24:09 -0600 Message-ID: <421687F8.6080608@lawrence.edu> Date: Fri, 18 Feb 2005 18:27:36 -0600 From: Robert Lowe Organization: Lawrence 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: Stewart Bryant CC: Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] PROTO-48: sequence number improvement - any objection? References: <4210D33D.6020703@cisco.com> <4212368F.5050209@lawrence.edu> <42150161.8010004@cisco.com> <42166470.6050508@lawrence.edu> <42167E81.1040602@cisco.com> In-Reply-To: <42167E81.1040602@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Stewart Bryant wrote: > > > Robert Lowe wrote: > >> >> >> Benoit Claise wrote: >> >> Hi Benoit, >> >>>>> Regarding this open issue in the IPFIX protocol draft, I'm >>>>> wondering if someone objects this proposal. >>>>> >>>>> PROTO-48: Should the "sequence number" be improved to contains the >>>>> number of flow records, like proposed in >>>>> http://ipfix.doit.wisc.edu/archive/2587.html? >>>>> >>>>> If someone does, this is the right time to discuss it! >>>>> Otherwise, it will change in the next version of the draft. >>>> >>>> >>>> >>>> >>>> The idea is nice, but what does it really do? If an IPFIX message >>>> contains sets other than data sets (some of which may be periodically >>>> resent, and thus not permanently lost), then what do you know about how >>>> much has been permanently lost? I assume this is only for detection >>>> and notification that data has really been lost. Or are you suggesting >>>> that since the ratio of non-data sets to data sets is so low as to make >>>> that distinction unimportant, and this is just a simple measure of >>>> congestion and/or reliability of the transport? >>> >>> >>> >>> First of all, let's say that this improvement is mainly for SCTP, the >>> MUST implement transport protocol >>> Let's however analyze the 3 transport protocols. >>> >>> 1. In case of SCTP, we have in the protocol draft: >>> >>> An Exporting Process MUST request at least two outbound streams per >>> association. The first stream (referred to as stream zero in the >>> rest of this document), is used to send the Template Set and the >>> Options Template Set. Stream zero MUST be fully reliable. Data >>> Sets MUST NOT be sent on stream zero. >>> >>> So we don't have the problem of mixed non-data sets and data sets >>> with SCTP, and retransmission of non-data sets. >>> Creating multiple streams, one for each template ID, would return the >>> number of records per template. >> >> >> >> Yes, and the collecting process would know not only that something is >> missing, >> but of what type. > > > With SCTP the templates are sent over the a reliable channel so they > will not get lost, or at least if they do, there will be a transport > reset to tell you. Yes, but as an added advantage, the sequence number for the non-reliable streams, which are for data sets, takes on more meaning, i.e. N flow data records were lost vs. N records were lost, some of which may have been flow data records. This is good. :-) >>> BTW, "loss of flow records during the data transfer" is requirement >>> from RFC 3917: >>> >>> 6.3.2. Reliability >>> >>> Loss of flow records during the data transfer from the exporting >>> process to the collecting process must be indicated at the >>> collecting >>> process. This indication must allow the collecting process to gauge >>> the number of flow records lost. >> >> >> >> Perhaps it's a bit unfortunate that the definition of "flow record" is >> not >> completely precise in RFC3917, but I infer from the context of >> [IPFIX-PROTO] >> that it really means flow data record (or perhaps includes options data >> record, thereby covering the possibilities for a data set). This now >> means, >> in the strictest sense, that this requirement cannot be met with UDP, >> unless >> of course, gauge means only an estimate. ;-) Perhaps a caveat is in >> order? > > > Sure, but in the UDP specific section, as this is a UDP specific issue. Perfect. >> >>> 2. TCP is reliable protocol and will keep retransmitting. So, even if >>> we have the issue of "mixed non-data sets and data sets", this is not >>> important! >>> >>> 3. UDP. I think that your comments were mainly about UDP, right? >> >> >> >> Sure, but don't take that to mean anything other than a quest for >> accuracy in the document. > > >> >>> As you observed (as specified in section 13.3.6 of[IPFIX-PROTO], we >>> might have the issue of "mixed non-data sets and data sets" in the >>> same IPFIX Message. >>> Basically, there are 2 different cases: >>> 3.1 We loose one IPFIX Message with "mixed non-data sets and data >>> sets", then the collectors knows from the gap in data records >>> sequence that there is something wrong (at least one IPFIX Message >>> lost). >>> You are right: "since the ratio of non-data sets to data sets is so >>> low as to make >>> that distinction unimportant, and this is just a simple measure of >>> congestion and/or reliability of the transport" >>> 3.2 We loose all the IPFIX Messages that contain the template and >>> options template Set, by a strange coincidence (a kind of payload >>> inspection access-list). >>> This is the only serious case where I see a potential drawback >>> compared to the current situation. >>> However, in both case 3.1 and 3.2, the collector might still monitor >>> the condition of not refreshed templates. >>> >>>> From [IPFIX-PROTO]: >>> >>> >>> >>> Templates not refreshed by the Exporting Process within the timeout >>> are expired at >>> the Collecting Process. If the template is not refreshed by the >>> Exporting Process before that lifetime has expired, the Collecting >>> Process MUST discard the Template, and any current and future >>> associated Flow or Option Data Records. >>> >>> We could complete the sentence "and an alarm MAY be logged" >> >> >> >> I would agree that something should be added (perhaps stronger >> than MAY) if all that's necessary for an attacker to force the >> discarding of flow [data] records is to inhibit the arrival of >> the template set. > > > MUST sounds OK. Fine by me. -Robert -- 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 Bran@jentro.com Sat Feb 19 00:41:47 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 AAA29266 for ; Sat, 19 Feb 2005 00:41:46 -0500 (EST) Received: from pcp08553031pcs.northw01.in.comcast.net ([68.57.223.131] helo=jentro.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1D2NAd-0003sq-00 for ipfix-list@mil.doit.wisc.edu; Fri, 18 Feb 2005 23:28:47 -0600 From: "Paulina Omalley" To: "Phaedrus Thorne" Subject: Best Phharmacy you can trust Date: Sat, 19 Feb 2005 00:40:57 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_00EBC0ED.973A172D" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?68.57.223.131 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0004_00EBC0ED.973A172D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Have a nice day. ------=_NextPart_000_0004_00EBC0ED.973A172D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello,  Welcome = to the best=20 online ST0RE
 
Vi ra  al Xa x  cod
ag (109$ / 30p) = Ci is (324$ /=20 90p)  na (299$ / 90p) = Vi in (178$ /=20 90p)
 
With each purchase you get:
 
>Top quality medicationn.
>Low=20 prices.
>Reputable manufacturers.
>Secure pay=20 system.
>Discreet packaging.
>Home delivery.
>Total=20 confidentiality.
>24 toll-free customer service = hotline.
 
Have a nice day.
------=_NextPart_000_0004_00EBC0ED.973A172D-- From Poseidon@jmatas.com Mon Feb 21 01:10: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 BAA27296 for ; Mon, 21 Feb 2005 01:10:37 -0500 (EST) Received: from [61.96.42.205] (helo=jmatas.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1D36TH-0001iC-00 for ipfix-list@mil.doit.wisc.edu; Sun, 20 Feb 2005 23:51:04 -0600 From: "Colene Mercer" To: "Caratacus Norwood" Subject: Giga Pharmmacy you need Date: Mon, 21 Feb 2005 00:50:06 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_003A0642.26DE74E8" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?61.96.42.205 X-RBL-Warning: (dnsbl.njabl.org) open proxy -- 1108038219 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0006_003A0642.26DE74E8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Have a nice day. ------=_NextPart_000_0006_003A0642.26DE74E8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello,  Welcome = to the best=20 online ST0RE
 
Vi ra  al Xa x  cod
ag (109$ / 30p) = Ci is (324$ /=20 90p)  na (299$ / 90p) = Vi in (178$ /=20 90p)
 
With each purchase you get:
 
>Top quality medicationn.
>Low=20 prices.
>Reputable manufacturers.
>Secure pay=20 system.
>Discreet packaging.
>Home delivery.
>Total=20 confidentiality.
>24 toll-free customer service = hotline.
 
Have a nice day.
------=_NextPart_000_0006_003A0642.26DE74E8-- From majordomo@mil.doit.wisc.edu Mon Feb 21 06:39: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 GAA14802 for ; Mon, 21 Feb 2005 06:39:41 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D3Bmx-00032N-00 for ipfix-list@mil.doit.wisc.edu; Mon, 21 Feb 2005 05:31:43 -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 1D3Bmw-00032F-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 21 Feb 2005 05:31:42 -0600 Received: from [10.61.64.193] (ams-clip-vpn-dhcp193.cisco.com [10.61.64.193]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id j1LBVf120946 for ; Mon, 21 Feb 2005 12:31:41 +0100 (CET) Message-ID: <4219C69C.60305@cisco.com> Date: Mon, 21 Feb 2005 12:31:40 +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] New version of ipfix protocol draft posted: draft-ietf-ipfix-protocol-08.txt Content-Type: multipart/alternative; boundary="------------030006000400050101020904" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------030006000400050101020904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is the list of changes. PROTO-23: Finalize the time details. The time-related Information Elements are not defined in [IPFIX-INFO]. We agree that the definition of timer semantics should be moved to the info model document (see the http://ipfix.doit.wisc.edu/archive/2588.html email thread). Now we need: - to insert some new text in the section 9 of this document - to insert the timing Information Element in [IFPIX-INFO] Note: see http://ipfix.doit.wisc.edu/archive/2580.html for a way to improve the timing-related Information Elements. SOLUTION: changed some text in the section 8.0 PROTO-30: review RFC 3917, to see if we miss any requirements SOLUTION: will be part of last-call PROTO-34: Need a security expert to review the security section: - [TBD] in the security section - [EDITOR NOTE: the security section may need be adapted to the revised transport section], [XXX-REFERENCE] - [XXX-SCTP-BLIND-SPOOFING-REFERENCE] not defined - TCP Security 1. Handshake: should we introduce a handshake sequence at the start of the connection? A simple ASCII-based handshake could be used to request TLS. 2. It would make sense to add TLS support even in the absence of a handshake. It would be the responsibility of the collector (connection initiator) to know whether TLS setup is required. SOLUTION: the review by a security expert will be part of last-call PROTO-38: [IPFIX-INFO] consistency issue: - the ipfixOption, time, droppedFUPacketCount, droppedFUByteCount, droppedFlows, keyList, timeFirstFUDropped, timeLastFUDropped, droppedFAPacketCount, droppedFAByteCount, timeFirstFADropped, timeLastFADropped, and Exporter ID, Source ID Information Elements are not used in this document but not yet specified in [IPFIX-INFO]. - Review the Options Template example once the Source ID is defined as an information element (currently the ID 141 is used) SOLUTION: waiting for [IPFIX-INFO] PROTO-44: UDP, TCP, and SCTP ports XXXX should be replaced once assigned by IANA. Proposal: 4739 SOLUTION: the request has been registered to IANA. I added an EDITOR NOTE PROTO-46: TCP section update, waiting text for Simon Leinen. See the thread starting with http://ipfix.doit.wisc.edu/archive/2569.html SOLUTION: done with Simon. As a consequence, Simon is now listed as an author. PROTO-48: Should the "sequence number" be improved to contains the number of flow records, like proposed in http://ipfix.doit.wisc.edu/archive/2587.html? SOLUTION: - New sequence number definition included - the notion of "an alarm MUST be logged" in the section 13.3.7 UDP -> Collecting Process - the notion of IPFIX sequence number for UDP in section 13.3.2 - the notion of IPFIX sequence number for TCP in section 13.4.2.1 So what's left? Editorial changes, waiting for [IPFIX-INFO]. PROTO-38: [IPFIX-INFO] consistency issue: - the ipfixOption, time, droppedFUPacketCount, droppedFUByteCount, droppedFlows, keyList, timeFirstFUDropped, timeLastFUDropped, droppedFAPacketCount, droppedFAByteCount, timeFirstFADropped, timeLastFADropped, and Exporter ID, Source ID Information Elements are not used in this document but not yet specified in [IPFIX-INFO]. - Review the Options Template example once the Source ID is defined as an information element (currently the ID 141 is used) - waiting for [IPFIX-INFO]. Small editorial changes PROTO-47: Some "EDITOR NOTE" in the draft. Regards, Benoit. --------------030006000400050101020904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Here is the list of changes.

PROTO-23: Finalize the time details. The time-related Information Elements are not defined in [IPFIX-INFO]. We agree that the definition of timer semantics should be moved to the info model document (see the http://ipfix.doit.wisc.edu/archive/2588.html email thread). Now we need:
-    to insert some new text in the section 9 of this document
-    to insert the timing Information Element in [IFPIX-INFO]
Note: see http://ipfix.doit.wisc.edu/archive/2580.html for a way to improve the timing-related Information Elements.
SOLUTION: changed some text in the section 8.0

PROTO-30: review RFC 3917, to see if we miss any requirements
SOLUTION: will be part of last-call

PROTO-34: Need a security expert to review the security section:
- [TBD] in the security section
- [EDITOR NOTE: the security section may need be adapted to the revised transport section], [XXX-REFERENCE]
- [XXX-SCTP-BLIND-SPOOFING-REFERENCE] not defined
- TCP Security
1. Handshake: should we introduce a handshake sequence at the start of the connection? A simple ASCII-based handshake could be used to request TLS.
2. It would make sense to add TLS support even in the absence of a handshake. It would be the responsibility of the collector (connection initiator) to know whether TLS setup is required.
SOLUTION: the review by a security expert will be part of last-call

PROTO-38: [IPFIX-INFO] consistency issue:
- the ipfixOption, time, droppedFUPacketCount, droppedFUByteCount, droppedFlows, keyList, timeFirstFUDropped, timeLastFUDropped, droppedFAPacketCount, droppedFAByteCount, timeFirstFADropped, timeLastFADropped, and Exporter ID, Source ID Information Elements are not used in this document but not yet specified in [IPFIX-INFO].
- Review the Options Template example once the Source ID is defined as an information element (currently the ID 141 is used)
SOLUTION: waiting for [IPFIX-INFO]

PROTO-44: UDP, TCP, and SCTP ports XXXX should be replaced once assigned by IANA. Proposal: 4739
SOLUTION: the request has been registered to IANA. I added an EDITOR NOTE

PROTO-46: TCP section update, waiting text for Simon Leinen. See the thread starting with http://ipfix.doit.wisc.edu/archive/2569.html
SOLUTION: done with Simon. As a consequence, Simon is now listed as an author.

PROTO-48: Should the "sequence number" be improved to contains the number of flow records, like proposed in http://ipfix.doit.wisc.edu/archive/2587.html?
SOLUTION:
    - New sequence number definition included
    - the notion of "an alarm MUST be logged" in the section 13.3.7 UDP -> Collecting Process
    - the notion of IPFIX sequence number for UDP in section 13.3.2
    - the notion of IPFIX sequence number for TCP in section 13.4.2.1




So what's left? Editorial changes, waiting for [IPFIX-INFO].
 
   PROTO-38: [IPFIX-INFO] consistency issue:
          - the ipfixOption, time, droppedFUPacketCount,
          droppedFUByteCount, droppedFlows, keyList,
          timeFirstFUDropped, timeLastFUDropped, droppedFAPacketCount,
          droppedFAByteCount, timeFirstFADropped, timeLastFADropped,
          and Exporter ID, Source ID Information Elements are not used
          in this document but not yet specified in [IPFIX-INFO].
          - Review the Options Template example once the Source ID is
          defined as an information element (currently the ID 141 is
          used)
          - waiting for [IPFIX-INFO]. Small editorial changes
   PROTO-47: Some "EDITOR NOTE" in the draft.


Regards, Benoit.

 


--------------030006000400050101020904-- -- 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 Feb 22 04:07:47 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 EAA02524 for ; Tue, 22 Feb 2005 04:07:46 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D3ViV-0005wz-00 for ipfix-list@mil.doit.wisc.edu; Tue, 22 Feb 2005 02:48:27 -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 1D3ViU-0005wu-00 for ipfix@net.doit.wisc.edu; Tue, 22 Feb 2005 02:48:26 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id C383F34378 for ; Tue, 22 Feb 2005 21:48:25 +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 25821-03 for ; Tue, 22 Feb 2005 21:48:25 +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 AB357342CE for ; Tue, 22 Feb 2005 21:48:25 +1300 (NZDT) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id j1M8mPe27092 for ipfix@net.doit.wisc.edu; Tue, 22 Feb 2005 21:48:25 +1300 Received: from port-60-234-192-252.jet.net.nz (port-60-234-192-252.jet.net.nz [60.234.192.252]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Tue, 22 Feb 2005 21:48:25 +1300 Message-ID: <1109062105.30fc0a0d1d88c@webmail.auckland.ac.nz> Date: Tue, 22 Feb 2005 21:48:25 +1300 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] DRAFT 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: 60.234.192.252 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all: 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 draft 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 ezekiel@aacr.net Tue Feb 22 17:06:24 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 RAA28179 for ; Tue, 22 Feb 2005 17:06:18 -0500 (EST) Received: from c-67-184-142-177.client.comcast.net ([67.184.142.177]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1D3hpG-00012V-00 for ipfix-list@mil.doit.wisc.edu; Tue, 22 Feb 2005 15:44:15 -0600 Message-ID: From: "Paul A. Davis" To: ipfix-list@mil.doit.wisc.edu Subject: =?iso-8859-1?B?Q2lhbGlzIC0gdmVyeSBsb3cgcHJpY2U=?= Date: Tue, 22 Feb 2005 21:23:59 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_EEE3E6B7.2C61F2DA" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?67.184.142.177 This is a multi-part message in MIME format. ------=_NextPart_000_0000_EEE3E6B7.2C61F2DA Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_9F50FE4E.67D8BBD9" ------=_NextPart_001_0001_9F50FE4E.67D8BBD9 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Fast & easy erections Long-lasting effects No prescription required 2 popular medicines: Cialis - http://www.kilomed.biz/sv/ Viagra - http://www.kilomed.biz/vt/ Directly from the manufacturer! _________________________________________________________________________ To change your mail preferences, go here: http://www.kilomed.biz/uns.htm _________________________________________________________________________ ------=_NextPart_001_0001_9F50FE4E.67D8BBD9 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit

Stable & hard erections
Long-lasting effects
No prescription needed

2 popular medicines:
CIALIS - http://www.kilomed.biz/sv/
VIAGRA - http://www.kilomed.biz/vt/

Directly from the manufacturer!


_________________________________________________________________________
To change your mail details, go here: http://www.kilomed.biz/uns.htm
_________________________________________________________________________

------=_NextPart_001_0001_9F50FE4E.67D8BBD9-- ------=_NextPart_000_0000_EEE3E6B7.2C61F2DA-- From majordomo@mil.doit.wisc.edu Thu Feb 24 16:29:50 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 QAA23812 for ; Thu, 24 Feb 2005 16:29:50 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D4QIJ-0005up-00 for ipfix-list@mil.doit.wisc.edu; Thu, 24 Feb 2005 15:13:11 -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 1D4QIH-0005uk-00 for ipfix@net.doit.wisc.edu; Thu, 24 Feb 2005 15:13:10 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id A7B4D34DC0 for ; Fri, 25 Feb 2005 10:13:08 +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 17409-10 for ; Fri, 25 Feb 2005 10:13:08 +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 8AC2C34362 for ; Fri, 25 Feb 2005 10:13:08 +1300 (NZDT) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id j1OLD8V26646 for ipfix@net.doit.wisc.edu; Fri, 25 Feb 2005 10:13:08 +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 ; Fri, 25 Feb 2005 10:13:08 +1300 Message-ID: <1109279588.a23eae74a3d26@webmail.auckland.ac.nz> Date: Fri, 25 Feb 2005 10:13:08 +1300 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] WG Last Call - please read our drafts and comment *now* 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: As mentioned in our draft agenda for the Minneapolis IETF meeting, the four IPFIX drafts have all been revised since the DC IETF in November 2004. They are Applicability Statement draft-ietf-ipfix-as-04.txt Architecture draft-ietf-ipfix-architecture-06.txt Protocol draft-ietf-ipfix-protocol-08.txt Information Model draft-ietf-ipfix-info-06.txt All four are available from the IPFIX home page, http://ipfix.doit.wisc.edu/ and/or from the IPFIX WG page on the IETF site, http://www.ietf.org/html.charters/ipfix-charter.html This posting announces the start of a two-week WG Last Call on these four drafts. Please read them, and post your comments to the IPFIX list (ipfix@net.doit.wisc.edu). * If you're happy with, or can at least live with, the drafts as they * are now, please say so - that will help support us when we submit * the drafts to IESG for publication as RFCs. The IPFIX WG has reached a stage when, although we know that people are working on implementations and interoperability, only a few people are actively working on the documents. At the same time we're under increasing pressure from our AD to get the documents finished - other WGs are held up waiting for them. At this stage there are few issues left outstanding, and the draft editors have worked hard to resolve them. By starting the WG Last Call now, we're hoping to bring out any remaining problems in the drafts. Also, given the pressure on us to finish things, it's entirely possible that our session in Minneapolis will be the last IPFIX one at an IETF meeting. Summary: we really do want to get the drafts finished and submitted, we *need* your feedback. Do please read them and post your comments to the ipfix list. It's important for all reviewers to post, regardless of whether or not they open new issues. Cheers, Nevil & Dave (IPFIX co-chairs) ----------------------------------------------------------------------- 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 Feb 27 03:50:23 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 DAA05551 for ; Sun, 27 Feb 2005 03:50:23 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1D5JjJ-00056k-00 for ipfix-list@mil.doit.wisc.edu; Sun, 27 Feb 2005 02:24:45 -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 1D5JjH-00056f-00 for ipfix@net.doit.wisc.edu; Sun, 27 Feb 2005 02:24:44 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 8A93434AD6 for ; Sun, 27 Feb 2005 21:24:42 +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 04629-11 for ; Sun, 27 Feb 2005 21:24:42 +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 6A501349DC for ; Sun, 27 Feb 2005 21:24:42 +1300 (NZDT) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id j1R8Oga02755 for ipfix@net.doit.wisc.edu; Sun, 27 Feb 2005 21:24:42 +1300 Received: from port-60-234-193-98.jet.net.nz (port-60-234-193-98.jet.net.nz [60.234.193.98]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Sun, 27 Feb 2005 21:24:42 +1300 Message-ID: <1109492682.4db6705c6af6a@webmail.auckland.ac.nz> Date: Sun, 27 Feb 2005 21:24:42 +1300 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] Re: WG Last Call - please read our drafts and comment *now* 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: 60.234.193.98 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Forwarded by Nevil from Tal Givoli ........................... Nevil, I believe to the fact that the applicability statement doesn't document any caveats regarding the use of IPFIX for billing or accounting. Despite the fact that IPFIX provides a flexible way to encode a variety of record structures for a variety of services, it couldn't be used for VoIP, telephony calls, e-commerce transactions or ATM transactions, for that matter. One might ask oneself why is this the case? Because the reliability is not at the degree of reliability currently offered by RADIUS, DIAMETER, AMATPS/AMADNS, GTP', IPDR Streaming Protocol, and other protocols. I believe this needs to be clearly denoted and perhaps the applicability statement is where it might be worth mentioning this. This was addressed in the requirement document by including in section 3 the statement: The reliability requirements defined in sections 5.1 and 6.3.2. are not sufficient to guarantee the level of reliability that is needed for many usage-based accounting systems. Particular reliability requirements for accounting systems are discussed in [RFC2975]. Perhaps this needs to be echoed in a similar fashion in section 2.1 of the applicability statement? Tal ----------------------------------------------------------------------- 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/