From majordomo@mil.doit.wisc.edu Wed Feb 01 20:29:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4THP-00078l-V8 for ipfix-archive@megatron.ietf.org; Wed, 01 Feb 2006 20:29:06 -0500 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 UAA10847 for ; Wed, 1 Feb 2006 20:27:15 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F4T32-0001ag-00 for ipfix-list@mil.doit.wisc.edu; Wed, 01 Feb 2006 19:14:08 -0600 Received: from groucho.itss.auckland.ac.nz ([130.216.190.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F4T30-0001ZM-00 for ipfix@net.doit.wisc.edu; Wed, 01 Feb 2006 19:14:06 -0600 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 82DFB34A31 for ; Thu, 2 Feb 2006 14:14:02 +1300 (NZDT) Received: from groucho.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02829-03 for ; Thu, 2 Feb 2006 14:14:02 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 6731C34236 for ; Thu, 2 Feb 2006 14:14:02 +1300 (NZDT) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id k121E2w03460 for ipfix@net.doit.wisc.edu; Thu, 2 Feb 2006 14:14:02 +1300 Received: from nevil-laptop.cs.auckland.ac.nz (nevil-laptop.cs.auckland.ac.nz [130.216.38.130]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Thu, 2 Feb 2006 14:14:01 +1300 Message-ID: <1138842841.e2594a1cd7fa6@webmail.auckland.ac.nz> Date: Thu, 2 Feb 2006 14:14:01 +1300 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] IANA assigns sctp port 4739 to IPFIX 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.38.130 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 received the note below from IANA. Now we have 4739 allocated to IPFIX for sctp, tcp and udp. Cheers, Nevil ----- Forwarded message from iana-ports-usr@icann.org ----- Date: Wed, 1 Feb 2006 16:19:38 -0800 From: iana-ports-usr@icann.org Reply-To: iana-ports-usr@icann.org Subject: RE: Application for port-number: ipfix (Assigned-4739) [I06-050814-0000] To: n.brownlee@auckland.ac.nz Dear Nevil Brownlee, We have assigned the following user port number with you as the point of contact: ipfix 4739/sctp IP Flow Info Export # Nevil Brownlee <n.brownlee@auckland.ac.nz> January 2006 See: <http://www.iana.org/assignments/port-numbers> Please notify the IANA if there is a change in contact information by completing the following template: <http://www.iana.org/cgi-bin/mod_portno.pl> Thank you, Pearl Liang IANA *************************************************************** Internet Assigned Numbers Authority (IANA) 4676 Admiralty Way, Suite 330 Marina del Rey, California 90292 Voice: (310) 823-9358 FAX: (310) 823-8649 email: iana-ports@iana.org *************************************************************** ----- End forwarded message ----- ----------------------------------------------------------------------- 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 Feb 02 05:48:45 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4c16-0003DS-BK for ipfix-archive@megatron.ietf.org; Thu, 02 Feb 2006 05:48:45 -0500 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 FAA20328 for ; Thu, 2 Feb 2006 05:47:05 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F4bgC-0004A9-00 for ipfix-list@mil.doit.wisc.edu; Thu, 02 Feb 2006 04:27:08 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F4bgB-0004A3-00 for ipfix@net.doit.wisc.edu; Thu, 02 Feb 2006 04:27:07 -0600 Received: from EXCHSRV.fokus.fraunhofer.de (einstein [10.147.9.230]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id k12AR5K21647; Thu, 2 Feb 2006 11:27:05 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipfix] IPFIX followup charter Date: Thu, 2 Feb 2006 11:27:15 +0100 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA101D312@EXCHSRV.fokus.fraunhofer.de> Thread-Topic: [ipfix] IPFIX followup charter Thread-Index: AcYmt9iUQWdDA4pEQ/aQSYYqUZgnAQBJ6pvw From: "Tanja Zseby" To: "Juergen Quittek" , Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Hi J=FCrgen and all, I agree that due to the high amount of drafts we need to decide on the = most important ones for the first round. Nevertheless, I think we should = consider to include the bi-flow draft already now in the new charter.=20 The idea for such a draft originated at the last FloCon workshop where a = lot of people had doubts about IPFIX because it currently lacks = information on how to do bi-flow matching/reporting. Many of the = participants have written their own programs in the past to allow = bi-flow analysis from NetFlow data. So as a result of discussions during = the workshop, Brian and Elisa decided to work on such a draft. I agree = that there is not yet very much content in the current version of the = draft but since this request came from a larger community I consider it = as important.=20 Brian, Elisa maybe you can comment on this? Do you share my viewpoint? = How would you prioritize your work in IPFIX (since you are also = co-authors in other drafts)?=20 Best regards, Tanja=20 -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On = Behalf Of Juergen Quittek Sent: Tuesday, January 31, 2006 11:42 PM To: ipfix@net.doit.wisc.edu Subject: [ipfix] IPFIX followup charter Dear all, As you know, the IPFIX working group has completed its charter by = submitting all planned documents (with a delay of several years) to the = IESG for publication as RFC. Also the PSAMP WG will reach this status = soon. Building on the results of these WGs, there are a lot of related ongoing = activities that are producing Internet drafts related to IPFIX. Several = of them have already been presented at recent IPFIX and PSAMP sessions. = But working on them is not covered by the IPFIX or PSAMP charter. If we = want to continue this IPFIX-related work, we need a new charter that = gives it a home at the IETF. The text below lists and discusses related work and suggests a charter = for a follow-up WG. It is the output of several discussions with = Tanja, Benoit, and Nevil. The proposed charter is very short-lived and includes only the three = most mature work items out of a longer list of candidates. The basic = idea is completing this charter within less than a year and then = re-chartering to cover further work items that have progressed until = then. This lean work model with short-lived charters allows the group = to focus on a limited number of issues and is preferable to long-lived = WGs working on many issues in parallel. (It is highly recommended by = the IESG.) Please have a look at it and state whether or not you think it makes = sense to have an IPFIX follow-up WG. Also please read the proposed = charter carefully and express your objections, concerns, comments, = requests for modifications, etc. The plan is to elaborate the new charter proposal on this list and = submit an agreed version to our area directors soon. The deadline for = requesting BoF sessions at the next IETF meeting in Dallas is February = 13. Thanks, Juergen =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Why do we need to continue the work of IPFIX and PSAMP? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D IPFIX has completed its charter and PSAMP will do so very soon. Still, = there are a lot of ongoing activities in the community of these two WGs: 1. Flow aggregation draft-dressler-ipfix-aggregation-01.txt 2. reducing redundancy in IPFIX and PSAMP reports draft-boschi-export-perpktinfo-00.txt 3. IPFIX implementation guidelines draft-boschi-ipfix-implementation-guidelines-00.txt 4. Path-coupled meter configuration draft-fessi-nsis-m-nslp-framework-02.txt draft-dressler-nsis-metering-nslp-03.txt (currently under discussion in the NSIS WG, but not covered by the NSIS charter. It is a candidate work item for NSIS re-chartering, but the NSIS WG asks if it would not be better covered by IPFIX) 5. IPFIX reliability draft-bclaise-ipfix-reliability-00.txt 6. Reporting bi-directional flows with IPFIX draft-boschi-ipfix-biflow-01.txt 7. a format for storing IPFIX records draft-trammell-ipfix-file-00.txt 8. IPFIX MIB module no I-D yet, but two teams working on it independently. 9. Common IPFIX templates draft-stephan-isp-templates-01.txt 10. Reliable server pooling for IPFIX draft-coene-rserpool-applic-ipfix-01.txt 11. Flow sampling draft-molina-flow-selection-00.txt (expired) Did I miss something? 1.-4. and 9. have already been discussed at past IPFIX or PSAMP = sessions. This list shows two things. - There is a community interested in IPFIX that is not too small. - This community and is willing to further work on issues = IPFIX-related issues in the IETF. This is a very good starting point for a charter discussion. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Which work items are suited? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Not all of the issues listed above are at a stage, where they should be = considered as a WG work item, but 1.-4. are quite well developed and 5. and 6. are candidates. Since 4. is a candidate for NSIS re-chartering, = I dropped it from the following considerations. Each of 1.-3. has been presented at IPFIX or PSAMP sessions already two = times with some discussion on the suggested approach. For all I sense = an agreement in the IPFIX WG (at least no objections so far) that these = issues are relevant work and potential WG work items (to be confirmed on = the list, of course). - The flow aggregation work is rather mature. Actually this draft = covers something that is missing in IPFIX: How to tell the collector that = the metering probe does not have the standard (Netflow default) = configuration, but filters and aggregates certain flows. There are some terminology problems and a set of technical issues to = be solved, but there is not problem with the general direction and the = chosen approach. Still, thorough reviews are missing as well as a = discussion on how to fit it well into the IPFIX architecture. - Reducing redundancy in IPFIX and PSAMP reports is an issue that was received very well by both WGs when past versions of the IDs were = presented. It is considered a useful method of applying IPFIX efficiently. Still, the current drafts were considered as to specific. They = apply the optimization to packet reports only. At the last PSAMP meeting = it was noted that the method should be generalized such that it can be = applied to all redundant IPFIX transmissions. This generalization needs to be = done, but the way to go is clear and basically agreed on. - The implementation guidelines are considered the most important work = item by many WG members (including myself). Many people are currently = implementing IPFIX and several recommendations were identified at the first IPFIX = interop (next one is scheduled for end of February). The sooner this = document is available, the more will help improving ongoing implementations. My problem with this item is that the current individual draft is in = a bad shape. Therefore, the milestones for this item are later than for = the others. The two weaker candidates for WG items are IPFIX reliability and = reporting of bidirectional flows. Both have been requested on the IPFIX = mailing list several time in the past years, but we could not agree on = making them part of the basic IPFIX standard. But as add-ons, that integrate well with the standard, they can be = considered, particularly since I heard about operator requests for both = of them. A problem of these issues is that so far they have not been presented at = IPFIX or PSAMP sessions and there has not been a discussion yet on the = approaches followed by the existing drafts. Therefore, these two are = not included in the draft proposal below. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Charter Proposal: Efficient Use of IPFIX (USEIPFIX) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D The IPFIX working group has specified the IPFIX protocol for exporting = flow records. The PSAMP working group has specified the usage of the = IPFIX protocol for exporting packet records. With both specifications = available, several implementers have started building applications using = the IPFIX protocol. At a first interoperability testing event, several IPFIX protocol = implementations were tested. The experiences made at this event were fed = back to IPFIX protocol specification, particularly for removing = ambiguities. In addition, several lessons were learned about how to = implement and use IPFIX correctly and efficiently. The exchange among = different implementers further led to new ideas for advanced usage of = IPFIX. Many of these ideas are currently documented in individual = Internet drafts. The goal of the USEIPFIX working group is producing best current = practice and guideline documents concerning implementation, application = and usage of the IPFIX protocol. Out of scope are modifications of the core IPFIX and PSAMP protocol = specifications. In scope is the definition of new IPFIX and PSAMP = information elements within the documents produced by the USEIPFIX WG. Specific Goals of the USEIPFIX WG are: o Developing guidelines for implementers based on experiences gained individually by implementers and jointly at interoperability testing events. The guidelines will give recommendations for integrating IPFIX observation points, measurement processes, and exporting processes into the packet flow at different kinds of IPFIX devices. They will make suggestions for efficient implementation of the IPFIX protocol features and identify parts of the IPFIX specification that have already been misunderstood by several implementers. For some implementation choices that the protocol specification leaves to the implementer, the guidelines will discuss advantages and disadvantages of the different choices. o Developing methods and means for an efficient use of the IPFIX protocol that reduces redundancy in flow reports. The basic idea to be followed is very simple. For multiple flow records that all report the same value in one or more of the contained IPFIX information elements, these values are removed from the flow records and instead reported once for all in a separate record. Such an approach integrates very well with the IPFIX protocol and only needs few means for expressing the relationship between flow records and corresponding separate records. o Develop a method for flow aggregation reducing the amount of measurement data exchanged between IPFIX exporters and IPFIX collectors. Using aggregation techniques, measurement information of multiple similar flows is aggregated into few meta-flow records. Applied aggregation rules need to be communicate. o Investigate further ways of efficiently using the IPFIX protocols including but not limited to - providing reliability for IPFIX transmissions, - reporting bi-directional flows, - path-coupled configuration of IPFIX devices, - reporting the configuration of IPFIX devices, - flow sampling at IPFIX devices, - storing IPFIX flow records and packet records. These issues are not current work items of the USEIPFIX WG but are evaluated as candidates for potential future work items. Milestones: Mar 2006 Initial version of flow aggregation methods Mar 2006 Initial = version of reducing redundandy in IPFIX records Mar 2006 IPFIX and = PSAMP interoperability testing event (not a real WG milestone?) Apr 2006 = Initial version of implementation guidelines Jul 2006 Submit flow = aggregation methods to IESG Sep 2006 Submit reducing redundancy in = IPFIX records to IESG Sep 2006 Submit implementation guidelines to IESG -- 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 Thu Feb 02 12:54:11 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4iem-0007r5-Rg for ipfix-archive@megatron.ietf.org; Thu, 02 Feb 2006 12:54:11 -0500 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 MAA24306 for ; Thu, 2 Feb 2006 12:52:22 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F4iXY-0002Tk-00 for ipfix-list@mil.doit.wisc.edu; Thu, 02 Feb 2006 11:46:40 -0600 Received: from franclinus.red.cert.org ([192.88.209.16]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F4iXW-0002TR-00 for ipfix@net.doit.wisc.edu; Thu, 02 Feb 2006 11:46:38 -0600 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.16) with ESMTP id k12HkafE030201 for ; Thu, 2 Feb 2006 12:46:36 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k12HkKVK030188 for ; Thu, 2 Feb 2006 12:46:20 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k12HkJQm030186; Thu, 02 Feb 2006 12:46:20 -0500 (EST) Received: from [128.237.244.135] (vpn-10-25-4-16.remote.cert.org [10.25.4.16]) by villemus.indigo.cert.org (8.12.11/8.12.11/2.53) with ESMTP id k12HkJME012622; Thu, 2 Feb 2006 12:46:19 -0500 In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA101D312@EXCHSRV.fokus.fraunhofer.de> References: <804B13F8F3D94A4AB18B9B01ACB68FA101D312@EXCHSRV.fokus.fraunhofer.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4--466098579" Message-Id: Cc: Juergen Quittek , ipfix@net.doit.wisc.edu, Elisa Boschi , Roman Danyliw Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [ipfix] IPFIX followup charter Date: Thu, 2 Feb 2006 12:46:14 -0500 To: Tanja Zseby X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000004 X-Scanned-By: MIMEDefang 2.54 on 192.88.209.16 Precedence: bulk Sender: majordomo listserver This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-4--466098579 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable Tanja, As co-author of the biflow draft, of course I agree with you that it =20 should be included in this charter. There has not been much =20 discussion among the wider group on the biflow draft because there =20 has not been a full working group meeting since the effort was =20 initiated. That said, in one-on-one meetings in Vancouver, we did =20 recieve some very good feedback and are incorporating it into a -02 =20 draft that will be available well before Dallas for discussion. There's not a whole lot of content in -01 (or the forthcoming -02 for =20= that matter) mainly because single-record biflow export is a =20 relatively simple idea with a relatively simple design. I personally =20 don't anticipate that adding the biflow draft to the proposed short-=20 term charter will have a significant impact on the amount of time =20 required to see it to completion. Given that many of us in the security-oriented flow analysis =20 community, where the question "did anyone answer?" often separates =20 mere concern from actionability, consider biflow export support to be =20= quite important, failure to improve upon the relatively inefficient =20 current methods for biflow export in IPFIX may hinder its adoption as =20= anything other than a slightly more complicated NetFlow V9: another =20 data source to read from and translated to one of a number of =20 proprietary collection protocols as near to the sensing edge as =20 possible. Delaying official WG action on this until July 2007, as I =20 believe leaving biflow support off the next charter and allowing for =20 one IETF meeting cycle of slack in the schedule implies, won't help =20 IPFIX adoption within this community. By that time, CERT/NetSA's own =20 biflow export system will have been in production use for a year, =20 albeit with CERT private enterprise IEs standing in for official =20 reverse-direction value fields. It would instead be preferable to continue this work within the =20 working group without delay. Regards, Brian On Feb 2, 2006, at 5:27 AM, Tanja Zseby wrote: > Hi J=FCrgen and all, > > I agree that due to the high amount of drafts we need to decide on =20 > the most important ones for the first round. Nevertheless, I think =20 > we should consider to include the bi-flow draft already now in the =20 > new charter. > The idea for such a draft originated at the last FloCon workshop =20 > where a lot of people had doubts about IPFIX because it currently =20 > lacks information on how to do bi-flow matching/reporting. Many of =20 > the participants have written their own programs in the past to =20 > allow bi-flow analysis from NetFlow data. So as a result of =20 > discussions during the workshop, Brian and Elisa decided to work on =20= > such a draft. I agree that there is not yet very much content in =20 > the current version of the draft but since this request came from a =20= > larger community I consider it as important. > > Brian, Elisa maybe you can comment on this? Do you share my =20 > viewpoint? How would you prioritize your work in IPFIX (since you =20 > are also co-authors in other drafts)? > > Best regards, > Tanja > > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On =20 > Behalf Of Juergen Quittek > Sent: Tuesday, January 31, 2006 11:42 PM > To: ipfix@net.doit.wisc.edu > Subject: [ipfix] IPFIX followup charter > > Dear all, > > As you know, the IPFIX working group has completed its charter by =20 > submitting all planned documents (with a delay of several years) to =20= > the IESG for publication as RFC. Also the PSAMP WG will reach this =20= > status soon. > > Building on the results of these WGs, there are a lot of related =20 > ongoing activities that are producing Internet drafts related to =20 > IPFIX. Several of them have already been presented at recent IPFIX =20= > and PSAMP sessions. But working on them is not covered by the =20 > IPFIX or PSAMP charter. If we want to continue this IPFIX-related =20 > work, we need a new charter that gives it a home at the IETF. > > The text below lists and discusses related work and suggests a =20 > charter for a follow-up WG. It is the output of several =20 > discussions with Tanja, Benoit, and Nevil. > > The proposed charter is very short-lived and includes only the =20 > three most mature work items out of a longer list of candidates. =20 > The basic idea is completing this charter within less than a year =20 > and then re-chartering to cover further work items that have =20 > progressed until then. This lean work model with short-lived =20 > charters allows the group to focus on a limited number of issues =20 > and is preferable to long-lived WGs working on many issues in =20 > parallel. (It is highly recommended by the IESG.) > > Please have a look at it and state whether or not you think it =20 > makes sense to have an IPFIX follow-up WG. Also please read the =20 > proposed charter carefully and express your objections, concerns, =20 > comments, requests for modifications, etc. > > The plan is to elaborate the new charter proposal on this list and =20 > submit an agreed version to our area directors soon. The deadline =20 > for requesting BoF sessions at the next IETF meeting in Dallas is =20 > February 13. > > Thanks, > > Juergen > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > Why do we need to continue the work of IPFIX and PSAMP? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > IPFIX has completed its charter and PSAMP will do so very soon. =20 > Still, there are a lot of ongoing activities in the community of =20 > these two WGs: > > 1. Flow aggregation > draft-dressler-ipfix-aggregation-01.txt > > 2. reducing redundancy in IPFIX and PSAMP reports > draft-boschi-export-perpktinfo-00.txt > > 3. IPFIX implementation guidelines > draft-boschi-ipfix-implementation-guidelines-00.txt > > 4. Path-coupled meter configuration > draft-fessi-nsis-m-nslp-framework-02.txt > draft-dressler-nsis-metering-nslp-03.txt > (currently under discussion in the NSIS WG, but not covered > by the NSIS charter. It is a candidate work item for NSIS > re-chartering, but the NSIS WG asks if it would not be better > covered by IPFIX) > > 5. IPFIX reliability > draft-bclaise-ipfix-reliability-00.txt > > 6. Reporting bi-directional flows with IPFIX > draft-boschi-ipfix-biflow-01.txt > > 7. a format for storing IPFIX records > draft-trammell-ipfix-file-00.txt > > 8. IPFIX MIB module > no I-D yet, but two teams working on it independently. > > 9. Common IPFIX templates > draft-stephan-isp-templates-01.txt > > 10. Reliable server pooling for IPFIX > draft-coene-rserpool-applic-ipfix-01.txt > > 11. Flow sampling > draft-molina-flow-selection-00.txt (expired) > > Did I miss something? > > > 1.-4. and 9. have already been discussed at past IPFIX or PSAMP =20 > sessions. > > This list shows two things. > - There is a community interested in IPFIX that is not too small. > - This community and is willing to further work on issues IPFIX-=20 > related > issues in the IETF. > This is a very good starting point for a charter discussion. > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Which work items are suited? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > Not all of the issues listed above are at a stage, where they =20 > should be considered as a WG work item, but 1.-4. are quite well =20 > developed and 5. > and 6. are candidates. Since 4. is a candidate for NSIS re-=20 > chartering, I dropped it from the following considerations. > > Each of 1.-3. has been presented at IPFIX or PSAMP sessions already =20= > two times with some discussion on the suggested approach. For all =20 > I sense an agreement in the IPFIX WG (at least no objections so =20 > far) that these issues are relevant work and potential WG work =20 > items (to be confirmed on the list, of course). > > - The flow aggregation work is rather mature. Actually this =20 > draft covers > something that is missing in IPFIX: How to tell the collector =20 > that the > metering probe does not have the standard (Netflow default) =20 > configuration, > but filters and aggregates certain flows. > There are some terminology problems and a set of technical =20 > issues to be > solved, but there is not problem with the general direction and =20= > the chosen > approach. Still, thorough reviews are missing as well as a =20 > discussion on > how to fit it well into the IPFIX architecture. > > - Reducing redundancy in IPFIX and PSAMP reports is an issue that =20= > was > received very well by both WGs when past versions of the IDs =20 > were presented. > It is considered a useful method of applying IPFIX efficiently. > Still, the current drafts were considered as to specific. They =20= > apply > the optimization to packet reports only. At the last PSAMP =20 > meeting it was > noted that the method should be generalized such that it can be =20= > applied to > all redundant IPFIX transmissions. This generalization needs =20 > to be done, > but the way to go is clear and basically agreed on. > > - The implementation guidelines are considered the most important =20= > work item > by many WG members (including myself). Many people are =20 > currently implementing > IPFIX and several recommendations were identified at the first =20 > IPFIX interop > (next one is scheduled for end of February). The sooner this =20 > document is > available, the more will help improving ongoing implementations. > My problem with this item is that the current individual draft =20 > is in a bad > shape. Therefore, the milestones for this item are later than =20 > for the > others. > > The two weaker candidates for WG items are IPFIX reliability and =20 > reporting of bidirectional flows. Both have been requested on the =20 > IPFIX mailing list several time in the past years, but we could not =20= > agree on making them part of the basic IPFIX standard. > But as add-ons, that integrate well with the standard, they can be =20 > considered, particularly since I heard about operator requests for =20 > both of them. > A problem of these issues is that so far they have not been =20 > presented at IPFIX or PSAMP sessions and there has not been a =20 > discussion yet on the approaches followed by the existing drafts. =20 > Therefore, these two are not included in the draft proposal below. > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > Charter Proposal: > Efficient Use of IPFIX (USEIPFIX) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > The IPFIX working group has specified the IPFIX protocol for =20 > exporting flow records. The PSAMP working group has specified the =20 > usage of the IPFIX protocol for exporting packet records. With both =20= > specifications available, several implementers have started =20 > building applications using the IPFIX protocol. > > At a first interoperability testing event, several IPFIX protocol =20 > implementations were tested. The experiences made at this event =20 > were fed back to IPFIX protocol specification, particularly for =20 > removing ambiguities. In addition, several lessons were learned =20 > about how to implement and use IPFIX correctly and efficiently. =20 > The exchange among different implementers further led to new ideas =20 > for advanced usage of IPFIX. Many of these ideas are currently =20 > documented in individual Internet drafts. > > The goal of the USEIPFIX working group is producing best current =20 > practice and guideline documents concerning implementation, =20 > application and usage of the IPFIX protocol. > > Out of scope are modifications of the core IPFIX and PSAMP protocol =20= > specifications. In scope is the definition of new IPFIX and PSAMP =20 > information elements within the documents produced by the USEIPFIX WG. > > Specific Goals of the USEIPFIX WG are: > > o Developing guidelines for implementers based on experiences > gained individually by implementers and jointly at interoperability > testing events. The guidelines will give recommendations for > integrating IPFIX observation points, measurement processes, and > exporting processes into the packet flow at different kinds of IPFIX > devices. They will make suggestions for efficient implementation of > the IPFIX protocol features and identify parts of the IPFIX > specification that have already been misunderstood by several > implementers. For some implementation choices that the protocol > specification leaves to the implementer, the guidelines will discuss > advantages and disadvantages of the different choices. > > o Developing methods and means for an efficient use of the IPFIX > protocol that reduces redundancy in flow reports. The basic idea > to be followed is very simple. For multiple flow records that all > report the same value in one or more of the contained IPFIX > information elements, these values are removed from the flow records > and instead reported once for all in a separate record. Such an > approach integrates very well with the IPFIX protocol and only needs > few means for expressing the relationship between flow records and > corresponding separate records. > > o Develop a method for flow aggregation reducing the amount of > measurement data exchanged between IPFIX exporters and IPFIX > collectors. Using aggregation techniques, measurement =20 > information of > multiple similar flows is aggregated into few meta-flow records. > Applied aggregation rules need to be communicate. > > o Investigate further ways of efficiently using the IPFIX protocols > including but not limited to > - providing reliability for IPFIX transmissions, > - reporting bi-directional flows, > - path-coupled configuration of IPFIX devices, > - reporting the configuration of IPFIX devices, > - flow sampling at IPFIX devices, > - storing IPFIX flow records and packet records. > These issues are not current work items of the USEIPFIX WG but are > evaluated as candidates for potential future work items. > > > Milestones: > > Mar 2006 Initial version of flow aggregation methods Mar 2006 =20 > Initial version of reducing redundandy in IPFIX records Mar 2006 =20 > IPFIX and PSAMP interoperability testing event (not a real WG =20 > milestone?) Apr 2006 Initial version of implementation guidelines =20 > Jul 2006 Submit flow aggregation methods to IESG Sep 2006 Submit =20 > reducing redundancy in IPFIX records to IESG Sep 2006 Submit =20 > implementation guidelines to IESG > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in =20 > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe =20= > ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in =20 > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ --Apple-Mail-4--466098579 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.4.2 (Darwin) iD8DBQFD4kVq4/8LCZ4pwvYRAgaQAKC4lFLdIyBGWa8tr21ZCIJSCIlD+ACeKqcw iP8RLjagFqDBj410hnMrBfU= =FQnu -----END PGP SIGNATURE----- --Apple-Mail-4--466098579-- -- 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 02 16:50:19 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4mLG-0002Zi-Uw for ipfix-archive@megatron.ietf.org; Thu, 02 Feb 2006 16:50:19 -0500 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 QAA16979 for ; Thu, 2 Feb 2006 16:48:28 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F4lwz-0003DC-00 for ipfix-list@mil.doit.wisc.edu; Thu, 02 Feb 2006 15:25:09 -0600 Received: from relay01.pair.com ([209.68.5.15]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1F4lwy-0003Cu-00 for ipfix@net.doit.wisc.edu; Thu, 02 Feb 2006 15:25:08 -0600 Received: (qmail 66000 invoked from network); 2 Feb 2006 19:06:39 -0000 Received: from unknown (HELO ?192.168.0.162?) (unknown) by unknown with SMTP; 2 Feb 2006 19:06:39 -0000 X-pair-Authenticated: 207.237.36.98 In-Reply-To: References: <804B13F8F3D94A4AB18B9B01ACB68FA101D312@EXCHSRV.fokus.fraunhofer.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1EDA3416-DC29-4853-9397-7C9ADA4FEDC6@qosient.com> Cc: Tanja Zseby , Juergen Quittek , ipfix@net.doit.wisc.edu, Elisa Boschi , Roman Danyliw Content-Transfer-Encoding: quoted-printable From: Carter Bullard Subject: Re: [ipfix] IPFIX followup charter Date: Thu, 2 Feb 2006 14:06:38 -0500 To: Brian Trammell X-Mailer: Apple Mail (2.746.2) Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Gentle people, My two cents worth. I do believe that the biggest problems for IPFIX =20= adoption are first, its requirement for SCTP and second its shortcomings in =20 extensibility, which include (but are not limited to) issues in support for vendor =20 specific information elements. I would be interested in using IPFIX if it could support multicast =20 transport, and if it could support middlebox recognition and processing of vendor =20 specific proprietary information elements in an efficient/utilitarian way. If these =20 topics were in the next IPFIX WG effort, then that would help a great deal!!!! But, I would be more interested in supporting an effort to describe =20 an IPFIX file format (exchange doesn't happen just on the wire you know). While =20 the IETF would probably not support a working group for a file format, any =20 future IPFIX WG should include in its set of goals an informational RFC that =20 describes issues for persistent IPFIX data. Any idea if you guys are going to have a formal meeting in Dallas? Carter On Feb 2, 2006, at 12:46 PM, Brian Trammell wrote: > Tanja, > > As co-author of the biflow draft, of course I agree with you that =20 > it should be included in this charter. There has not been much =20 > discussion among the wider group on the biflow draft because there =20 > has not been a full working group meeting since the effort was =20 > initiated. That said, in one-on-one meetings in Vancouver, we did =20 > recieve some very good feedback and are incorporating it into a -02 =20= > draft that will be available well before Dallas for discussion. > > There's not a whole lot of content in -01 (or the forthcoming -02 =20 > for that matter) mainly because single-record biflow export is a =20 > relatively simple idea with a relatively simple design. I =20 > personally don't anticipate that adding the biflow draft to the =20 > proposed short-term charter will have a significant impact on the =20 > amount of time required to see it to completion. > > Given that many of us in the security-oriented flow analysis =20 > community, where the question "did anyone answer?" often separates =20 > mere concern from actionability, consider biflow export support to =20 > be quite important, failure to improve upon the relatively =20 > inefficient current methods for biflow export in IPFIX may hinder =20 > its adoption as anything other than a slightly more complicated =20 > NetFlow V9: another data source to read from and translated to one =20 > of a number of proprietary collection protocols as near to the =20 > sensing edge as possible. Delaying official WG action on this until =20= > July 2007, as I believe leaving biflow support off the next charter =20= > and allowing for one IETF meeting cycle of slack in the schedule =20 > implies, won't help IPFIX adoption within this community. By that =20 > time, CERT/NetSA's own biflow export system will have been in =20 > production use for a year, albeit with CERT private enterprise IEs =20 > standing in for official reverse-direction value fields. > > It would instead be preferable to continue this work within the =20 > working group without delay. > > Regards, > > Brian > > On Feb 2, 2006, at 5:27 AM, Tanja Zseby wrote: > >> Hi J=FCrgen and all, >> >> I agree that due to the high amount of drafts we need to decide on =20= >> the most important ones for the first round. Nevertheless, I think =20= >> we should consider to include the bi-flow draft already now in the =20= >> new charter. >> The idea for such a draft originated at the last FloCon workshop =20 >> where a lot of people had doubts about IPFIX because it currently =20 >> lacks information on how to do bi-flow matching/reporting. Many of =20= >> the participants have written their own programs in the past to =20 >> allow bi-flow analysis from NetFlow data. So as a result of =20 >> discussions during the workshop, Brian and Elisa decided to work =20 >> on such a draft. I agree that there is not yet very much content =20 >> in the current version of the draft but since this request came =20 >> from a larger community I consider it as important. >> >> Brian, Elisa maybe you can comment on this? Do you share my =20 >> viewpoint? How would you prioritize your work in IPFIX (since you =20 >> are also co-authors in other drafts)? >> >> Best regards, >> Tanja >> >> -----Original Message----- >> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On =20= >> Behalf Of Juergen Quittek >> Sent: Tuesday, January 31, 2006 11:42 PM >> To: ipfix@net.doit.wisc.edu >> Subject: [ipfix] IPFIX followup charter >> >> Dear all, >> >> As you know, the IPFIX working group has completed its charter by =20 >> submitting all planned documents (with a delay of several years) =20 >> to the IESG for publication as RFC. Also the PSAMP WG will reach =20 >> this status soon. >> >> Building on the results of these WGs, there are a lot of related =20 >> ongoing activities that are producing Internet drafts related to =20 >> IPFIX. Several of them have already been presented at recent =20 >> IPFIX and PSAMP sessions. But working on them is not covered by =20 >> the IPFIX or PSAMP charter. If we want to continue this IPFIX-=20 >> related work, we need a new charter that gives it a home at the IETF. >> >> The text below lists and discusses related work and suggests a =20 >> charter for a follow-up WG. It is the output of several =20 >> discussions with Tanja, Benoit, and Nevil. >> >> The proposed charter is very short-lived and includes only the =20 >> three most mature work items out of a longer list of candidates. =20 >> The basic idea is completing this charter within less than a year =20 >> and then re-chartering to cover further work items that have =20 >> progressed until then. This lean work model with short-lived =20 >> charters allows the group to focus on a limited number of issues =20 >> and is preferable to long-lived WGs working on many issues in =20 >> parallel. (It is highly recommended by the IESG.) >> >> Please have a look at it and state whether or not you think it =20 >> makes sense to have an IPFIX follow-up WG. Also please read the =20 >> proposed charter carefully and express your objections, concerns, =20 >> comments, requests for modifications, etc. >> >> The plan is to elaborate the new charter proposal on this list and =20= >> submit an agreed version to our area directors soon. The deadline =20= >> for requesting BoF sessions at the next IETF meeting in Dallas is =20 >> February 13. >> >> Thanks, >> >> Juergen >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> Why do we need to continue the work of IPFIX and PSAMP? >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> >> IPFIX has completed its charter and PSAMP will do so very soon. =20 >> Still, there are a lot of ongoing activities in the community of =20 >> these two WGs: >> >> 1. Flow aggregation >> draft-dressler-ipfix-aggregation-01.txt >> >> 2. reducing redundancy in IPFIX and PSAMP reports >> draft-boschi-export-perpktinfo-00.txt >> >> 3. IPFIX implementation guidelines >> draft-boschi-ipfix-implementation-guidelines-00.txt >> >> 4. Path-coupled meter configuration >> draft-fessi-nsis-m-nslp-framework-02.txt >> draft-dressler-nsis-metering-nslp-03.txt >> (currently under discussion in the NSIS WG, but not covered >> by the NSIS charter. It is a candidate work item for NSIS >> re-chartering, but the NSIS WG asks if it would not be better >> covered by IPFIX) >> >> 5. IPFIX reliability >> draft-bclaise-ipfix-reliability-00.txt >> >> 6. Reporting bi-directional flows with IPFIX >> draft-boschi-ipfix-biflow-01.txt >> >> 7. a format for storing IPFIX records >> draft-trammell-ipfix-file-00.txt >> >> 8. IPFIX MIB module >> no I-D yet, but two teams working on it independently. >> >> 9. Common IPFIX templates >> draft-stephan-isp-templates-01.txt >> >> 10. Reliable server pooling for IPFIX >> draft-coene-rserpool-applic-ipfix-01.txt >> >> 11. Flow sampling >> draft-molina-flow-selection-00.txt (expired) >> >> Did I miss something? >> >> >> 1.-4. and 9. have already been discussed at past IPFIX or PSAMP =20 >> sessions. >> >> This list shows two things. >> - There is a community interested in IPFIX that is not too small. >> - This community and is willing to further work on issues IPFIX-=20 >> related >> issues in the IETF. >> This is a very good starting point for a charter discussion. >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> Which work items are suited? >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> >> Not all of the issues listed above are at a stage, where they =20 >> should be considered as a WG work item, but 1.-4. are quite well =20 >> developed and 5. >> and 6. are candidates. Since 4. is a candidate for NSIS re-=20 >> chartering, I dropped it from the following considerations. >> >> Each of 1.-3. has been presented at IPFIX or PSAMP sessions =20 >> already two times with some discussion on the suggested approach. =20= >> For all I sense an agreement in the IPFIX WG (at least no =20 >> objections so far) that these issues are relevant work and =20 >> potential WG work items (to be confirmed on the list, of course). >> >> - The flow aggregation work is rather mature. Actually this =20 >> draft covers >> something that is missing in IPFIX: How to tell the collector =20 >> that the >> metering probe does not have the standard (Netflow default) =20 >> configuration, >> but filters and aggregates certain flows. >> There are some terminology problems and a set of technical =20 >> issues to be >> solved, but there is not problem with the general direction =20 >> and the chosen >> approach. Still, thorough reviews are missing as well as a =20 >> discussion on >> how to fit it well into the IPFIX architecture. >> >> - Reducing redundancy in IPFIX and PSAMP reports is an issue =20 >> that was >> received very well by both WGs when past versions of the IDs =20 >> were presented. >> It is considered a useful method of applying IPFIX efficiently. >> Still, the current drafts were considered as to specific. =20 >> They apply >> the optimization to packet reports only. At the last PSAMP =20 >> meeting it was >> noted that the method should be generalized such that it can =20 >> be applied to >> all redundant IPFIX transmissions. This generalization needs =20 >> to be done, >> but the way to go is clear and basically agreed on. >> >> - The implementation guidelines are considered the most =20 >> important work item >> by many WG members (including myself). Many people are =20 >> currently implementing >> IPFIX and several recommendations were identified at the first =20= >> IPFIX interop >> (next one is scheduled for end of February). The sooner this =20 >> document is >> available, the more will help improving ongoing implementations. >> My problem with this item is that the current individual draft =20= >> is in a bad >> shape. Therefore, the milestones for this item are later than =20= >> for the >> others. >> >> The two weaker candidates for WG items are IPFIX reliability and =20 >> reporting of bidirectional flows. Both have been requested on the =20= >> IPFIX mailing list several time in the past years, but we could =20 >> not agree on making them part of the basic IPFIX standard. >> But as add-ons, that integrate well with the standard, they can be =20= >> considered, particularly since I heard about operator requests for =20= >> both of them. >> A problem of these issues is that so far they have not been =20 >> presented at IPFIX or PSAMP sessions and there has not been a =20 >> discussion yet on the approaches followed by the existing drafts. =20= >> Therefore, these two are not included in the draft proposal below. >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> Charter Proposal: >> Efficient Use of IPFIX (USEIPFIX) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> The IPFIX working group has specified the IPFIX protocol for =20 >> exporting flow records. The PSAMP working group has specified the =20 >> usage of the IPFIX protocol for exporting packet records. With =20 >> both specifications available, several implementers have started =20 >> building applications using the IPFIX protocol. >> >> At a first interoperability testing event, several IPFIX protocol =20 >> implementations were tested. The experiences made at this event =20 >> were fed back to IPFIX protocol specification, particularly for =20 >> removing ambiguities. In addition, several lessons were learned =20 >> about how to implement and use IPFIX correctly and efficiently. =20 >> The exchange among different implementers further led to new ideas =20= >> for advanced usage of IPFIX. Many of these ideas are currently =20 >> documented in individual Internet drafts. >> >> The goal of the USEIPFIX working group is producing best current =20 >> practice and guideline documents concerning implementation, =20 >> application and usage of the IPFIX protocol. >> >> Out of scope are modifications of the core IPFIX and PSAMP =20 >> protocol specifications. In scope is the definition of new IPFIX =20 >> and PSAMP information elements within the documents produced by =20 >> the USEIPFIX WG. >> >> Specific Goals of the USEIPFIX WG are: >> >> o Developing guidelines for implementers based on experiences >> gained individually by implementers and jointly at interoperability >> testing events. The guidelines will give recommendations for >> integrating IPFIX observation points, measurement processes, and >> exporting processes into the packet flow at different kinds of =20 >> IPFIX >> devices. They will make suggestions for efficient =20 >> implementation of >> the IPFIX protocol features and identify parts of the IPFIX >> specification that have already been misunderstood by several >> implementers. For some implementation choices that the protocol >> specification leaves to the implementer, the guidelines will =20 >> discuss >> advantages and disadvantages of the different choices. >> >> o Developing methods and means for an efficient use of the IPFIX >> protocol that reduces redundancy in flow reports. The basic idea >> to be followed is very simple. For multiple flow records that all >> report the same value in one or more of the contained IPFIX >> information elements, these values are removed from the flow =20 >> records >> and instead reported once for all in a separate record. Such an >> approach integrates very well with the IPFIX protocol and only =20 >> needs >> few means for expressing the relationship between flow records and >> corresponding separate records. >> >> o Develop a method for flow aggregation reducing the amount of >> measurement data exchanged between IPFIX exporters and IPFIX >> collectors. Using aggregation techniques, measurement =20 >> information of >> multiple similar flows is aggregated into few meta-flow records. >> Applied aggregation rules need to be communicate. >> >> o Investigate further ways of efficiently using the IPFIX protocols >> including but not limited to >> - providing reliability for IPFIX transmissions, >> - reporting bi-directional flows, >> - path-coupled configuration of IPFIX devices, >> - reporting the configuration of IPFIX devices, >> - flow sampling at IPFIX devices, >> - storing IPFIX flow records and packet records. >> These issues are not current work items of the USEIPFIX WG but are >> evaluated as candidates for potential future work items. >> >> >> Milestones: >> >> Mar 2006 Initial version of flow aggregation methods Mar 2006 =20 >> Initial version of reducing redundandy in IPFIX records Mar 2006 =20 >> IPFIX and PSAMP interoperability testing event (not a real WG =20 >> milestone?) Apr 2006 Initial version of implementation guidelines =20= >> Jul 2006 Submit flow aggregation methods to IESG Sep 2006 Submit =20= >> reducing redundancy in IPFIX records to IESG Sep 2006 Submit =20 >> implementation guidelines to IESG >> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in =20 >> message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say =20 >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in =20 >> 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 goij200@yahoo.co.jp Thu Feb 02 20:09:59 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4pSZ-00013w-Mt for ipfix-archive@megatron.ietf.org; Thu, 02 Feb 2006 20:09:59 -0500 Received: from ocn.co.jp ([221.212.58.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07123 for ; Thu, 2 Feb 2006 20:08:12 -0500 (EST) Date: Thu, 2 Feb 2006 20:08:12 -0500 (EST) Message-Id: <200602030108.UAA07123@ietf.org> Received: from vedcs4 (unknown [120.24.164.95]) by smtp90 (Coremail) with SMTP id RM9nEIRuRGFsZY8I.1 for ; Thu, 27 Feb 2003 17:55:48 +0800 (CST) X-Originating-IP: [120.24.164.95] Subject: =?iso-2022-jp?B?KH5vfikbJEIkNDNORycyPCQ1JCQhKiEqGyhC?= From: =?gb2312?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C2DD98.18D6E820" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C2DD98.18D6E820 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCNS5FQiRPS1xFUE8/JEokNSRsJEYkJCReJDskcyEjJDMkTiReJF4kRyQ5JEg1VTFnPXVCUD5d JEskSiRqJF4kOyRzJE4kR0IuJGQkKyRLS1xFUE8/JHIkKjpRJF4kOzI8JDUkJCEjGyhCDQpodHRw Oi8vYXdnLndlYmNodS5jb20vY2FzYW5vdmEvPzE5MjkNCg0KGyRCIiM1LkVCO1hEajh9OkI/Njl+ JF8yREc9JEo9d0AtQj8/dCRHJDkbKEIgGyRCIiMxZz11NmJAaEonJCQ2ZDlUPzY5fjJERz0lNyU5 JUYlYEVrOlwbKEINChskQjg9Ol8hShsoQjIwMDYtMDEbJEIhSyRONVUxZz11QWo+bCRPGyhCOC41 GyRCS3wxXyFBGyhCMTUuNhskQkt8MV8kSCRKJEMkRiQqJGokXiQ5ISMbKEINClBDIBskQjdIQlMh Ik14TVEyREc9JEckOSEjGyhCDQobJEIkXiQ6JE8/NzUsTDVOQUVQTz8kKyRpJCo0aiQkQ1ckNyRe JDkhIxsoQg0KDQpodHRwOi8vYXdnLndlYmNodS5jb20vY2FzYW5vdmEvPzE5MjkNCg0KPBskQjUu PXckTiVVJSclaSVGJS8kXyQ7JEYyPCQ1JCQhZBsoQg0KIA0KGyRCIVolVSUnJWk8K0t9PXdALUpn PTghWxsoQg0KGyRCJVUlJyVpOSUkLSRONS49dyRLJEgkQyRGOkc5YiROPVAycSQkJE4+bD1qJEck OSEqGyhCDQobJEI6IyRKJGlCdDszJE5DS0AtIWEhSiQqJEEkcyRBJHMhSyRyQSokU0p8QmokRyQ5 ISobKEINChskQjUuPXckTiVVJSclaSVGJS8lSyVDJS8kcjtXJCZCOEosQUc/TUNLQC0kSztuJDck RiRfJEYyPCQ1JCQhIxsoQg0KGyRCJCokQSRzJEEkc0M1JDckTzojRD4kMCRLJEckYiEqGyhCDQpo dHRwOi8vYXdnLndlYmNodS5jb20vY2FzYW5vdmEvPzE5MjkNCg0KGyRCIVolVSUnJWk5JSQtJEpD S0AtPTgkXiRsISohWxsoQg0KIA0KGyRCIXtDS0AtRVBPPyRiJCpCVCRBJDckRiQqJGokXiQ5ISMb KEINChskQiF7Q0tALSROSn0kT0w1TkEkR0VQTz9EOiQxJF4kOSEjGyhCDQpodHRwOi8vYXdnLndl YmNodS5jb20vY2FzYW5vdmEvPzE5MjkNCg0KIA0KDQoNCiANCg0KDQobJEI6IzJzNj1MIyQsQTQk L0w1JCRKfSEiJWEhPCVrSVRNVyROSn0kTyQzJEEkaSRLJWEhPCVrJHIiLRsoQg0KY29uY2VwdDJf bmV0QHlhaG9vLmNh ------=_NextPart_000_0006_01C2DD98.18D6E820 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiPjxGT05U IHNpemU9Mj4NCjxESVY+GyRCNS5FQiRPS1xFUE8/JEokNSRsJEYkJCReJDskcyEjJDMkTiReJF4k RyQ5JEg1VTFnPXVCUD5dJEskSiRqJF4kOyRzJE4kR0IuJGQkKyRLS1xFUE8/JHIkKjpRJF4kOzI8 JDUkJCEjGyhCPEJSPjxBIA0KaHJlZj0iaHR0cDovL2F3Zy53ZWJjaHUuY29tL2Nhc2Fub3ZhLz8x OTI5Ij5odHRwOi8vYXdnLndlYmNodS5jb20vY2FzYW5vdmEvPzE5Mjk8L0E+PC9ESVY+DQo8RElW PjxCUj4bJEIiIzUuRUI7WERqOH06Qj82OX4kXzJERz0kSj13QC1CPz90JEckORsoQiANChskQiIj MWc9dTZiQGhKJyQkNmQ5VD82OX4yREc9JTclOSVGJWBFazpcGyhCPEJSPhskQjg9Ol8hShsoQjIw MDYtMDEbJEIhSyRONVUxZz11QWo+bCRPGyhCOC41GyRCS3wxXyFBGyhCMTUuNhskQkt8MV8kSCRK JEMkRiQqJGokXiQ5ISMbKEI8QlI+UEMgDQobJEI3SEJTISJNeE1RMkRHPSRHJDkhIxsoQjxCUj4b JEIkXiQ6JE8/NzUsTDVOQUVQTz8kKyRpJCo0aiQkQ1ckNyReJDkhIxsoQjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+PEEgDQpocmVmPSJodHRwOi8vYXdnLndlYmNodS5jb20vY2FzYW5v dmEvPzE5MjkiPmh0dHA6Ly9hd2cud2ViY2h1LmNvbS9jYXNhbm92YS8/MTkyOTwvQT48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT0bJEJBV0JOGyhCPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+Jmx0 OxskQjUuPXckTiVVJSclaSVGJS8kXyQ7JEYyPCQ1JCQhZBsoQjxCUj4mbmJzcDs8QlI+GyRCIVol VSUnJWk8K0t9PXdALUpnPTghWxsoQjxCUj4bJEIlVSUnJWk5JSQtJE41Lj13JEskSCRDJEY6Rzli JE49UDJxJCQkTj5sPWokRyQ5ISobKEI8QlI+GyRCOiMkSiRpQnQ7MyROQ0tALSFhIUokKiRBJHMk QSRzIUskckEqJFNKfEJqJEckOSEqGyhCPEJSPhskQjUuPXckTiVVJSclaSVGJS8lSyVDJS8kcjtX JCZCOEosQUc/TUNLQC0kSztuJDckRiRfJEYyPCQ1JCQhIxsoQjxCUj4bJEIkKiRBJHMkQSRzQzUk NyRPOiNEPiQwJEskRyRiISobKEI8QlI+PEEgDQpocmVmPSJodHRwOi8vYXdnLndlYmNodS5jb20v Y2FzYW5vdmEvPzE5MjkiPmh0dHA6Ly9hd2cud2ViY2h1LmNvbS9jYXNhbm92YS8/MTkyOTwvQT48 L0RJVj4NCjxESVY+PEJSPhskQiFaJVUlJyVpOSUkLSRKQ0tALT04JF4kbCEqIVsbKEI8QlI+Jm5i c3A7PEJSPhskQiF7Q0tALUVQTz8kYiQqQlQkQSQ3JEYkKiRqJF4kOSEjGyhCPEJSPhskQiF7Q0tA LSROSn0kT0w1TkEkR0VQTz9EOiQxJF4kOSEjGyhCPEJSPjxBIA0KaHJlZj0iaHR0cDovL2F3Zy53 ZWJjaHUuY29tL2Nhc2Fub3ZhLz8xOTI5Ij5odHRwOi8vYXdnLndlYmNodS5jb20vY2FzYW5vdmEv PzE5Mjk8L0E+PC9ESVY+DQo8RElWPjxCUj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPjxCUj4mbmJzcDs8L0RJVj48L0ZPTlQ+PC9GT05UPg0KPERJVj48Rk9OVCBmYWNlPSJN UyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 Ik1TIFVJIEdvdGhpYyI+PEJSPjxGT05UIA0Kc2l6ZT0yPhskQjojMnM2PUwjJCxBNCQvTDUkJEp9 ISIlYSE8JWtJVE1XJE5KfSRPJDMkQSRpJEslYSE8JWskciItGyhCPEJSPjwvRk9OVD48Rk9OVCBz aXplPTI+PEEgDQpocmVmPSJtYWlsdG86Y29uY2VwdDJfbmV0QHlhaG9vLmNhIj5jb25jZXB0Ml9u ZXRAeWFob28uY2E8L0E+PC9GT05UPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0006_01C2DD98.18D6E820-- From majordomo@mil.doit.wisc.edu Fri Feb 03 03:33:53 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4wO0-0002c7-PA for ipfix-archive@megatron.ietf.org; Fri, 03 Feb 2006 03:33:53 -0500 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 DAA05121 for ; Fri, 3 Feb 2006 03:32:06 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F4w3F-0000q2-00 for ipfix-list@mil.doit.wisc.edu; Fri, 03 Feb 2006 02:12:17 -0600 Received: from smtp.ee.ethz.ch ([129.132.2.219]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F4w3D-0000pX-00 for ipfix@net.doit.wisc.edu; Fri, 03 Feb 2006 02:12:15 -0600 Received: from localhost (tranquillity.ee.ethz.ch [129.132.2.222]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D1413D931A; Fri, 3 Feb 2006 09:12:12 +0100 (MET) Received: from smtp.ee.ethz.ch ([129.132.2.217]) by localhost (tranquillity [129.132.2.222]) (amavisd-new, port 10024) with LMTP id 28395-03-10; Fri, 3 Feb 2006 09:12:12 +0100 (MET) Received: from [192.168.0.3] (80-218-231-239.dclient.hispeed.ch [80.218.231.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ee.ethz.ch (Postfix) with ESMTP id 203C0D9312; Fri, 3 Feb 2006 09:12:12 +0100 (MET) Message-ID: <43E31159.9000105@fokus.fraunhofer.de> Date: Fri, 03 Feb 2006 09:16:25 +0100 From: Elisa Boschi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Trammell Cc: Tanja Zseby , Juergen Quittek , ipfix@net.doit.wisc.edu, Elisa Boschi , Roman Danyliw Subject: Re: [ipfix] IPFIX followup charter References: <804B13F8F3D94A4AB18B9B01ACB68FA101D312@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: by amavisd-new at ee.ethz.ch Content-Transfer-Encoding: quoted-printable Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Dear all, I agree with Tanja and Brian and think that the biflow draft should be included already now in the new charter. Reporting bidirectional flows has been requested by a large community and therefore I too consider it important As Brian said, the reason why we didn't present the draft at the IETF is that there was no IPFIX meeting scheduled in Vancouver. Still, we received comments and feedback and are incorporating them in the -02 version. We will definitely request a slot to present this draft at the upcoming IPFIX (or USEIPFIX) meeting in Dallas. Apart from this, I agree with Jurgen's proposed charter and milestones. Regards, Elisa Brian Trammell wrote: > Tanja, > > As co-author of the biflow draft, of course I agree with you that it=20 > should be included in this charter. There has not been much=20 > discussion among the wider group on the biflow draft because there=20 > has not been a full working group meeting since the effort was=20 > initiated. That said, in one-on-one meetings in Vancouver, we did=20 > recieve some very good feedback and are incorporating it into a -02=20 > draft that will be available well before Dallas for discussion. > > There's not a whole lot of content in -01 (or the forthcoming -02 for=20 > that matter) mainly because single-record biflow export is a=20 > relatively simple idea with a relatively simple design. I personally=20 > don't anticipate that adding the biflow draft to the proposed short- > term charter will have a significant impact on the amount of time=20 > required to see it to completion. > > Given that many of us in the security-oriented flow analysis=20 > community, where the question "did anyone answer?" often separates=20 > mere concern from actionability, consider biflow export support to be=20 > quite important, failure to improve upon the relatively inefficient=20 > current methods for biflow export in IPFIX may hinder its adoption as=20 > anything other than a slightly more complicated NetFlow V9: another=20 > data source to read from and translated to one of a number of=20 > proprietary collection protocols as near to the sensing edge as=20 > possible. Delaying official WG action on this until July 2007, as I=20 > believe leaving biflow support off the next charter and allowing for=20 > one IETF meeting cycle of slack in the schedule implies, won't help=20 > IPFIX adoption within this community. By that time, CERT/NetSA's own=20 > biflow export system will have been in production use for a year,=20 > albeit with CERT private enterprise IEs standing in for official=20 > reverse-direction value fields. > > It would instead be preferable to continue this work within the=20 > working group without delay. > > Regards, > > Brian > > On Feb 2, 2006, at 5:27 AM, Tanja Zseby wrote: > >> Hi J=FCrgen and all, >> >> I agree that due to the high amount of drafts we need to decide on=20 >> the most important ones for the first round. Nevertheless, I think=20 >> we should consider to include the bi-flow draft already now in the=20 >> new charter. >> The idea for such a draft originated at the last FloCon workshop=20 >> where a lot of people had doubts about IPFIX because it currently=20 >> lacks information on how to do bi-flow matching/reporting. Many of=20 >> the participants have written their own programs in the past to=20 >> allow bi-flow analysis from NetFlow data. So as a result of=20 >> discussions during the workshop, Brian and Elisa decided to work on=20 >> such a draft. I agree that there is not yet very much content in the >> current version of the draft but since this request came from a=20 >> larger community I consider it as important. >> >> Brian, Elisa maybe you can comment on this? Do you share my=20 >> viewpoint? How would you prioritize your work in IPFIX (since you=20 >> are also co-authors in other drafts)? >> >> Best regards, >> Tanja >> >> -----Original Message----- >> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On=20 >> Behalf Of Juergen Quittek >> Sent: Tuesday, January 31, 2006 11:42 PM >> To: ipfix@net.doit.wisc.edu >> Subject: [ipfix] IPFIX followup charter >> >> Dear all, >> >> As you know, the IPFIX working group has completed its charter by=20 >> submitting all planned documents (with a delay of several years) to=20 >> the IESG for publication as RFC. Also the PSAMP WG will reach this=20 >> status soon. >> >> Building on the results of these WGs, there are a lot of related=20 >> ongoing activities that are producing Internet drafts related to=20 >> IPFIX. Several of them have already been presented at recent IPFIX=20 >> and PSAMP sessions. But working on them is not covered by the IPFIX >> or PSAMP charter. If we want to continue this IPFIX-related work, >> we need a new charter that gives it a home at the IETF. >> >> The text below lists and discusses related work and suggests a=20 >> charter for a follow-up WG. It is the output of several=20 >> discussions with Tanja, Benoit, and Nevil. >> >> The proposed charter is very short-lived and includes only the three >> most mature work items out of a longer list of candidates. The >> basic idea is completing this charter within less than a year and >> then re-chartering to cover further work items that have progressed >> until then. This lean work model with short-lived charters allows >> the group to focus on a limited number of issues and is preferable >> to long-lived WGs working on many issues in parallel. (It is highly >> recommended by the IESG.) >> >> Please have a look at it and state whether or not you think it makes >> sense to have an IPFIX follow-up WG. Also please read the proposed >> charter carefully and express your objections, concerns, comments, >> requests for modifications, etc. >> >> The plan is to elaborate the new charter proposal on this list and=20 >> submit an agreed version to our area directors soon. The deadline=20 >> for requesting BoF sessions at the next IETF meeting in Dallas is=20 >> February 13. >> >> Thanks, >> >> Juergen >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> Why do we need to continue the work of IPFIX and PSAMP? >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> >> IPFIX has completed its charter and PSAMP will do so very soon. =20 >> Still, there are a lot of ongoing activities in the community of=20 >> these two WGs: >> >> 1. Flow aggregation >> draft-dressler-ipfix-aggregation-01.txt >> >> 2. reducing redundancy in IPFIX and PSAMP reports >> draft-boschi-export-perpktinfo-00.txt >> >> 3. IPFIX implementation guidelines >> draft-boschi-ipfix-implementation-guidelines-00.txt >> >> 4. Path-coupled meter configuration >> draft-fessi-nsis-m-nslp-framework-02.txt >> draft-dressler-nsis-metering-nslp-03.txt >> (currently under discussion in the NSIS WG, but not covered >> by the NSIS charter. It is a candidate work item for NSIS >> re-chartering, but the NSIS WG asks if it would not be better >> covered by IPFIX) >> >> 5. IPFIX reliability >> draft-bclaise-ipfix-reliability-00.txt >> >> 6. Reporting bi-directional flows with IPFIX >> draft-boschi-ipfix-biflow-01.txt >> >> 7. a format for storing IPFIX records >> draft-trammell-ipfix-file-00.txt >> >> 8. IPFIX MIB module >> no I-D yet, but two teams working on it independently. >> >> 9. Common IPFIX templates >> draft-stephan-isp-templates-01.txt >> >> 10. Reliable server pooling for IPFIX >> draft-coene-rserpool-applic-ipfix-01.txt >> >> 11. Flow sampling >> draft-molina-flow-selection-00.txt (expired) >> >> Did I miss something? >> >> >> 1.-4. and 9. have already been discussed at past IPFIX or PSAMP=20 >> sessions. >> >> This list shows two things. >> - There is a community interested in IPFIX that is not too small. >> - This community and is willing to further work on issues IPFIX- >> related >> issues in the IETF. >> This is a very good starting point for a charter discussion. >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> Which work items are suited? >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> >> Not all of the issues listed above are at a stage, where they should >> be considered as a WG work item, but 1.-4. are quite well developed >> and 5. >> and 6. are candidates. Since 4. is a candidate for NSIS re- >> chartering, I dropped it from the following considerations. >> >> Each of 1.-3. has been presented at IPFIX or PSAMP sessions already=20 >> two times with some discussion on the suggested approach. For all I >> sense an agreement in the IPFIX WG (at least no objections so far) >> that these issues are relevant work and potential WG work items (to >> be confirmed on the list, of course). >> >> - The flow aggregation work is rather mature. Actually this draft >> covers >> something that is missing in IPFIX: How to tell the collector=20 >> that the >> metering probe does not have the standard (Netflow default)=20 >> configuration, >> but filters and aggregates certain flows. >> There are some terminology problems and a set of technical=20 >> issues to be >> solved, but there is not problem with the general direction and=20 >> the chosen >> approach. Still, thorough reviews are missing as well as a=20 >> discussion on >> how to fit it well into the IPFIX architecture. >> >> - Reducing redundancy in IPFIX and PSAMP reports is an issue that w= as >> received very well by both WGs when past versions of the IDs=20 >> were presented. >> It is considered a useful method of applying IPFIX efficiently. >> Still, the current drafts were considered as to specific. They=20 >> apply >> the optimization to packet reports only. At the last PSAMP=20 >> meeting it was >> noted that the method should be generalized such that it can be=20 >> applied to >> all redundant IPFIX transmissions. This generalization needs to >> be done, >> but the way to go is clear and basically agreed on. >> >> - The implementation guidelines are considered the most important=20 >> work item >> by many WG members (including myself). Many people are=20 >> currently implementing >> IPFIX and several recommendations were identified at the first=20 >> IPFIX interop >> (next one is scheduled for end of February). The sooner this=20 >> document is >> available, the more will help improving ongoing implementations. >> My problem with this item is that the current individual draft=20 >> is in a bad >> shape. Therefore, the milestones for this item are later than=20 >> for the >> others. >> >> The two weaker candidates for WG items are IPFIX reliability and=20 >> reporting of bidirectional flows. Both have been requested on the=20 >> IPFIX mailing list several time in the past years, but we could not=20 >> agree on making them part of the basic IPFIX standard. >> But as add-ons, that integrate well with the standard, they can be=20 >> considered, particularly since I heard about operator requests for=20 >> both of them. >> A problem of these issues is that so far they have not been=20 >> presented at IPFIX or PSAMP sessions and there has not been a=20 >> discussion yet on the approaches followed by the existing drafts. =20 >> Therefore, these two are not included in the draft proposal below. >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> Charter Proposal: >> Efficient Use of IPFIX (USEIPFIX) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> The IPFIX working group has specified the IPFIX protocol for=20 >> exporting flow records. The PSAMP working group has specified the=20 >> usage of the IPFIX protocol for exporting packet records. With both=20 >> specifications available, several implementers have started building >> applications using the IPFIX protocol. >> >> At a first interoperability testing event, several IPFIX protocol=20 >> implementations were tested. The experiences made at this event were >> fed back to IPFIX protocol specification, particularly for removing >> ambiguities. In addition, several lessons were learned about how to >> implement and use IPFIX correctly and efficiently. The exchange >> among different implementers further led to new ideas for advanced >> usage of IPFIX. Many of these ideas are currently documented in >> individual Internet drafts. >> >> The goal of the USEIPFIX working group is producing best current=20 >> practice and guideline documents concerning implementation,=20 >> application and usage of the IPFIX protocol. >> >> Out of scope are modifications of the core IPFIX and PSAMP protocol=20 >> specifications. In scope is the definition of new IPFIX and PSAMP=20 >> information elements within the documents produced by the USEIPFIX WG. >> >> Specific Goals of the USEIPFIX WG are: >> >> o Developing guidelines for implementers based on experiences >> gained individually by implementers and jointly at interoperability >> testing events. The guidelines will give recommendations for >> integrating IPFIX observation points, measurement processes, and >> exporting processes into the packet flow at different kinds of IPFIX >> devices. They will make suggestions for efficient implementation of >> the IPFIX protocol features and identify parts of the IPFIX >> specification that have already been misunderstood by several >> implementers. For some implementation choices that the protocol >> specification leaves to the implementer, the guidelines will discuss >> advantages and disadvantages of the different choices. >> >> o Developing methods and means for an efficient use of the IPFIX >> protocol that reduces redundancy in flow reports. The basic idea >> to be followed is very simple. For multiple flow records that all >> report the same value in one or more of the contained IPFIX >> information elements, these values are removed from the flow records >> and instead reported once for all in a separate record. Such an >> approach integrates very well with the IPFIX protocol and only needs >> few means for expressing the relationship between flow records and >> corresponding separate records. >> >> o Develop a method for flow aggregation reducing the amount of >> measurement data exchanged between IPFIX exporters and IPFIX >> collectors. Using aggregation techniques, measurement information = of >> multiple similar flows is aggregated into few meta-flow records. >> Applied aggregation rules need to be communicate. >> >> o Investigate further ways of efficiently using the IPFIX protocols >> including but not limited to >> - providing reliability for IPFIX transmissions, >> - reporting bi-directional flows, >> - path-coupled configuration of IPFIX devices, >> - reporting the configuration of IPFIX devices, >> - flow sampling at IPFIX devices, >> - storing IPFIX flow records and packet records. >> These issues are not current work items of the USEIPFIX WG but are >> evaluated as candidates for potential future work items. >> >> >> Milestones: >> >> Mar 2006 Initial version of flow aggregation methods Mar 2006 =20 >> Initial version of reducing redundandy in IPFIX records Mar 2006 =20 >> IPFIX and PSAMP interoperability testing event (not a real WG=20 >> milestone?) Apr 2006 Initial version of implementation guidelines=20 >> Jul 2006 Submit flow aggregation methods to IESG Sep 2006 Submit=20 >> reducing redundancy in IPFIX records to IESG Sep 2006 Submit=20 >> implementation guidelines to IESG >> >> >> --=20 >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in=20 >> message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe=20 >> ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> >> >> --=20 >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in=20 >> 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 03 03:50:27 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4we9-0002xg-Si for ipfix-archive@megatron.ietf.org; Fri, 03 Feb 2006 03:50:27 -0500 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 DAA06218 for ; Fri, 3 Feb 2006 03:48:47 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F4wLl-0003vF-00 for ipfix-list@mil.doit.wisc.edu; Fri, 03 Feb 2006 02:31:25 -0600 Received: from faui70.informatik.uni-erlangen.de ([131.188.37.37]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F4wLk-0003v3-00 for ipfix@net.doit.wisc.edu; Fri, 03 Feb 2006 02:31:24 -0600 Received: from faui7as.informatik.uni-erlangen.de (faui7as [131.188.37.230]) by faui70.informatik.uni-erlangen.de (8.9.3p2/8.1.3-FAU) with ESMTP id JAA14519; Fri, 3 Feb 2006 09:31:21 +0100 (MET) Received: from [127.0.0.1] (faui7as.informatik.uni-erlangen.de [131.188.37.230]) by faui7as.informatik.uni-erlangen.de (Postfix) with ESMTP id C8DF1CC207; Fri, 3 Feb 2006 09:31:20 +0100 (CET) Message-ID: <43E314D4.70808@informatik.uni-erlangen.de> Date: Fri, 03 Feb 2006 09:31:16 +0100 From: Falko Dressler Organization: University of Erlangen-Nuremberg, Germany User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX followup charter References: <399327FA4D1893115F68503B@[192.168.1.128]> In-Reply-To: <399327FA4D1893115F68503B@[192.168.1.128]> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear Juergen, Tanja, Brian, Carter, *, I read all the responses to Juergens initial email. Mostly, they suggested to include "just another" additional item to the proposed charter. I believe that all these proposals are really important to successfully deploy IPFIX in the field or to convince a wider audience. Nevertheless, I support Juergens idea of having a very short living charter that covers only a few drafts and a quick re-chartering to include the "next couple of" drafts - again for a fast WG processing. This procedure does not exclude any bright ideas from the IPFIX WG but allows to always focus on a few drafts, bringing them to RFC state, and to repeat these steps again and again. Cheers, Falko. Juergen Quittek wrote: > Dear all, > > As you know, the IPFIX working group has completed its charter > by submitting all planned documents (with a delay of several years) > to the IESG for publication as RFC. Also the PSAMP WG will reach > this status soon. > > Building on the results of these WGs, there are a lot of related > ongoing activities that are producing Internet drafts related to > IPFIX. Several of them have already been presented at recent IPFIX > and PSAMP sessions. But working on them is not covered by the IPFIX > or PSAMP charter. If we want to continue this IPFIX-related work, > we need a new charter that gives it a home at the IETF. > > The text below lists and discusses related work and suggests a > charter for a follow-up WG. It is the output of several discussions > with Tanja, Benoit, and Nevil. > > The proposed charter is very short-lived and includes only the three > most mature work items out of a longer list of candidates. The basic > idea is completing this charter within less than a year and then > re-chartering to cover further work items that have progressed until > then. This lean work model with short-lived charters allows the group > to focus on a limited number of issues and is preferable to long-lived > WGs working on many issues in parallel. (It is highly recommended > by the IESG.) > > Please have a look at it and state whether or not you think it makes > sense to have an IPFIX follow-up WG. Also please read the proposed > charter carefully and express your objections, concerns, comments, > requests for modifications, etc. > > The plan is to elaborate the new charter proposal on this list and > submit an agreed version to our area directors soon. The deadline > for requesting BoF sessions at the next IETF meeting in Dallas is > February 13. > > Thanks, > > Juergen > > > ======================================================= > Why do we need to continue the work of IPFIX and PSAMP? > ======================================================= > > IPFIX has completed its charter and PSAMP will do so very soon. Still, > there > are a lot of ongoing activities in the community of these two WGs: > > 1. Flow aggregation > draft-dressler-ipfix-aggregation-01.txt > > 2. reducing redundancy in IPFIX and PSAMP reports > draft-boschi-export-perpktinfo-00.txt > > 3. IPFIX implementation guidelines > draft-boschi-ipfix-implementation-guidelines-00.txt > > 4. Path-coupled meter configuration > draft-fessi-nsis-m-nslp-framework-02.txt > draft-dressler-nsis-metering-nslp-03.txt > (currently under discussion in the NSIS WG, but not covered > by the NSIS charter. It is a candidate work item for NSIS > re-chartering, but the NSIS WG asks if it would not be better > covered by IPFIX) > > 5. IPFIX reliability > draft-bclaise-ipfix-reliability-00.txt > > 6. Reporting bi-directional flows with IPFIX > draft-boschi-ipfix-biflow-01.txt > > 7. a format for storing IPFIX records > draft-trammell-ipfix-file-00.txt > > 8. IPFIX MIB module > no I-D yet, but two teams working on it independently. > > 9. Common IPFIX templates > draft-stephan-isp-templates-01.txt > > 10. Reliable server pooling for IPFIX > draft-coene-rserpool-applic-ipfix-01.txt > > 11. Flow sampling > draft-molina-flow-selection-00.txt (expired) > > Did I miss something? > > > 1.-4. and 9. have already been discussed at past IPFIX or PSAMP sessions. > > This list shows two things. > - There is a community interested in IPFIX that is not too small. > - This community and is willing to further work on issues IPFIX-related > issues in the IETF. > This is a very good starting point for a charter discussion. > > > ============================ > Which work items are suited? > ============================ > > Not all of the issues listed above are at a stage, where they should be > considered as a WG work item, but 1.-4. are quite well developed and 5. > and 6. are candidates. Since 4. is a candidate for NSIS re-chartering, > I dropped it from the following considerations. > > Each of 1.-3. has been presented at IPFIX or PSAMP sessions already two > times > with some discussion on the suggested approach. For all I sense an > agreement > in the IPFIX WG (at least no objections so far) that these issues are > relevant > work and potential WG work items (to be confirmed on the list, of course). > > - The flow aggregation work is rather mature. Actually this draft covers > something that is missing in IPFIX: How to tell the collector that the > metering probe does not have the standard (Netflow default) > configuration, > but filters and aggregates certain flows. > There are some terminology problems and a set of technical issues to be > solved, but there is not problem with the general direction and the > chosen > approach. Still, thorough reviews are missing as well as a > discussion on > how to fit it well into the IPFIX architecture. > > - Reducing redundancy in IPFIX and PSAMP reports is an issue that was > received very well by both WGs when past versions of the IDs were > presented. > It is considered a useful method of applying IPFIX efficiently. > Still, the current drafts were considered as to specific. They apply > the optimization to packet reports only. At the last PSAMP meeting it > was > noted that the method should be generalized such that it can be > applied to > all redundant IPFIX transmissions. This generalization needs to be > done, > but the way to go is clear and basically agreed on. > > - The implementation guidelines are considered the most important work > item > by many WG members (including myself). Many people are currently > implementing > IPFIX and several recommendations were identified at the first IPFIX > interop > (next one is scheduled for end of February). The sooner this > document is > available, the more will help improving ongoing implementations. > My problem with this item is that the current individual draft is in > a bad > shape. Therefore, the milestones for this item are later than for the > others. > > The two weaker candidates for WG items are IPFIX reliability and > reporting of > bidirectional flows. Both have been requested on the IPFIX mailing list > several > time in the past years, but we could not agree on making them part of > the basic > IPFIX standard. > But as add-ons, that integrate well with the standard, they can be > considered, > particularly since I heard about operator requests for both of them. > A problem of these issues is that so far they have not been presented at > IPFIX > or PSAMP sessions and there has not been a discussion yet on the approaches > followed by the existing drafts. Therefore, these two are not included > in the > draft proposal below. > > > ================================= > Charter Proposal: > Efficient Use of IPFIX (USEIPFIX) > ================================= > > The IPFIX working group has specified the IPFIX protocol for exporting > flow records. The PSAMP working group has specified the usage of the > IPFIX protocol for exporting packet records. With both specifications > available, several implementers have started building applications > using the IPFIX protocol. > > At a first interoperability testing event, several IPFIX protocol > implementations were tested. The experiences made at this event were > fed back to IPFIX protocol specification, particularly for removing > ambiguities. In addition, several lessons were learned about how to > implement and use IPFIX correctly and efficiently. The exchange among > different implementers further led to new ideas for advanced usage of > IPFIX. Many of these ideas are currently documented in individual > Internet drafts. > > The goal of the USEIPFIX working group is producing best current > practice and guideline documents concerning implementation, application > and usage of the IPFIX protocol. > > Out of scope are modifications of the core IPFIX and PSAMP protocol > specifications. In scope is the definition of new IPFIX and PSAMP > information elements within the documents produced by the USEIPFIX WG. > > Specific Goals of the USEIPFIX WG are: > > o Developing guidelines for implementers based on experiences > gained individually by implementers and jointly at interoperability > testing events. The guidelines will give recommendations for > integrating IPFIX observation points, measurement processes, and > exporting processes into the packet flow at different kinds of IPFIX > devices. They will make suggestions for efficient implementation of > the IPFIX protocol features and identify parts of the IPFIX > specification that have already been misunderstood by several > implementers. For some implementation choices that the protocol > specification leaves to the implementer, the guidelines will discuss > advantages and disadvantages of the different choices. > > o Developing methods and means for an efficient use of the IPFIX > protocol that reduces redundancy in flow reports. The basic idea > to be followed is very simple. For multiple flow records that all > report the same value in one or more of the contained IPFIX > information elements, these values are removed from the flow records > and instead reported once for all in a separate record. Such an > approach integrates very well with the IPFIX protocol and only needs > few means for expressing the relationship between flow records and > corresponding separate records. > > o Develop a method for flow aggregation reducing the amount of > measurement data exchanged between IPFIX exporters and IPFIX > collectors. Using aggregation techniques, measurement information of > multiple similar flows is aggregated into few meta-flow records. > Applied aggregation rules need to be communicate. > > o Investigate further ways of efficiently using the IPFIX protocols > including but not limited to > - providing reliability for IPFIX transmissions, > - reporting bi-directional flows, > - path-coupled configuration of IPFIX devices, > - reporting the configuration of IPFIX devices, > - flow sampling at IPFIX devices, > - storing IPFIX flow records and packet records. > These issues are not current work items of the USEIPFIX WG but are > evaluated as candidates for potential future work items. > > > Milestones: > > Mar 2006 Initial version of flow aggregation methods > Mar 2006 Initial version of reducing redundandy in IPFIX records > Mar 2006 IPFIX and PSAMP interoperability testing event (not a real WG > milestone?) > Apr 2006 Initial version of implementation guidelines > Jul 2006 Submit flow aggregation methods to IESG > Sep 2006 Submit reducing redundancy in IPFIX records to IESG > Sep 2006 Submit implementation guidelines to IESG > > > -- > 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/ -- Dr.-Ing. Falko Dressler Computer Networks and Communication Systems University of Erlangen-Nuremberg, Germany Phone: +49 9131 85-27914 / Fax: +49 9131 85-27409 EMail: dressler@informatik.uni-erlangen.de / fd@acm.org WWW: http://www7.informatik.uni-erlangen.de/~dressler/ -- 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 03 10:08:34 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F52Y3-00042b-VD for ipfix-archive@megatron.ietf.org; Fri, 03 Feb 2006 10:08:34 -0500 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 KAA07550 for ; Fri, 3 Feb 2006 10:06:45 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F52ON-00001x-00 for ipfix-list@mil.doit.wisc.edu; Fri, 03 Feb 2006 08:58:31 -0600 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F52OL-00001X-00 for ipfix@net.doit.wisc.edu; Fri, 03 Feb 2006 08:58:29 -0600 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 06A981BAC4D; Fri, 3 Feb 2006 15:58:23 +0100 (CET) Date: Fri, 03 Feb 2006 15:58:33 +0100 From: Juergen Quittek To: Carter Bullard , Brian Trammell Cc: Tanja Zseby , ipfix@net.doit.wisc.edu, Elisa Boschi , Roman Danyliw Subject: Re: [ipfix] IPFIX followup charter Message-ID: <4E52B7DC2366E17B068BB7AF@[10.1.1.171]> In-Reply-To: <1EDA3416-DC29-4853-9397-7C9ADA4FEDC6@qosient.com> References: <804B13F8F3D94A4AB18B9B01ACB68FA101D312@EXCHSRV.fokus.fraunhofer.de> <1EDA3416-DC29-4853-9397-7C9ADA4FEDC6@qosient.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Hi Carter, --On 2/2/06 2:06 PM -0500 Carter Bullard wrote: > Gentle people, > My two cents worth. I do believe that the biggest problems for IPFIX adoption are > first, its requirement for SCTP and second its shortcomings in extensibility, which > include (but are not limited to) issues in support for vendor specific information > elements. > > I would be interested in using IPFIX if it could support multicast transport, and if > it could support middlebox recognition and processing of vendor specific proprietary > information elements in an efficient/utilitarian way. If these topics were in the > next IPFIX WG effort, then that would help a great deal!!!! > > But, I would be more interested in supporting an effort to describe an IPFIX file > format (exchange doesn't happen just on the wire you know). While the IETF > would probably not support a working group for a file format, any future IPFIX > WG should include in its set of goals an informational RFC that describes issues for > persistent IPFIX data. I also think this would be a useful piece to have. But so far, nobody has come up with an initial suggestion. The way I would like to see the new charter is that it is short lived and updated frequently. We could discuss in our meetings already upcoming work items that are submitted as individual drafts and potential candidates to be covered by the next charter update. > Any idea if you guys are going to have a formal meeting in Dallas? Yes, we will definitely meet, just the way how we organize it is not clear. Formally, the best way would be having a BoF session. But if this approach fails, we can go on like last time and host discussions on these work items at IPFIX or PSAMP sessions. > Carter Thanks, Juergen > > > On Feb 2, 2006, at 12:46 PM, Brian Trammell wrote: > >> Tanja, >> >> As co-author of the biflow draft, of course I agree with you that >> it should be included in this charter. There has not been much >> discussion among the wider group on the biflow draft because there >> has not been a full working group meeting since the effort was >> initiated. That said, in one-on-one meetings in Vancouver, we did >> recieve some very good feedback and are incorporating it into a -02 >> draft that will be available well before Dallas for discussion. >> >> There's not a whole lot of content in -01 (or the forthcoming -02 >> for that matter) mainly because single-record biflow export is a >> relatively simple idea with a relatively simple design. I >> personally don't anticipate that adding the biflow draft to the >> proposed short-term charter will have a significant impact on the >> amount of time required to see it to completion. >> >> Given that many of us in the security-oriented flow analysis >> community, where the question "did anyone answer?" often separates >> mere concern from actionability, consider biflow export support to >> be quite important, failure to improve upon the relatively >> inefficient current methods for biflow export in IPFIX may hinder >> its adoption as anything other than a slightly more complicated >> NetFlow V9: another data source to read from and translated to one >> of a number of proprietary collection protocols as near to the >> sensing edge as possible. Delaying official WG action on this until >> July 2007, as I believe leaving biflow support off the next charter >> and allowing for one IETF meeting cycle of slack in the schedule >> implies, won't help IPFIX adoption within this community. By that >> time, CERT/NetSA's own biflow export system will have been in >> production use for a year, albeit with CERT private enterprise IEs >> standing in for official reverse-direction value fields. >> >> It would instead be preferable to continue this work within the >> working group without delay. >> >> Regards, >> >> Brian >> >> On Feb 2, 2006, at 5:27 AM, Tanja Zseby wrote: >> >>> Hi J=FCrgen and all, >>> >>> I agree that due to the high amount of drafts we need to decide on >>> the most important ones for the first round. Nevertheless, I think >>> we should consider to include the bi-flow draft already now in the >>> new charter. >>> The idea for such a draft originated at the last FloCon workshop >>> where a lot of people had doubts about IPFIX because it currently >>> lacks information on how to do bi-flow matching/reporting. Many of >>> the participants have written their own programs in the past to >>> allow bi-flow analysis from NetFlow data. So as a result of >>> discussions during the workshop, Brian and Elisa decided to work >>> on such a draft. I agree that there is not yet very much content >>> in the current version of the draft but since this request came >>> from a larger community I consider it as important. >>> >>> Brian, Elisa maybe you can comment on this? Do you share my >>> viewpoint? How would you prioritize your work in IPFIX (since you >>> are also co-authors in other drafts)? >>> >>> Best regards, >>> Tanja >>> >>> -----Original Message----- >>> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On >>> Behalf Of Juergen Quittek >>> Sent: Tuesday, January 31, 2006 11:42 PM >>> To: ipfix@net.doit.wisc.edu >>> Subject: [ipfix] IPFIX followup charter >>> >>> Dear all, >>> >>> As you know, the IPFIX working group has completed its charter by >>> submitting all planned documents (with a delay of several years) >>> to the IESG for publication as RFC. Also the PSAMP WG will reach >>> this status soon. >>> >>> Building on the results of these WGs, there are a lot of related >>> ongoing activities that are producing Internet drafts related to >>> IPFIX. Several of them have already been presented at recent >>> IPFIX and PSAMP sessions. But working on them is not covered by >>> the IPFIX or PSAMP charter. If we want to continue this IPFIX- >>> related work, we need a new charter that gives it a home at the IETF. >>> >>> The text below lists and discusses related work and suggests a >>> charter for a follow-up WG. It is the output of several >>> discussions with Tanja, Benoit, and Nevil. >>> >>> The proposed charter is very short-lived and includes only the >>> three most mature work items out of a longer list of candidates. >>> The basic idea is completing this charter within less than a year >>> and then re-chartering to cover further work items that have >>> progressed until then. This lean work model with short-lived >>> charters allows the group to focus on a limited number of issues >>> and is preferable to long-lived WGs working on many issues in >>> parallel. (It is highly recommended by the IESG.) >>> >>> Please have a look at it and state whether or not you think it >>> makes sense to have an IPFIX follow-up WG. Also please read the >>> proposed charter carefully and express your objections, concerns, >>> comments, requests for modifications, etc. >>> >>> The plan is to elaborate the new charter proposal on this list and >>> submit an agreed version to our area directors soon. The deadline >>> for requesting BoF sessions at the next IETF meeting in Dallas is >>> February 13. >>> >>> Thanks, >>> >>> Juergen >>> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Why do we need to continue the work of IPFIX and PSAMP? >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> IPFIX has completed its charter and PSAMP will do so very soon. >>> Still, there are a lot of ongoing activities in the community of >>> these two WGs: >>> >>> 1. Flow aggregation >>> draft-dressler-ipfix-aggregation-01.txt >>> >>> 2. reducing redundancy in IPFIX and PSAMP reports >>> draft-boschi-export-perpktinfo-00.txt >>> >>> 3. IPFIX implementation guidelines >>> draft-boschi-ipfix-implementation-guidelines-00.txt >>> >>> 4. Path-coupled meter configuration >>> draft-fessi-nsis-m-nslp-framework-02.txt >>> draft-dressler-nsis-metering-nslp-03.txt >>> (currently under discussion in the NSIS WG, but not covered >>> by the NSIS charter. It is a candidate work item for NSIS >>> re-chartering, but the NSIS WG asks if it would not be better >>> covered by IPFIX) >>> >>> 5. IPFIX reliability >>> draft-bclaise-ipfix-reliability-00.txt >>> >>> 6. Reporting bi-directional flows with IPFIX >>> draft-boschi-ipfix-biflow-01.txt >>> >>> 7. a format for storing IPFIX records >>> draft-trammell-ipfix-file-00.txt >>> >>> 8. IPFIX MIB module >>> no I-D yet, but two teams working on it independently. >>> >>> 9. Common IPFIX templates >>> draft-stephan-isp-templates-01.txt >>> >>> 10. Reliable server pooling for IPFIX >>> draft-coene-rserpool-applic-ipfix-01.txt >>> >>> 11. Flow sampling >>> draft-molina-flow-selection-00.txt (expired) >>> >>> Did I miss something? >>> >>> >>> 1.-4. and 9. have already been discussed at past IPFIX or PSAMP >>> sessions. >>> >>> This list shows two things. >>> - There is a community interested in IPFIX that is not too small. >>> - This community and is willing to further work on issues IPFIX- >>> related >>> issues in the IETF. >>> This is a very good starting point for a charter discussion. >>> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Which work items are suited? >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> Not all of the issues listed above are at a stage, where they >>> should be considered as a WG work item, but 1.-4. are quite well >>> developed and 5. >>> and 6. are candidates. Since 4. is a candidate for NSIS re- >>> chartering, I dropped it from the following considerations. >>> >>> Each of 1.-3. has been presented at IPFIX or PSAMP sessions >>> already two times with some discussion on the suggested approach. >>> For all I sense an agreement in the IPFIX WG (at least no >>> objections so far) that these issues are relevant work and >>> potential WG work items (to be confirmed on the list, of course). >>> >>> - The flow aggregation work is rather mature. Actually this >>> draft covers >>> something that is missing in IPFIX: How to tell the collector >>> that the >>> metering probe does not have the standard (Netflow default) >>> configuration, >>> but filters and aggregates certain flows. >>> There are some terminology problems and a set of technical >>> issues to be >>> solved, but there is not problem with the general direction >>> and the chosen >>> approach. Still, thorough reviews are missing as well as a >>> discussion on >>> how to fit it well into the IPFIX architecture. >>> >>> - Reducing redundancy in IPFIX and PSAMP reports is an issue >>> that was >>> received very well by both WGs when past versions of the IDs >>> were presented. >>> It is considered a useful method of applying IPFIX efficiently. >>> Still, the current drafts were considered as to specific. >>> They apply >>> the optimization to packet reports only. At the last PSAMP >>> meeting it was >>> noted that the method should be generalized such that it can >>> be applied to >>> all redundant IPFIX transmissions. This generalization needs >>> to be done, >>> but the way to go is clear and basically agreed on. >>> >>> - The implementation guidelines are considered the most >>> important work item >>> by many WG members (including myself). Many people are >>> currently implementing >>> IPFIX and several recommendations were identified at the first >>> IPFIX interop >>> (next one is scheduled for end of February). The sooner this >>> document is >>> available, the more will help improving ongoing implementations. >>> My problem with this item is that the current individual draft >>> is in a bad >>> shape. Therefore, the milestones for this item are later than >>> for the >>> others. >>> >>> The two weaker candidates for WG items are IPFIX reliability and >>> reporting of bidirectional flows. Both have been requested on the >>> IPFIX mailing list several time in the past years, but we could >>> not agree on making them part of the basic IPFIX standard. >>> But as add-ons, that integrate well with the standard, they can be >>> considered, particularly since I heard about operator requests for >>> both of them. >>> A problem of these issues is that so far they have not been >>> presented at IPFIX or PSAMP sessions and there has not been a >>> discussion yet on the approaches followed by the existing drafts. >>> Therefore, these two are not included in the draft proposal below. >>> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Charter Proposal: >>> Efficient Use of IPFIX (USEIPFIX) >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> The IPFIX working group has specified the IPFIX protocol for >>> exporting flow records. The PSAMP working group has specified the >>> usage of the IPFIX protocol for exporting packet records. With >>> both specifications available, several implementers have started >>> building applications using the IPFIX protocol. >>> >>> At a first interoperability testing event, several IPFIX protocol >>> implementations were tested. The experiences made at this event >>> were fed back to IPFIX protocol specification, particularly for >>> removing ambiguities. In addition, several lessons were learned >>> about how to implement and use IPFIX correctly and efficiently. >>> The exchange among different implementers further led to new ideas >>> for advanced usage of IPFIX. Many of these ideas are currently >>> documented in individual Internet drafts. >>> >>> The goal of the USEIPFIX working group is producing best current >>> practice and guideline documents concerning implementation, >>> application and usage of the IPFIX protocol. >>> >>> Out of scope are modifications of the core IPFIX and PSAMP >>> protocol specifications. In scope is the definition of new IPFIX >>> and PSAMP information elements within the documents produced by >>> the USEIPFIX WG. >>> >>> Specific Goals of the USEIPFIX WG are: >>> >>> o Developing guidelines for implementers based on experiences >>> gained individually by implementers and jointly at interoperability >>> testing events. The guidelines will give recommendations for >>> integrating IPFIX observation points, measurement processes, and >>> exporting processes into the packet flow at different kinds of >>> IPFIX >>> devices. They will make suggestions for efficient >>> implementation of >>> the IPFIX protocol features and identify parts of the IPFIX >>> specification that have already been misunderstood by several >>> implementers. For some implementation choices that the protocol >>> specification leaves to the implementer, the guidelines will >>> discuss >>> advantages and disadvantages of the different choices. >>> >>> o Developing methods and means for an efficient use of the IPFIX >>> protocol that reduces redundancy in flow reports. The basic idea >>> to be followed is very simple. For multiple flow records that all >>> report the same value in one or more of the contained IPFIX >>> information elements, these values are removed from the flow >>> records >>> and instead reported once for all in a separate record. Such an >>> approach integrates very well with the IPFIX protocol and only >>> needs >>> few means for expressing the relationship between flow records and >>> corresponding separate records. >>> >>> o Develop a method for flow aggregation reducing the amount of >>> measurement data exchanged between IPFIX exporters and IPFIX >>> collectors. Using aggregation techniques, measurement >>> information of >>> multiple similar flows is aggregated into few meta-flow records. >>> Applied aggregation rules need to be communicate. >>> >>> o Investigate further ways of efficiently using the IPFIX protocols >>> including but not limited to >>> - providing reliability for IPFIX transmissions, >>> - reporting bi-directional flows, >>> - path-coupled configuration of IPFIX devices, >>> - reporting the configuration of IPFIX devices, >>> - flow sampling at IPFIX devices, >>> - storing IPFIX flow records and packet records. >>> These issues are not current work items of the USEIPFIX WG but are >>> evaluated as candidates for potential future work items. >>> >>> >>> Milestones: >>> >>> Mar 2006 Initial version of flow aggregation methods Mar 2006 >>> Initial version of reducing redundandy in IPFIX records Mar 2006 >>> IPFIX and PSAMP interoperability testing event (not a real WG >>> milestone?) Apr 2006 Initial version of implementation guidelines >>> Jul 2006 Submit flow aggregation methods to IESG Sep 2006 Submit >>> reducing redundancy in IPFIX records to IESG Sep 2006 Submit >>> implementation guidelines to IESG >>> >>> >>> -- >>> 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/ >> > > > > -- > 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 03 10:17:43 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F52gw-0006cT-33 for ipfix-archive@megatron.ietf.org; Fri, 03 Feb 2006 10:17:42 -0500 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 KAA08929 for ; Fri, 3 Feb 2006 10:15:54 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F52SQ-0001YM-00 for ipfix-list@mil.doit.wisc.edu; Fri, 03 Feb 2006 09:02:42 -0600 Received: from franclinus.red.cert.org ([192.88.209.16]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F52SO-0001Xf-00 for ipfix@net.doit.wisc.edu; Fri, 03 Feb 2006 09:02:40 -0600 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.16) with ESMTP id k13F2cI9020540 for ; Fri, 3 Feb 2006 10:02:38 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k13F0qko019553 for ; Fri, 3 Feb 2006 10:00:52 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k13F0qF8019550; Fri, 03 Feb 2006 10:00:52 -0500 (EST) Received: from [128.237.250.243] (vpn-10-25-4-15.remote.cert.org [10.25.4.15]) by villemus.indigo.cert.org (8.12.11/8.12.11/2.53) with ESMTP id k13F0qX9024010; Fri, 3 Feb 2006 10:00:52 -0500 In-Reply-To: <4E52B7DC2366E17B068BB7AF@[10.1.1.171]> References: <804B13F8F3D94A4AB18B9B01ACB68FA101D312@EXCHSRV.fokus.fraunhofer.de> <1EDA3416-DC29-4853-9397-7C9ADA4FEDC6@qosient.com> <4E52B7DC2366E17B068BB7AF@[10.1.1.171]> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3--389625937" Message-Id: <0EFCE0C8-976D-40DF-A3D5-8E908A8F5C01@cert.org> Cc: Carter Bullard , Tanja Zseby , ipfix@net.doit.wisc.edu, Elisa Boschi , Roman Danyliw Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [ipfix] IPFIX followup charter Date: Fri, 3 Feb 2006 10:00:47 -0500 To: Juergen Quittek X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000004 X-Scanned-By: MIMEDefang 2.54 on 192.88.209.16 Precedence: bulk Sender: majordomo listserver This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-3--389625937 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Feb 3, 2006, at 9:58 AM, Juergen Quittek wrote: >> Any idea if you guys are going to have a formal meeting in Dallas? > > Yes, we will definitely meet, just the way how we organize it is > not clear. > > Formally, the best way would be having a BoF session. But if this > approach > fails, we can go on like last time and host discussions on these > work items > at IPFIX or PSAMP sessions. My preference would be for a USEIPFIX BoF - it would help having everyone in the room to gauge WG interest in the length and scope of the first follow-on charter. --Apple-Mail-3--389625937 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.4.2 (Darwin) iD8DBQFD43Ai4/8LCZ4pwvYRAmiuAJ0WlV5cOluL8DOOCJcF1XNGhow+0ACcC0pb 0NusU9Wo+HxqlPsma0wIzzE= =UJVv -----END PGP SIGNATURE----- --Apple-Mail-3--389625937-- -- 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 cplyler@earthlink.net Fri Feb 03 13:37:01 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F55np-0001ON-Ps for ipfix-archive@megatron.ietf.org; Fri, 03 Feb 2006 13:37:01 -0500 Received: from 82-46-58-168.cable.ubr04.azte.blueyonder.co.uk (82-46-58-168.cable.ubr04.azte.blueyonder.co.uk [82.46.58.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27437 for ; Fri, 3 Feb 2006 13:34:49 -0500 (EST) Received: from conn.twosome.com (laurentian [181.172.59.55]) by combinatorial.com (physiotherapist) with platonist id 6161629418139 for ; Fri, 03 Feb 2006 17:51:25 -0500 Date: Fri, 03 Feb 2006 13:47:23 -0500 Message-Id: <733856512779319474397@microsoft.com> From: Brooke Coley To: ipfix-archive@ietf.org Subject: Amazing, Gilbert X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: electron 4.17.3586 X-MimeOLE: willis 92.530.7481 Content-Type: multipart/mixed; boundary="------=641871823790347" Content-Transfer-Encoding: quoted-printable --------=641871823790347 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


I will go anywhere, provided it be forward.The place is very well and quiet and the children only scream in a low voice.
Sir, a man may be so much of everything, that he is nothing of anything. --------=641871823790347 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Ursula-> http://mvjchp.tourgeth.info/?83295133 --------=641871823790347-- From momo_020460@yahoo.co.jp Sun Feb 05 02:16:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5e88-0003HG-7A for ipfix-archive@megatron.ietf.org; Sun, 05 Feb 2006 02:16:16 -0500 Received: from ocn.ne.jp ([221.212.57.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14776 for ; Sun, 5 Feb 2006 02:14:29 -0500 (EST) Date: Sun, 5 Feb 2006 02:14:29 -0500 (EST) Message-Id: <200602050714.CAA14776@ietf.org> Received: from sppwddlrwr3 (unknown [30.39.180.197]) by smtp62 (Coremail) with SMTP id qKPtAaYHuscZcKgz.1 for ; Sun, 05 Feb 2006 16:16:29 +0800 (CST) X-Originating-IP: [30.39.180.197] Subject: =?iso-2022-jp?B?GyRCSGtMKTg3PGkkSyRGNGokJCReJDkbKEI=?= From: =?gb2312?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: text/plain; Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Transfer-Encoding: base64 DQotGyRCISEbKEItGyRCISEbKEItGyRCISEbKEItGyRCISEbKEItGyRCISEbKEItGyRCISEbKEIt GyRCISEbKEItGyRCISEbKEItGyRCISEbKEItGyRCISEbKEItGyRCISEbKEItGyRCISEbKEItGyRC ISEbKEItGyRCISEbKEItGyRCISEbKEItGyRCISEbKEItGyRCISEbKEItGyRCISEbKEItGyRCISEb KEItGyRCISEbKEItGyRCISEbKEItGyRCISEbKEItGyRCISEbKEItGyRCISEbKEItGyRCISEbKEIt GyRCISEbKEItGyRCISEbKEItGyRCISEbKEINChskQkZNQTMkRyQ5JCw6IyReJEc9UDJxJCQ3TyU1 JSQlSCRHM048QiRLPVAycSQoJD8kMyRIJCIkaiReJDkkKyEpGyhCDQobJEJFdiU1JSQlSCRPOiMk XiRHJE49UDJxJCQ3TyU1JSQlSCRIMGMkJDliM05OKSRHPVAycSQmO3YkLCRHJC0kXiQ5ISMbKEIN ChskQjxCQFMkLCQiJGskPyRhISI8Kz8uJHI7fSRDJEY/ZD4pJEckLSRrJTUlJCVIJEskSiRDJEYk JCReJDkhIxsoQg0KGyRCPmU1LSROTU0kSzdqPmwlNSUkJUgkSyRKJEMkRiQkJGswWSQiJF4kajkt JGEkSiQkJEdEOiQtJD8kJCRIO1ckQyRGJCQkXiQ5ISMbKEINChskQiQtJEMkSDUuSn1NTSROOiMk XiRHJE47VyQkJHIzcCQoJGkkbCRrO3YkRyQ3JGckJiEjGyhCDQobJEJCOEosJEtIfkwjJDckJDtX JCQkciQ3JEYyPCQ1JCQhIxsoQg0KGyRCJC0kQyRINS5KfU1NPCs/SEV2JTUlJCVIJHJDLyRLJGI2 NSQoJD8kLyRKJC8kSiRrJEg7VyQkJF4kOSEjGyhCDQobJEI0MEE0TDVOQSRKJE4kRzBsRVkkKjtu JDckNyRGRDokLzJBQ00kTyQrJEokaiQiJGskSDtXJCQkXiQ5ISMbKEINChskQkQ5ITkkSEQ5Sjg8 Ok5pQ1ckNyReJDckPyEjGyhCDQobJEI6RzhlJF4kR0ZJJHMkR0Q6JC0kIiRqJCwkSCQmJDQkNiQk JF4kNyQ/ISMbKEINCi0bJEIhIRsoQi0bJEIhIRsoQi0bJEIhIRsoQi0bJEIhIRsoQi0bJEIhIRso Qi0bJEIhIRsoQi0bJEIhIRsoQi0bJEIhIRsoQi0bJEIhIRsoQi0bJEIhIRsoQi0bJEIhIRsoQi0b JEIhIRsoQi0bJEIhIRsoQi0bJEIhIRsoQi0bJEIhIRsoQi0bJEIhIRsoQi0bJEIhIRsoQi0bJEIh IRsoQi0bJEIhIRsoQi0bJEIhIRsoQi0bJEIhIRsoQi0bJEIhIRsoQi0bJEIhIRsoQi0bJEIhIRso Qi0bJEIhIRsoQi0bJEIhIRsoQi0bJEIhIRsoQi0bJEIhIRsoQg0KDQpodHRwOi8vYXdnLndlYmNo dS5jb20vY2FzYW5vdmEvPzE5MjYNCg0KDQoNCg0KDQoNCg0KDQoNCg0KGyRCJWEhPCVrSVRNVyRK Sn0kTyQzJEEkaSItGyhCDQpjb25jZXB0Ml9uZXRAeWFob28uY2ENCg0K From doelle@indiya.com Sun Feb 05 06:58:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5iXI-0004wc-8z for ipfix-archive@megatron.ietf.org; Sun, 05 Feb 2006 06:58:32 -0500 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 GAA01563 for ; Sun, 5 Feb 2006 06:56:32 -0500 (EST) Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F5iFj-0003zx-00 for ipfix-list@mil.doit.wisc.edu; Sun, 05 Feb 2006 05:40:23 -0600 Received: from 145746872 (CMPC016-195.CNet2.Gawex.PL [84.205.16.195]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k15BeKn8015584 for ; Sun, 5 Feb 2006 05:40:22 -0600 Received: from indiya.com (145386904 [145600352]) by CMPC016-195.CNet2.Gawex.PL (Qmailv1) with ESMTP id C7F8445E0A for ; Sun, 05 Feb 2006 15:39:42 -0800 Date: Sun, 05 Feb 2006 15:39:42 -0800 From: "'Quick Loss Weight' Team" X-Mailer: The Bat! (v2.00.1) Personal X-Priority: 3 Message-ID: <5899016305.20060205153942@indiya.com> To: Ipfix Subject: Looking for Managers in New Zealand MIME-Version: 1.0 Content-Type: text/plain X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp.doit.wisc.edu id k15BeKn8015584 Content-Transfer-Encoding: quoted-printable Hello Dear 'Quick Loss Weight' News Subscriber! Thank you for paying attention to our unique loss weight products and tre= atment complexes and for subscribing to the regular news announcements of= our company.=20 Today we would like to announce the unique business proposal of our compa= ny =91Be Graceful and Make Money=92. This proposal can interest not only = the individuals who care about their weight but also for whose who are lo= oking for additional income. So if you are not interested in our proposit= ion you can advice it to your neighbors or friends who are looking for pa= rt-time job. You can find brief job description in this news letter. 'Quick Loss Weight' is the USA self-owned company which develops and dist= ributes various medicines and food additives for losing weight. Three yea= rs ago due to Internet technologies we entered the international market o= f such products. =91Quick Loss Weight=92 is one of the leading companies in Internet marke= t of health products. But in 2004 we faced the problem of getting the int= ernational payments from our clients abroad because of the leading paymen= t systems which decreased the limits of on-line payments by credit cards.= That is why we had the negative sale results at the end of the 2004. At that time the management of the company decided to create the network = of financial agents in the countries with the most perspective sales mark= et and to save time and funds by receiving payments in the local banks in= the countries of our clients=92 residence. So we could solve the several= problems like fast payment receiving and widened the area of the product= s distribution. Also that business decision helped us to increase the sales volume. Now w= e faced the situation that our managers do not cope all the payments they= have to process. So the =91Quick Loss Weight=92 starts the new limited recruiting campaign. The main duty of the agents to receive payments from our clients to his o= r her own bank account with future forwarding to the company=92s represen= tative. Each agent receives 5% from each successfully processed payment. = All the new agents will get extra bonuses for their summer vacations with= total amount of $1500. The number of vacancies is limited. The successf= ul candidates will support client's online and sales business, using thei= r best skills. Basic responsibilities will include ensuring of sales bank= ing activities, and identifying and actioning cross-sales opportunities. = No special education is required. In other words our company requires par= t time persons for which the salary will be on a pro rata basis. The part= -time hours of work are flexible. Currently managers from New Zealand are urgently required. Residents of Australia, United Kingdom, Germany and Spain are also welcom= ed to apply for this position. Email your letters of interest to vacancy@quick-loss-weight.com. Please s= pecify your name, age and country of permanent residence. You can find the additional information about this vacancy on www.quick-l= oss-weight.com or send the letter of interest to vacancy@quick-loss-weigh= t.com and you will be sent the detailed information. We hope that our news will help you to find the best products and prices.= There are always a lot of new items, treatments and business solutions i= n our news. Feel free to contact us with all your questions and propositi= ons by e-mail info@quick-loss-weight.com. Also our mangers can help you i= n choosing the best treatment complexes, which suits you only. -- Best regards, 'Quick Loss Weight' Team info@quick-loss-weight.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D If you've received this email mistakenly and/or you are not subscribed to= our news, just send an email to unsubscribe@quick-loss-weight.com and you'll be rem= oved from the mailing list immediately. Sorry for any possible inconveniences =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From coopqfvnda@amazon.com Mon Feb 06 14:26:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6C0O-0000sG-Nk for ipfix-archive@megatron.ietf.org; Mon, 06 Feb 2006 14:26:32 -0500 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 OAA14750 for ; Mon, 6 Feb 2006 14:24:51 -0500 (EST) Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F6Bid-0006Ag-00 for ipfix-list@mil.doit.wisc.edu; Mon, 06 Feb 2006 13:08:11 -0600 Received: from amazon.com (dsl-145-250-187.telkomadsl.co.za [165.145.250.187]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k16J82Oj014029 for ; Mon, 6 Feb 2006 13:08:05 -0600 Date: Mon, 6 Feb 2006 13:08:02 -0600 Message-Id: <200602061908.k16J82Oj014029@smtp.doit.wisc.edu> From: "ipfix-list@mil.doit.wisc.edu" To: ipfix-list Subject: WINNING NOTIFICATION!!!!!!!!!!!!!!!! X-Priority: 3 X-MSMail-Priority: Normal Reply-To: "ipfix-list@mil.doit.wisc.edu" mime-version: 1.0 content-type: multipart/mixed; boundary="qzsoft_directmail_seperator" --qzsoft_directmail_seperator Content-Type: text/plain; charset="DEFAULT" Content-Transfer-Encoding: base64 CgoKR09WRVJOTUVOVCBBQ0NSRURJVEVEIExJQ0VOU0VEISEhClVLTE9UVEVSWU9OTElORSBJTlRF Uk5BVElPTkFMIExPVFRFUlkKSVMgUkVHSVNURVJFRCBVTkRFUiBUSEUgREFUQSBQUk9URUNUSU9O IEFDVCBPRjsKKFJlZ2lzdHJhdGlvbiBaNzIwNjMzWCkuCi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uCgpUcm9waWNhbCAgTG90dGVyeSBIZWFkcXVhcnRlcnMuClBST01PVElPTlMv UFJJWkUgQVdBUkQgREVQVAo5IEdyZWVud2ljaCBQYXJrCkNoYXJsdG9uIFdheSwgU0UxMApMT05E T04sRU5HTEFORCwKVU5JVEVEIEtJTkdET00KUkVGOiBVSy8xMjQ0ODkwMC8yMDA2LgpCQVRDSDog ODgvNTU3NzkzL1VLL1VLUSAKCkFUVEVOVElPTiA6VEhFIE9XTkVSIE9GIFRISVMgRU1BSUwgQURE UkVTUwogICAgICAgICAgICAgICAgICAgICAgICAgICAgCgpSRTogV0lOTklORyBOT1RJRklDQVRJ T04KCldlIGhhcHBpbHkgYW5ub3VuY2UgdG8geW91IHRoZSBkcmF3IG9mIHRoZSBUcm9waWNhbCBM b3R0ZXJ5IEludGVybmF0aW9uYWwgcHJvZ3JhbXMgaGVsZCBvbiB0aGUgNFRIb2YgRkVCUlVBUlkg MjAwNix0aGUgcmVzdWx0cyB3ZXJlcmVsZWFzZWQgb24gdGhlIDZUSCBGRUJSVUFSWSwgMjAwNiBp biBMb25kb24uIFlvdXIgZS1tYWlsIGFkZHJlc3MgYXR0YWNoZWQgdG8gdGlja2V0IG51bWJlcjog IDU3NTYwMDg0NjE3NyB3aXRoIHNlcmlhbCBudW1iZXIgNDU5OS8wMyBkcmV3IHRoZSBsdWNreSBu dW1iZXJzOiAzMS02LTI2LTEzLTM1LTcsd2hpY2ggc3Vic2VxdWVudGx5IHdvbiB5b3UgdGhlIGxv dHRlcnkgaW4gdGhlIDJuZCBjYXRlZ29yeS4KCllvdSBoYXZlIHRoZXJlZm9yZSBiZWVuIGFwcHJv dmVkIHRvIGNsYWltIGEgdG90YWwgc3VtIG9mIKMyLDUwMCwwMDAuMDAgIChUd28gTWlsbGlvbiBm aXZlIGh1bmRyZWQgdGhvdXNhbmQgUE9VTkQgU1RFUkxJTkcpIGluIGNhc2ggY3JlZGl0ZWQgdG8g ZmlsZSBpbiBjYXNoIHdoaWNoIGlzIGRlcG9zaXRlZCB3aXRoIGEgRmluYW5jZSAmIFNlY3VyaXR5 IENvbXBhbnkgaW4geW91cgpmYXZvdXIgYXMgYmVuZWZpY2lhcnkgYW5kIGNvdmVyZWQgd2l0aCBI SUdIIElOU1VSQU5DRSBQT0xJQ1kuCgoKQWxsIHBhcnRpY2lwYW50cyB3ZXJlIHNlbGVjdGVkIHJh bmRvbWx5IGZyb20gd29ybGQgd2lkZSB3ZWIgc2l0ZXMgdGhyb3VnaCBhIGNvbXB1dGVyIGRyYXdu IHN5c3RlbSBhbmQKZXh0cmFjdGVkIGZyb20gb3ZlciAxMDAsMDAwIGNvbXBhbmllcy4gVGhpcyBw cm9tb3Rpb24gdGFrZXMgcGxhY2UgYW5udWFsbHkuIAoKUGxlYXNlIG5vdGUgdGhhdCB5b3VyIGx1 Y2t5IHdpbm5pbmcgbnVtYmVyIGZhbGxzIHdpdGhpbiBvdXIgYm9va2xldCByZXByZXNlbnRhdGl2 ZSBvZmZpY2UgaW4gRXVyb3BlIGFzCmluZGljYXRlZCBpbiBvdXIgcGxheSBjb3Vwb24uIEluIHZp ZXcgb2YgdGhpcywgeW91ciCjMiw1MDAsMDAwLjAwICAoVHdvIE1pbGxpb24gZml2ZSBodW5kcmVk IHRob3VzYW5kIFBPVU5EIFNURVJMSU5HKSB3b3VsZCBiZSByZWxlYXNlZCB0byB5b3UgYnkgb3Vy IGFmZmlsaWF0ZSBGaW5hbmNlICYgU2VjdXJpdHkgQ29tcGFueSAgaW4gTG9uZG9uIGFzIHNvb24g YXMgeW91IAplc3RhYmxpc2ggY29udGFjdC4KCiAgClBsZWFzZSBiZSB3YXJuZWQuIFRvIGZpbGUg Zm9yIHlvdXIgY2xhaW0sIGNvbnRhY3Qgb3VyIGZpZHVjaWFyeSBhZ2VudCB3aXRoIHRoZSBiZWxv dyBkZXRhaWxzOwoKQ09OVEFDVCBOQU1FOkdFUkFMRCBBTkRFUlRPTgpDSVRZLyBDT1VOVFJZOiBM b25kb24uCiAgICAgICAgICAgICAgICAgVEVMOiArNDQtNzA0MDEyNTgxMwogICAgICAgICAgICAg ICAgIEZBWDogKzQ0LTg3MDM4OTAyNDYKICAgICAgICAgICAgICAgICBFbWFpbDp0cm9waWNhbF9h Z2VudDAwMUBrLnJvCiAgICAgICAgICAgICAgICAKClRvIGF2b2lkIHVubmVjZXNzYXJ5IGRlbGF5 cyBhbmQgY29tcGxpY2F0aW9ucywgcXVvdGUgeW91ciByZWZlcmVuY2UvYmF0Y2ggbnVtYmVycyBp biBhbnkgY29ycmVzcG9uZGVuY2VzIHdpdGggdXMgb3IKb3VyIGRlc2lnbmF0ZWQgYWdlbnQuIENv bmdyYXR1bGF0aW9ucyBvbmNlIG1vcmUuCgpZb3VycyBmYWl0aGZ1bGx5LApNcnMuIEFOR0VMQSBL SU4KRW1haWw6dHJvcGljYWxfYWdlbnQwMDJAay5ybwpab25lIENvLW9yZGluYXRvci4KICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBNYXRlcmlhbCBDb3B5cmlnaHQgqSAyMDA2IFRoZSBMb3R0 ZXJ5IENvLiBMdGQu --qzsoft_directmail_seperator-- From 1boon-hwe@a2.mbn.or.jp Mon Feb 06 20:24:42 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Hb0-0003wk-GY for ipfix-archive@megatron.ietf.org; Mon, 06 Feb 2006 20:24:42 -0500 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 UAA02421 for ; Mon, 6 Feb 2006 20:22:54 -0500 (EST) Received: from cpe-66-24-123-182.stny.res.rr.com ([66.24.123.182]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1F6HNF-0007gv-00 for ipfix-list@mil.doit.wisc.edu; Mon, 06 Feb 2006 19:10:29 -0600 Message-ID: <28a401c62b81$f07c1b1e$94c600c8@a2.mbn.or.jp> From: "Carol A. Ross" <1boon-hwe@a2.mbn.or.jp> To: ipfix-list@mil.doit.wisc.edu Subject: =?iso-8859-1?B?UG9wdWxhciBzb2Z0IC0gYm90dG9tIHByaWNlcw==?= Date: Tue, 07 Feb 2006 00:56:58 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_FD9BD7A8.6E3A3424" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?66.24.123.182 This is a multi-part message in MIME format. ------=_NextPart_000_0000_FD9BD7A8.6E3A3424 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_D567678F.C35E876D" ------=_NextPart_001_0001_D567678F.C35E876D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Don't overpay for software! Get it with a 75% discount! http://www.allsoftpossible.com __________________ To change, go here ------=_NextPart_001_0001_D567678F.C35E876D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Don't overpay for software!
Get it with a 75% discount!

http://www.allsoftpossible.com


__________________
To change, go here

------=_NextPart_001_0001_D567678F.C35E876D-- ------=_NextPart_000_0000_FD9BD7A8.6E3A3424-- From majordomo@mil.doit.wisc.edu Tue Feb 07 11:09:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6VPd-0001NL-Lf for ipfix-archive@megatron.ietf.org; Tue, 07 Feb 2006 11:09:54 -0500 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 LAA07007 for ; Tue, 7 Feb 2006 11:08:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F6V4d-0007FN-00 for ipfix-list@mil.doit.wisc.edu; Tue, 07 Feb 2006 09:48:11 -0600 Received: from beniaminus.red.cert.org ([192.88.209.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F6V4b-0007EY-00 for ipfix-info@net.doit.wisc.edu; Tue, 07 Feb 2006 09:48:09 -0600 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.16) with ESMTP id k17Fm521016405 for ; Tue, 7 Feb 2006 10:48:07 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k17FlJnp016351 for ; Tue, 7 Feb 2006 10:47:19 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k17FlI1v016349; Tue, 07 Feb 2006 10:47:19 -0500 (EST) Received: from [128.237.249.38] (vpn-10-25-4-12.remote.cert.org [10.25.4.12]) by villemus.indigo.cert.org (8.12.11/8.12.11/2.53) with ESMTP id k17FlIAW013343; Tue, 7 Feb 2006 10:47:18 -0500 In-Reply-To: <20060207151142.GA18424@localhost.localdomain> References: <43E75136.9060509@fokus.fraunhofer.de> <85F86ADC-BB27-4617-A848-43CCC210945C@cert.org> <20060207151142.GA18424@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2--41239908" Message-Id: Cc: Elisa Boschi , Lutz Mark , Elisa Boschi , yann@bashibuzuk.net Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: [ipfix-info] Re: draft-boschi-ipfix-biflow and software implementation Date: Tue, 7 Feb 2006 10:47:13 -0500 To: Alexandre Dulaunoy , ipfix-info@net.doit.wisc.edu X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000004 X-Scanned-By: MIMEDefang 2.54 on 192.88.209.10 Precedence: bulk Sender: majordomo listserver This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2--41239908 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Alexandre, On Feb 7, 2006, at 10:11 AM, Alexandre Dulaunoy wrote: > I'll try to "over" summarize back what I understand with the > information you gave me and the draft > (draft-boschi-export-perpktinfo-01.txt) : > > The FlowID is a 32bit id unique across one observation point and is > (always?) generated by the exporter. > > We (at SES ASTRA and CSRRT-LU) are trying to generate a > "unique/calculable" FlowID among a specify dataset of records. Why ? > We have a bunch of "exporters" (routers, devices) with various > versions of Netflow and we have to live with that for the time > being. What we are doing currently ? we use a simple hash function to > generate a "unique" FlowID per data set based on source/destination > IP, source/destination PORT and (protocol). We use the lowest > source/destination (IP/PORT) to generate a unified hash id per biflow. > > So it seems that I was mixing our and your definition of FlowID but > what do you think ? Can we call that a FlowID or something else ? > Have you think of a 'possible' function to generate a FlowID based on > records ? Like that, we can rebuild biflow(s) from uniflow(s) ? Does > it make sense ? flowId, as defined in -info-11, does not presently appear flexible enough to cover this use case; its "unique within Observation Domain" constraint appears to make multiple Flow Records sharing the same flowId impossible. Thinking about it for a moment, I think this is a fault in the information model. To increase the flexibility of this IE, I'd propose changing its definition to the following: 5.1.7. flowId Description: An identifier of a Flow that is unique within an Observation Domain. This Information Element can be used to distinguish between different Flows if Flow Keys such as IP addresses and port numbers are not reported or reported in separate records. Multiple Flow Records observed within the same Observation Domain may share the same flowId if they describe the same Flow as determined by the Metering Processes within that Domain. Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId: 148 Status: current (Elisa - this also expands flowId as required for -biflow-02 section 3.2) > Brian : A site note, looking into naf source code (the pcap exporter), > I can't find the part of generating the FlowID. Can you point me to > the correct part ? We don't actually use the flowId anywhere (hence the cheating) - we do single-record biflow export per draft-boschi-ipfix-biflow section 3.4 (section 4 in the forthcoming -02 draft), with CERT-private IEs standing in for IANA-assigned IEs pending completion of that draft. The relevant code is in nafcore.c. NAF unifies uniflows (from pcap or SiLK) into biflows the hard way; SiLK asymmetric unidirectional data is collected using the SiLK tools' proprietary protocol into a single database, relevant records are selected out of that database and sorted by time, mingling incoming and outgoing records and re- matching them before aggregation. YAF also cheats; it's designed solely for deployment at symmetric routing points, or for use on packet capture data that can be prearranged to appear to have come from a symmetric routing point. Regards, Brian --Apple-Mail-2--41239908 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.4.2 (Darwin) iD8DBQFD6MEF4/8LCZ4pwvYRAuilAKCRzBsZKdUEgjmJJpYI4TSqMM2WXwCfcPVc LNB3c/kAxC9oALerBraP80k= =+MdZ -----END PGP SIGNATURE----- --Apple-Mail-2--41239908-- -- 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 ron@bortech.ac.za Wed Feb 08 10:05:23 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6qsl-0003JQ-Jg for ipfix-archive@megatron.ietf.org; Wed, 08 Feb 2006 10:05:23 -0500 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 KAA29602 for ; Wed, 8 Feb 2006 10:03:33 -0500 (EST) Received: from s01060050bac7d504.vs.shawcable.net ([24.86.188.104] helo=bortech.ac.za) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1F6qTH-0002dT-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 Feb 2006 08:39:03 -0600 Message-ID: <000001c62cbd$5c8be170$8e96a8c0@somnifacient> Reply-To: "Ronaldo Pewitt" From: "Ronaldo Pewitt" To: "Wapasha Feldt" Subject: Re: q Y news 695 Date: Wed, 8 Feb 2006 09:38:43 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62C93.73B5D970" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?24.86.188.104 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62C93.73B5D970 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, http://www.makesta.com =20 VqAqLmlaUkMn r$j1r,r2l1a ViItAhGrRnAg h$b3m,z7j5a CwIdAvLsIfSm t$v3l,w3w3n ------=_NextPart_000_0001_01C62C93.73B5D970 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
VqAqLmlaUkMn r$j1r,r2l1a
ViItAhGrRnAg h$b3m,z7j5a
CwIdAvLsIfSm t$v3l,w3w3n
------=_NextPart_000_0001_01C62C93.73B5D970-- From majordomo@mil.doit.wisc.edu Thu Feb 09 05:37:59 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F79BX-00083P-2X for ipfix-archive@megatron.ietf.org; Thu, 09 Feb 2006 05:37:59 -0500 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 FAA07480 for ; Thu, 9 Feb 2006 05:36:15 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F78re-0007dW-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Feb 2006 04:17:26 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F78rc-0007dP-00 for ipfix@net.doit.wisc.edu; Thu, 09 Feb 2006 04:17:25 -0600 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k19AHNF26414 for ; Thu, 9 Feb 2006 11:17:23 +0100 (CET) Received: from [10.61.64.217] (ams-clip-vpn-dhcp217.cisco.com [10.61.64.217]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k19AHMC27414; Thu, 9 Feb 2006 11:17:22 +0100 (CET) Message-ID: <43EB16B3.4010008@cisco.com> Date: Thu, 09 Feb 2006 11:17:23 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Johnson CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Floating point numbers in IPFIX References: <43A1AC10.2000805@cisco.com> In-Reply-To: <43A1AC10.2000805@cisco.com> Content-Type: multipart/alternative; boundary="------------070401070804020907010102" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------070401070804020907010102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, In an attempt to summarize all this thread conclusion, I have inserted the following text. Regards, Benoit. 6R6.2 Reduced Size Encoding of Integer and Float Types Information Elements containing integer, string, float, and octetarray types in the information model MAY be encoded using fewer octets than those implied by their type in the information model definition [IPFIX-INFO], based on the assumption that the smaller type is sufficient to carry any value the Exporter may need to deliver. This reduces the network bandwidth requirement between the Exporter and the Collector. Note that the Information Element definitions [IPFIX-INFO] will always define the maximum encoding size. For instance the information model [IPFIX-INFO] defines byteCount as an unsigned64 type, which would require 64-bits. However if the Exporter will never locally encounter the need to send a value larger than 4294967295, it may chose to send the value instead as an unsigned32. For example, a core router would require an unsigned64 byteCount while an unsigned32 might be sufficient for an access router. This behavior is indicated by the Exporter by specifying a type size with a smaller length than that associated with the assigned type of the Information Element. In the example above the Exporter would place a length of 4 versus 8 in the template. If reduced sizing is used, it MUST only be applied to the following integer types: unsigned64, signed64, unsigned32, signed32, unsigned16, signed16. The same signed versus unsigned property MUST be preserved. The reduction in size can be to any number of octets smaller than the original type if the data value still fits, i.e. so that only leading zeroes are dropped. For example, an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s). Reduced sizing can also be used on the float64 and float32. The float32 not only has a reduced number range, but due to the smaller mantissa is also less precise. The reduced size encoding MUST NOT be applied to dateTimeMicroSeconds or to dateTimeNanoSeconds because these represent an inherent structure that would be destroyed by using less than the original number of bytes. > Hi all > > In the IPFIX protocol draft, section 3.1.5, we have a definition > of a floating point number. This definition allows export of > floating point numbers using the 32-bit format as specified in > IEEE.754. This same standard also allows floating point numbers > to be defined in a 64-bit format. > > I would like to see a float64 type added and the abiltity to > send float64 fields using float32 using a variation of the > Reduced Size Encoding as used with the integers. > > I would like to propose that at the next editing phase we add > the following type to the information model: > > 3.1.6. float64 > > The type "float64" corresponds to an IEEE double-precision 64-bit > floating point type as defined in [IEEE.754.1985]. > > > In the protocol, section 6.2 could also be expanded to encompase > the Reduced Size encoding for the floating point types. i.e. > > 6.2 Reduced Size Encoding of Integer Types > Information Elements containing integer, float, string, and ... > ^^^^^^^ > octetarray types in the information model MAY be encoded using fewer > octets than those implied by their type in the information model > definition [IPFIX-INFO], ... > > ... > If reduced sizing is used, it MUST only be applied to the following > integer types: unsigned64, signed64, unsigned32, signed32, > unsigned16, signed16. ... > > @@[NOTE: the signed types above are not in the data model]@@ > > Reduced sizing can also be used on the float64 and float32. The > float32 not only has a reduced number range, but due to the > smaller mantissa is also less precise. > > The reduced size encoding MUST NOT be applied to ... > > > Andrew > > > -- > 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/ --------------070401070804020907010102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

In an attempt to summarize all this thread conclusion, I have inserted the following text.

Regards, Benoit.

6R6.2 Reduced Size Encoding of Integer and Float Types

Information Elements containing integer, string, float, and octetarray types in the information model MAY be encoded using fewer octets than those implied by their type in the information model definition [IPFIX-INFO], based on the assumption that the smaller type is sufficient to carry any value the Exporter may need to deliver.  This reduces the network bandwidth requirement between the Exporter and the Collector.  Note that the Information Element definitions [IPFIX-INFO] will always define the maximum encoding size.

For instance the information model [IPFIX-INFO] defines byteCount as an unsigned64 type, which would require 64-bits.  However if the Exporter will never locally encounter the need to send a value larger than 4294967295, it may chose to send the value instead as an unsigned32.  For example, a core router would require an unsigned64 byteCount while an unsigned32 might be sufficient for an access router.

This behavior is indicated by the Exporter by specifying a type size with a smaller length than that associated with the assigned type of the Information Element.  In the example above the Exporter would place a length of 4 versus 8 in the template.

If reduced sizing is used, it MUST only be applied to the following integer types: unsigned64, signed64, unsigned32, signed32, unsigned16, signed16.  The same signed versus unsigned property MUST be preserved.  The reduction in size can be to any number of octets smaller than the original type if the data value still fits, i.e. so that only leading zeroes are dropped. For example, an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s).

Reduced sizing can also be used on the float64 and float32.  The float32 not only has a reduced number range, but due to the smaller mantissa is also less precise.

The reduced size encoding MUST NOT be applied to dateTimeMicroSeconds or to dateTimeNanoSeconds because these represent an inherent structure that would be destroyed by using less than the original number of bytes.


Hi all

In the IPFIX protocol draft, section 3.1.5, we have a definition
of a floating point number.  This definition allows export of
floating point numbers using the 32-bit format as specified in
IEEE.754.  This same standard also allows floating point numbers
to be defined in a 64-bit format.

I would like to see a float64 type added and the abiltity to
send float64 fields using float32 using a variation of the
Reduced Size Encoding as used with the integers.

I would like to propose that at the next editing phase we add
the following type to the information model:

3.1.6.  float64

The type "float64" corresponds to an IEEE double-precision 64-bit
floating point type as defined in [IEEE.754.1985].


In the protocol, section 6.2 could also be expanded to encompase
the Reduced Size encoding for the floating point types. i.e.

6.2      Reduced Size Encoding of Integer Types
 Information Elements containing integer, float, string, and ...
                                          ^^^^^^^
 octetarray types in the information model MAY be encoded using fewer
 octets than those implied by their type in the information model
 definition [IPFIX-INFO], ...

 ...
   If reduced sizing is used, it MUST only be applied to the following  integer types: unsigned64, signed64, unsigned32, signed32,  unsigned16, signed16.  ...

@@[NOTE: the signed types above are not in the data model]@@

 Reduced sizing can also be used on the float64 and float32.  The
 float32 not only has a reduced number range, but due to the
 smaller mantissa is also less precise.

 The reduced size encoding MUST NOT be applied to ...


Andrew


--
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/

--------------070401070804020907010102-- -- 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 09 05:43:43 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F79Gu-0000Zj-OB for ipfix-archive@megatron.ietf.org; Thu, 09 Feb 2006 05:43:43 -0500 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 FAA07869 for ; Thu, 9 Feb 2006 05:41:41 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F78y3-0000Vs-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Feb 2006 04:24:03 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F78y2-0000Vh-00 for ipfix@net.doit.wisc.edu; Thu, 09 Feb 2006 04:24:02 -0600 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k19AO1326893; Thu, 9 Feb 2006 11:24:01 +0100 (CET) Received: from [10.61.64.217] (ams-clip-vpn-dhcp217.cisco.com [10.61.64.217]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k19ANxC04824; Thu, 9 Feb 2006 11:24:00 +0100 (CET) Message-ID: <43EB183F.6080204@cisco.com> Date: Thu, 09 Feb 2006 11:23:59 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Nevil Brownlee CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IANA assigns sctp port 4739 to IPFIX References: <1138842841.e2594a1cd7fa6@webmail.auckland.ac.nz> In-Reply-To: <1138842841.e2594a1cd7fa6@webmail.auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Thanks Nevil, The protocol draft is now updated. Regards, Benoit. > Hi all: > > I've just received the note below from IANA. > > Now we have 4739 allocated to IPFIX for sctp, tcp and udp. > > Cheers, Nevil > > ----- Forwarded message from iana-ports-usr@icann.org ----- > Date: Wed, 1 Feb 2006 16:19:38 -0800 > From: iana-ports-usr@icann.org > Reply-To: iana-ports-usr@icann.org > Subject: RE: Application for port-number: ipfix (Assigned-4739) [I06-050814-0000] > To: n.brownlee@auckland.ac.nz > > > Dear Nevil Brownlee, > > We have assigned the following user port number with you as the point of contact: > > ipfix 4739/sctp IP Flow Info Export > # Nevil Brownlee <n.brownlee@auckland.ac.nz> January 2006 > > See: <http://www.iana.org/assignments/port-numbers> > > Please notify the IANA if there is a change in contact information by > completing the following template: > > <http://www.iana.org/cgi-bin/mod_portno.pl> > > Thank you, > > Pearl Liang > IANA > > *************************************************************** > Internet Assigned Numbers Authority (IANA) > 4676 Admiralty Way, Suite 330 > Marina del Rey, California 90292 > > Voice: (310) 823-9358 > FAX: (310) 823-8649 > email: iana-ports@iana.org > *************************************************************** > > > > ----- End forwarded message ----- > > > ----------------------------------------------------------------------- > 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/ > -- 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 09 05:54:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F79RE-0005Bw-P8 for ipfix-archive@megatron.ietf.org; Thu, 09 Feb 2006 05:54:14 -0500 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 FAA08798 for ; Thu, 9 Feb 2006 05:52:21 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F79C3-0003Hx-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Feb 2006 04:38:31 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F79C2-0003Hm-00 for ipfix@net.doit.wisc.edu; Thu, 09 Feb 2006 04:38:30 -0600 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k19AcSq27871; Thu, 9 Feb 2006 11:38:28 +0100 (CET) Received: from [10.61.64.217] (ams-clip-vpn-dhcp217.cisco.com [10.61.64.217]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k19AcSC21796; Thu, 9 Feb 2006 11:38:28 +0100 (CET) Message-ID: <43EB1BA2.1080305@cisco.com> Date: Thu, 09 Feb 2006 11:38:26 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Brian Trammell CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] spelling/editorial change to time data types References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040803070603030000010107" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------040803070603030000010107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, > All, > > May be a bit late for this, and may also be a bit pedantic, but I'd > like to advocate correcting the spelling of the data type names: > > 3.1.11. dateTimeMilliSeconds . . . . . . . . . . . . . . . . 12 > 3.1.12. dateTimeMicroSeconds . . . . . . . . . . . . . . . . 12 > 3.1.13. dateTimeNanoSeconds . . . . . . . . . . . . . . . . . 12 > > and their associated information elements: > > 5.8.3. flowStartMilliSeconds . . . . . . . . . . . . . . . . 58 > 5.8.4. flowEndMilliSeconds . . . . . . . . . . . . . . . . . 58 > 5.8.5. flowStartMicroSeconds . . . . . . . . . . . . . . . . 58 > 5.8.6. flowEndMicroSeconds . . . . . . . . . . . . . . . . . 58 > 5.8.7. flowStartNanoSeconds . . . . . . . . . . . . . . . . 58 > 5.8.8. flowEndNanoSeconds . . . . . . . . . . . . . . . . . 59 > 5.8.9. flowStartDeltaMicroSeconds . . . . . . . . . . . . . 59 > 5.8.10. flowEndDeltaMicroSeconds . . . . . . . . . . . . . . 59 > 5.8.11. systemInitTimeMilliSeconds . . . . . . . . . . . . . 59 > 5.10.4. flowDurationMilliSeconds . . . . . . . . . . . . . . 67 > 5.10.5. flowDurationMicroSeconds . . . . . . . . . . . . . . 68 > > in IPFIX-INFO 11 and normative references thereto in IPFIX-PROTO 17: > > 6.1.7 dateTimeMilliSeconds.....................................30 > 6.1.8 dateTimeNanoSeconds......................................30 > 6.1.9 dateTimeMicroSeconds.....................................30 > > Addition of an SI prefix does not cause a word break, as implied by > the interCap spelling of these identifiers. Suggested correction is to > make the "s" in seconds lower-case. This change would of course not > apply to dateTimeSeconds, as there _is_ a word break before "Seconds" > in that case. > > (Incidentially, I discovered this problem while testing our > implementation, attempting to find the flowStartMilliseconds (properly > spelled) IE in our IE registry, which caused a runtime error. Other > implementors and users of IPFIX may also run into the same problem in > the future, hence this suggestion.) > > Also, there are references to flowStartDeltaUseconds and > flowEndDeltaUseconds in PROTO 19; these should be changed to > "DeltaMicroseconds". Good catch! As there were no positive reaction from this community to change the "S" of seconds to lower case, I changed [IPFIX-PROTO] to flowStartDeltaMicroSeconds and flowEndDeltaMicroSeconds... to be consistent with [IPFIX-INFO]. Regards, Benoit. > > Regards, > > Brian --------------040803070603030000010107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian,
All,

May be a bit late for this, and may also be a bit pedantic, but I'd like to advocate correcting the spelling of the data type names:

       3.1.11. dateTimeMilliSeconds  . . . . . . . . . . . . . . . .  12
       3.1.12. dateTimeMicroSeconds  . . . . . . . . . . . . . . . .  12
       3.1.13. dateTimeNanoSeconds . . . . . . . . . . . . . . . . .  12

and their associated information elements:

       5.8.3.  flowStartMilliSeconds . . . . . . . . . . . . . . . .  58
       5.8.4.  flowEndMilliSeconds . . . . . . . . . . . . . . . . .  58
       5.8.5.  flowStartMicroSeconds . . . . . . . . . . . . . . . .  58
       5.8.6.  flowEndMicroSeconds . . . . . . . . . . . . . . . . .  58
       5.8.7.  flowStartNanoSeconds  . . . . . . . . . . . . . . . .  58
       5.8.8.  flowEndNanoSeconds  . . . . . . . . . . . . . . . . .  59
       5.8.9.  flowStartDeltaMicroSeconds  . . . . . . . . . . . . .  59
       5.8.10. flowEndDeltaMicroSeconds  . . . . . . . . . . . . . .  59
       5.8.11. systemInitTimeMilliSeconds  . . . . . . . . . . . . .  59
       5.10.4. flowDurationMilliSeconds  . . . . . . . . . . . . . .  67
       5.10.5. flowDurationMicroSeconds  . . . . . . . . . . . . . .  68

in IPFIX-INFO 11 and normative references thereto in IPFIX-PROTO 17:

     6.1.7   dateTimeMilliSeconds.....................................30
     6.1.8   dateTimeNanoSeconds......................................30
     6.1.9   dateTimeMicroSeconds.....................................30

Addition of an SI prefix does not cause a word break, as implied by the interCap spelling of these identifiers. Suggested correction is to make the "s" in seconds lower-case. This change would of course not apply to dateTimeSeconds, as there _is_ a word break before "Seconds" in that case.

(Incidentially, I discovered this problem while testing our implementation, attempting to find the flowStartMilliseconds (properly spelled) IE in our IE registry, which caused a runtime error. Other implementors and users of IPFIX may also run into the same problem in the future, hence this suggestion.)

Also, there are references to flowStartDeltaUseconds and flowEndDeltaUseconds in PROTO 19; these should be changed to "DeltaMicroseconds".

Good catch!
As there were no positive reaction from this community to change the "S" of seconds to lower case, I changed [IPFIX-PROTO] to flowStartDeltaMicroSeconds and flowEndDeltaMicroSeconds... to be consistent with [IPFIX-INFO].

Regards, Benoit.

Regards,

Brian

--------------040803070603030000010107-- -- 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 09 09:12:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7CWm-0000d2-N3 for ipfix-archive@megatron.ietf.org; Thu, 09 Feb 2006 09:12:10 -0500 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 JAA24413 for ; Thu, 9 Feb 2006 09:10:20 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F7CRC-0005Db-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Feb 2006 08:06:22 -0600 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F7CRA-0005DP-00 for ipfix@net.doit.wisc.edu; Thu, 09 Feb 2006 08:06:20 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 5D8092007D79; Thu, 9 Feb 2006 15:06:19 +0100 (CET) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03451-04; Thu, 9 Feb 2006 15:06:19 +0100 (CET) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 386CB200019C; Thu, 9 Feb 2006 15:06:19 +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] Floating point numbers in IPFIX Date: Thu, 9 Feb 2006 15:06:07 +0100 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_012F_01C62D8A.596F21F0" Message-ID: <6D28EBC684A4D94096217AD2FE400873075EE1@venus.office> X-MS-Has-Attach: yes Thread-Topic: [ipfix] Floating point numbers in IPFIX Thread-Index: AcYtalmTst3peAp9TCK2DUYf+K62PAAFxegQ From: "Thomas Dietz" To: "Benoit Claise" , "Andrew Johnson" Cc: X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_012F_01C62D8A.596F21F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0130_01C62D8A.596F21F0" ------=_NextPart_001_0130_01C62D8A.596F21F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Dear Benoit and all, I agree to your proposal but would add a sentence like: When reducing the size of a float type make sure that the precision is not reduced due to the smaller mantissa. You could make it more strong in writing "MUST make sure" but I think that's not needed. Best Regards, Thomas -- Thomas Dietz Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany _____ From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Benoit Claise Sent: Thursday, February 09, 2006 11:17 AM To: Andrew Johnson Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Floating point numbers in IPFIX Dear all, In an attempt to summarize all this thread conclusion, I have inserted the following text. Regards, Benoit. 6R6.2 Reduced Size Encoding of Integer and Float Types Information Elements containing integer, string, float, and octetarray types in the information model MAY be encoded using fewer octets than those implied by their type in the information model definition [IPFIX-INFO], based on the assumption that the smaller type is sufficient to carry any value the Exporter may need to deliver. This reduces the network bandwidth requirement between the Exporter and the Collector. Note that the Information Element definitions [IPFIX-INFO] will always define the maximum encoding size. For instance the information model [IPFIX-INFO] defines byteCount as an unsigned64 type, which would require 64-bits. However if the Exporter will never locally encounter the need to send a value larger than 4294967295, it may chose to send the value instead as an unsigned32. For example, a core router would require an unsigned64 byteCount while an unsigned32 might be sufficient for an access router. This behavior is indicated by the Exporter by specifying a type size with a smaller length than that associated with the assigned type of the Information Element. In the example above the Exporter would place a length of 4 versus 8 in the template. If reduced sizing is used, it MUST only be applied to the following integer types: unsigned64, signed64, unsigned32, signed32, unsigned16, signed16. The same signed versus unsigned property MUST be preserved. The reduction in size can be to any number of octets smaller than the original type if the data value still fits, i.e. so that only leading zeroes are dropped. For example, an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s). Reduced sizing can also be used on the float64 and float32. The float32 not only has a reduced number range, but due to the smaller mantissa is also less precise. The reduced size encoding MUST NOT be applied to dateTimeMicroSeconds or to dateTimeNanoSeconds because these represent an inherent structure that would be destroyed by using less than the original number of bytes. Hi all In the IPFIX protocol draft, section 3.1.5, we have a definition of a floating point number. This definition allows export of floating point numbers using the 32-bit format as specified in IEEE.754. This same standard also allows floating point numbers to be defined in a 64-bit format. I would like to see a float64 type added and the abiltity to send float64 fields using float32 using a variation of the Reduced Size Encoding as used with the integers. I would like to propose that at the next editing phase we add the following type to the information model: 3.1.6. float64 The type "float64" corresponds to an IEEE double-precision 64-bit floating point type as defined in [IEEE.754.1985]. In the protocol, section 6.2 could also be expanded to encompase the Reduced Size encoding for the floating point types. i.e. 6.2 Reduced Size Encoding of Integer Types Information Elements containing integer, float, string, and ... ^^^^^^^ octetarray types in the information model MAY be encoded using fewer octets than those implied by their type in the information model definition [IPFIX-INFO], ... ... If reduced sizing is used, it MUST only be applied to the following integer types: unsigned64, signed64, unsigned32, signed32, unsigned16, signed16. ... @@[NOTE: the signed types above are not in the data model]@@ Reduced sizing can also be used on the float64 and float32. The float32 not only has a reduced number range, but due to the smaller mantissa is also less precise. The reduced size encoding MUST NOT be applied to ... Andrew -- 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_001_0130_01C62D8A.596F21F0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Dear Benoit and all,
 
I agree to your proposal but would add a = sentence=20 like:
 
When reducing the size of a float type make = sure that the=20 precision is not reduced due to the smaller = mantissa.
 
You could make it more strong in writing "MUST = make sure"=20 but I think that's not needed.
 
Best Regards,
 
Thomas
 
--
Thomas = Dietz
Network=20 Laboratories, NEC Europe Ltd., 69115 Heidelberg,=20 Germany
  
From: majordomo listserver=20 [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Benoit=20 Claise
Sent: Thursday, February 09, 2006 11:17 = AM
To:=20 Andrew Johnson
Cc: = ipfix@net.doit.wisc.edu
Subject: Re:=20 [ipfix] Floating point numbers in IPFIX

Dear all,

In an attempt to summarize all this thread = conclusion, I have inserted the following text.

Regards, = Benoit.

6R6.2 Reduced = Size Encoding=20 of Integer and Float Types

Information Elements = containing=20 integer, string, float, and octetarray = types in the=20 information model MAY be encoded using fewer octets than those = implied by=20 their type in the information model definition [IPFIX-INFO], based on = the=20 assumption that the smaller type is sufficient to carry any value the = Exporter=20 may need to deliver.  This reduces the network bandwidth = requirement=20 between the Exporter and the Collector.  Note that the = Information=20 Element definitions [IPFIX-INFO] will always define the maximum = encoding=20 size.

For instance the = information=20 model [IPFIX-INFO] defines byteCount as an unsigned64 type, which = would=20 require 64-bits.  However if the Exporter will never locally = encounter=20 the need to send a value larger than 4294967295, it may chose to send = the=20 value instead as an unsigned32.  For example, a core router would = require=20 an unsigned64 byteCount while an unsigned32 might be sufficient for an = access=20 router.
<!--[if=20 !supportLineBreakNewLine]-->
<!--[endif]-->

This behavior is = indicated by the=20 Exporter by specifying a type size with a smaller length than that = associated=20 with the assigned type of the Information Element.  In the = example above=20 the Exporter would place a length of 4 versus 8 in the template.

If reduced sizing is = used, it MUST=20 only be applied to the following integer types: unsigned64, signed64, unsigned32, signed32, = unsigned16,=20 signed16.  The same signed versus unsigned property MUST = be=20 preserved.  The reduction in size can be to any number of octets = smaller=20 than the original type if the data value still fits, i.e. so that only = leading=20 zeroes are dropped. For example, an unsigned64 can be reduced in size = to 7, 6,=20 5, 4, 3, 2, or 1 octet(s).

Reduced sizing=20 can also be used on the float64 and float32.  The float32 = not only=20 has a reduced number range, but due to the smaller mantissa is also = less=20 precise.

The reduced size = encoding MUST=20 NOT be applied to dateTimeMicroSeconds or to dateTimeNanoSeconds = because these=20 represent an inherent structure that would be destroyed by using less = than the=20 original number of bytes.


Hi all =

In=20 the IPFIX protocol draft, section 3.1.5, we have a definition
of = a=20 floating point number.  This definition allows export of =
floating=20 point numbers using the 32-bit format as specified in =
IEEE.754. =20 This same standard also allows floating point numbers
to be = defined in a=20 64-bit format.

I would like to see a float64 type added and = the=20 abiltity to
send float64 fields using float32 using a variation = of the=20
Reduced Size Encoding as used with the integers.

I would = like to=20 propose that at the next editing phase we add
the following type = to the=20 information model:

3.1.6.  float64

The type = "float64"=20 corresponds to an IEEE double-precision 64-bit
floating point = type as=20 defined in [IEEE.754.1985].


In the protocol, section 6.2 = could=20 also be expanded to encompase
the Reduced Size encoding for the = floating=20 point types. i.e.

6.2      Reduced = Size=20 Encoding of Integer Types
 Information Elements containing = integer,=20 float, string, and ...=20 =
           &nb= sp;           &nbs= p;            = ;     =20 ^^^^^^^
 octetarray types in the information model MAY be = encoded=20 using fewer
 octets than those implied by their type in the = information model
 definition [IPFIX-INFO], ... =

 ...=20
   If reduced sizing is used, it MUST only be applied = to the=20 following  integer types: unsigned64, signed64, unsigned32, = signed32,=20  unsigned16, signed16.  ...

@@[NOTE: the signed = types=20 above are not in the data model]@@

 Reduced sizing can = also be=20 used on the float64 and float32.  The
 float32 not = only has a=20 reduced number range, but due to the
 smaller mantissa is = also less=20 precise.

 The reduced size encoding MUST NOT be applied = to ...=20


Andrew


--=20
Help        mailto:majordomo@net.doit.wis= c.edu=20 and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wis= c.edu=20 and say
"unsubscribe ipfix" in message body=20
Archive     http://ipfix.doit.wisc.edu/a= rchive/=20

------=_NextPart_001_0130_01C62D8A.596F21F0-- ------=_NextPart_000_012F_01C62D8A.596F21F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcDCCAvgw ggJhoAMCAQICAw9RdTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE3MDkwOTE3WhcNMDYwODE3MDkwOTE3WjBjMQ4wDAYDVQQE EwVEaWV0ejEPMA0GA1UEKhMGVGhvbWFzMRUwEwYDVQQDEwxUaG9tYXMgRGlldHoxKTAnBgkqhkiG 9w0BCQEWGlRob21hcy5EaWV0ekBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA4nhGGaCtAFl95e262kXtWs33/Co8wu3qnQqpmgEkgADwZV1ZGoNphSGYXWmdAO4S C+M2HFzsJ0FJ3eG4KV0IaI+kvuKQdfHbqKSV8OfUTIhwrzjwZVJBvUYagIBF8ksvo37XR8YPg5Hw j/zPFAbRhbGg/mrKj/Za7/P9ouv1onhwigQtOG5qcr3+MHE+I6lmkZM7FrzzNwYSJ0Jq52Q8BUEg LWdhLHnXDFy1d+tCZdtdEK3bKga13+Udc5jC0Yvg8hmY+nrxhUPKcYR038q404eJplla2qtpEC3O IoGTKLYRtcxAtoMQ1VG32AylLKJ59/GQDqXOjr9iCI4qyyj7zwIDAQABozcwNTAlBgNVHREEHjAc gRpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAE2PK+6rLfxJ5o+m3N28Uj0XGeArIfvLtnzZQDvuzz2jaThTjJ7PqULqOzjPsCGT/UsT2Ayo 2ksMnxzcVVIK4iJJlaJ2qJRrORakM2CfmkaxFkrJweezRfMPSp7tlW8QnZ/Johw746jZj5bcnOsV 0gxcXkhfMr9OcjEVsJ6+2eg6MIIDLTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkG A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYD VQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBE aXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIz MTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmlj YXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIs YyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56 fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUw AwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuo SpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMm CZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJ KoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjA dQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn 8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjAp BgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6 GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh eILcIRk13iSx0x1G/11fZU8xggNQMIIDTAIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDD1F1MAkGBSsOAwIaBQCgggG8MBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDIwOTE0MDYwNVowIwYJKoZIhvcNAQkEMRYEFKBQZTXN s014JSesIo5ykXHUkNnGMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPUXUwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDD1F1MA0GCSqGSIb3DQEBAQUABIIBAMFt3i73YKfUGuI5S7hm A+Yqi5rtk8C/lrQm5ZvBr6zErhGVZmjPWeH5fDujUfVs5kkL+npf/lD1nPV8F3ym1eMe+3bMGsgB XTqdcLKYV74Rxq0FIIv+HVLMsHva3/HdR+/nRxxz8uBd34eOrqmwHquzGxOTAVJuOUnyuljIe4MB +6WdFGLqt3okUzF0QtJmPRmw7f6MdA0TNL8bTbAIqRYHv3jaN+X3i6C5JB3FcxVbTPT0ZS7nCqcd l6qvE0PVhasx8mGb38aNGf47Alz1fqWe2+dbKzfPF9NXAawE0u/qAkDo+SGJt2pwgHVeZLAAEpKr FRtcYEpC9EZelQ97vdoAAAAAAAA= ------=_NextPart_000_012F_01C62D8A.596F21F0-- -- 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 09 09:19:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7CeD-0003AW-ES for ipfix-archive@megatron.ietf.org; Thu, 09 Feb 2006 09:19:49 -0500 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 JAA25059 for ; Thu, 9 Feb 2006 09:18:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F7CZW-00008y-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Feb 2006 08:14:58 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F7CZU-00008k-00 for ipfix@net.doit.wisc.edu; Thu, 09 Feb 2006 08:14:57 -0600 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Feb 2006 15:14:56 +0100 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 k19EEp5i014510; Thu, 9 Feb 2006 15:14:52 +0100 (MET) Received: from [10.61.64.255] (ams-clip-vpn-dhcp255.cisco.com [10.61.64.255]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA05160; Thu, 9 Feb 2006 14:14:48 GMT Message-ID: <43EB4E58.6050608@cisco.com> Date: Thu, 09 Feb 2006 14:14:48 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Dietz CC: Benoit Claise , Andrew Johnson , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Floating point numbers in IPFIX References: <6D28EBC684A4D94096217AD2FE400873075EE1@venus.office> In-Reply-To: <6D28EBC684A4D94096217AD2FE400873075EE1@venus.office> Content-Type: multipart/alternative; boundary="------------000706080008060103040009" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------000706080008060103040009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thomas Dietz wrote: > Dear Benoit and all, > > I agree to your proposal but would add a sentence like: > > When reducing the size of a float type make sure that the precision is > not reduced due to the smaller mantissa. It may be OK to reduce the precision - it's application dependent. - Stewart > > You could make it more strong in writing "MUST make sure" but I think > that's not needed. > > Best Regards, > > Thomas > > -- > Thomas Dietz > Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany > > > ------------------------------------------------------------------------ > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On > Behalf Of Benoit Claise > Sent: Thursday, February 09, 2006 11:17 AM > To: Andrew Johnson > Cc: ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] Floating point numbers in IPFIX > > Dear all, > > In an attempt to summarize all this thread conclusion, I have > inserted the following text. > > Regards, Benoit. > > 6R6.2 Reduced Size Encoding of Integer and Float Types > > Information Elements containing integer, string, float, and > octetarray types in the information model MAY be encoded using > fewer octets than those implied by their type in the information > model definition [IPFIX-INFO], based on the assumption that the > smaller type is sufficient to carry any value the Exporter may > need to deliver. This reduces the network bandwidth requirement > between the Exporter and the Collector. Note that the Information > Element definitions [IPFIX-INFO] will always define the maximum > encoding size. > > For instance the information model [IPFIX-INFO] defines byteCount > as an unsigned64 type, which would require 64-bits. However if > the Exporter will never locally encounter the need to send a value > larger than 4294967295, it may chose to send the value instead as > an unsigned32. For example, a core router would require an > unsigned64 byteCount while an unsigned32 might be sufficient for > an access router. > > > > This behavior is indicated by the Exporter by specifying a type > size with a smaller length than that associated with the assigned > type of the Information Element. In the example above the > Exporter would place a length of 4 versus 8 in the template. > > If reduced sizing is used, it MUST only be applied to the > following integer types: unsigned64, signed64, unsigned32, > signed32, unsigned16, signed16. The same signed versus unsigned > property MUST be preserved. The reduction in size can be to any > number of octets smaller than the original type if the data value > still fits, i.e. so that only leading zeroes are dropped. For > example, an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, > or 1 octet(s). > > Reduced sizing can also be used on the float64 and float32. > The float32 not only has a reduced number range, but due to the > smaller mantissa is also less precise. > > The reduced size encoding MUST NOT be applied to > dateTimeMicroSeconds or to dateTimeNanoSeconds because these > represent an inherent structure that would be destroyed by using > less than the original number of bytes. > > >> Hi all >> >> In the IPFIX protocol draft, section 3.1.5, we have a definition >> of a floating point number. This definition allows export of >> floating point numbers using the 32-bit format as specified in >> IEEE.754. This same standard also allows floating point numbers >> to be defined in a 64-bit format. >> >> I would like to see a float64 type added and the abiltity to >> send float64 fields using float32 using a variation of the >> Reduced Size Encoding as used with the integers. >> >> I would like to propose that at the next editing phase we add >> the following type to the information model: >> >> 3.1.6. float64 >> >> The type "float64" corresponds to an IEEE double-precision 64-bit >> floating point type as defined in [IEEE.754.1985]. >> >> >> In the protocol, section 6.2 could also be expanded to encompase >> the Reduced Size encoding for the floating point types. i.e. >> >> 6.2 Reduced Size Encoding of Integer Types >> Information Elements containing integer, float, string, and ... >> ^^^^^^^ >> octetarray types in the information model MAY be encoded using >> fewer >> octets than those implied by their type in the information model >> definition [IPFIX-INFO], ... >> >> ... >> If reduced sizing is used, it MUST only be applied to the >> following integer types: unsigned64, signed64, unsigned32, >> signed32, unsigned16, signed16. ... >> >> @@[NOTE: the signed types above are not in the data model]@@ >> >> Reduced sizing can also be used on the float64 and float32. The >> float32 not only has a reduced number range, but due to the >> smaller mantissa is also less precise. >> >> The reduced size encoding MUST NOT be applied to ... >> >> >> Andrew >> >> >> -- >> 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/ > > --------------000706080008060103040009 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thomas Dietz wrote:
Dear Benoit and all,
 
I agree to your proposal but would add a sentence like:
 
When reducing the size of a float type make sure that the precision is not reduced due to the smaller mantissa.
It may be OK to reduce the precision - it's application dependent.

- Stewart
 
You could make it more strong in writing "MUST make sure" but I think that's not needed.
 
Best Regards,
 
Thomas
 
--
Thomas Dietz
Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany
  
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Benoit Claise
Sent: Thursday, February 09, 2006 11:17 AM
To: Andrew Johnson
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Floating point numbers in IPFIX

Dear all,

In an attempt to summarize all this thread conclusion, I have inserted the following text.

Regards, Benoit.

6R6.2 Reduced Size Encoding of Integer and Float Types

Information Elements containing integer, string, float, and octetarray types in the information model MAY be encoded using fewer octets than those implied by their type in the information model definition [IPFIX-INFO], based on the assumption that the smaller type is sufficient to carry any value the Exporter may need to deliver.  This reduces the network bandwidth requirement between the Exporter and the Collector.  Note that the Information Element definitions [IPFIX-INFO] will always define the maximum encoding size.

For instance the information model [IPFIX-INFO] defines byteCount as an unsigned64 type, which would require 64-bits.  However if the Exporter will never locally encounter the need to send a value larger than 4294967295, it may chose to send the value instead as an unsigned32.  For example, a core router would require an unsigned64 byteCount while an unsigned32 might be sufficient for an access router.
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

This behavior is indicated by the Exporter by specifying a type size with a smaller length than that associated with the assigned type of the Information Element.  In the example above the Exporter would place a length of 4 versus 8 in the template.

If reduced sizing is used, it MUST only be applied to the following integer types: unsigned64, signed64, unsigned32, signed32, unsigned16, signed16.  The same signed versus unsigned property MUST be preserved.  The reduction in size can be to any number of octets smaller than the original type if the data value still fits, i.e. so that only leading zeroes are dropped. For example, an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s).

Reduced sizing can also be used on the float64 and float32.  The float32 not only has a reduced number range, but due to the smaller mantissa is also less precise.

The reduced size encoding MUST NOT be applied to dateTimeMicroSeconds or to dateTimeNanoSeconds because these represent an inherent structure that would be destroyed by using less than the original number of bytes.


Hi all

In the IPFIX protocol draft, section 3.1.5, we have a definition
of a floating point number.  This definition allows export of
floating point numbers using the 32-bit format as specified in
IEEE.754.  This same standard also allows floating point numbers
to be defined in a 64-bit format.

I would like to see a float64 type added and the abiltity to
send float64 fields using float32 using a variation of the
Reduced Size Encoding as used with the integers.

I would like to propose that at the next editing phase we add
the following type to the information model:

3.1.6.  float64

The type "float64" corresponds to an IEEE double-precision 64-bit
floating point type as defined in [IEEE.754.1985].


In the protocol, section 6.2 could also be expanded to encompase
the Reduced Size encoding for the floating point types. i.e.

6.2      Reduced Size Encoding of Integer Types
 Information Elements containing integer, float, string, and ...
                                          ^^^^^^^
 octetarray types in the information model MAY be encoded using fewer
 octets than those implied by their type in the information model
 definition [IPFIX-INFO], ...

 ...
   If reduced sizing is used, it MUST only be applied to the following  integer types: unsigned64, signed64, unsigned32, signed32,  unsigned16, signed16.  ...

@@[NOTE: the signed types above are not in the data model]@@

 Reduced sizing can also be used on the float64 and float32.  The
 float32 not only has a reduced number range, but due to the
 smaller mantissa is also less precise.

 The reduced size encoding MUST NOT be applied to ...


Andrew


--
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/


--------------000706080008060103040009-- -- 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 09 10:08:04 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7DOt-0007fU-Uf for ipfix-archive@megatron.ietf.org; Thu, 09 Feb 2006 10:08:04 -0500 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 KAA28826 for ; Thu, 9 Feb 2006 10:06:20 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F7DI8-0007Un-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Feb 2006 09:01:04 -0600 Received: from beniaminus.red.cert.org ([192.88.209.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F7DI6-0007UR-00 for ipfix@net.doit.wisc.edu; Thu, 09 Feb 2006 09:01:02 -0600 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.16) with ESMTP id k19F0xJq019481 for ; Thu, 9 Feb 2006 10:01:00 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k19ExUOL019404 for ; Thu, 9 Feb 2006 09:59:30 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k19ExU6R019402; Thu, 09 Feb 2006 09:59:30 -0500 (EST) Received: from [128.237.244.46] (vpn-10-25-4-3.remote.cert.org [10.25.4.3]) by villemus.indigo.cert.org (8.12.11/8.12.11/2.53) with ESMTP id k19ExTHI005466; Thu, 9 Feb 2006 09:59:29 -0500 In-Reply-To: <43EB4E58.6050608@cisco.com> References: <6D28EBC684A4D94096217AD2FE400873075EE1@venus.office> <43EB4E58.6050608@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-128691953" Message-Id: <6637AD0B-BA63-4A9E-B12C-D4207FBD7D2F@cert.org> Cc: Thomas Dietz , Benoit Claise , Andrew Johnson , ipfix@net.doit.wisc.edu Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [ipfix] Floating point numbers in IPFIX Date: Thu, 9 Feb 2006 09:59:25 -0500 To: Stewart Bryant X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000004 X-Scanned-By: MIMEDefang 2.54 on 192.88.209.10 Precedence: bulk Sender: majordomo listserver This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1-128691953 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit All, There's something I'm missing here... Does IEEE 754 have anything to say on arbitrary reduced-precision/reduced-range floating point representations? Is there really a meaningful, say, six-byte "float64" that everyone can agree on? Do you reduce the exponent, or the mantissa, or both; in that case, each by how many bits? If my 6- byte float64 has a 10-bit exponent and a 36-bit fraction, and yours has an 8-bit exponent and a 34-bit fraction, how do we represent this? Do we open the float types to non-754, machine-specific representations? Or are we really, practically, just talking about a way to represent a float64-specified IE as a float32? - Brian On Feb 9, 2006, at 9:14 AM, Stewart Bryant wrote: > Thomas Dietz wrote: >> Dear Benoit and all, >> >> I agree to your proposal but would add a sentence like: >> >> When reducing the size of a float type make sure that the >> precision is not reduced due to the smaller mantissa. > It may be OK to reduce the precision - it's application dependent. > > - Stewart >> >> You could make it more strong in writing "MUST make sure" but I >> think that's not needed. >> >> Best Regards, >> >> Thomas >> >> -- >> Thomas Dietz >> Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany >> >> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On >> Behalf Of Benoit Claise >> Sent: Thursday, February 09, 2006 11:17 AM >> To: Andrew Johnson >> Cc: ipfix@net.doit.wisc.edu >> Subject: Re: [ipfix] Floating point numbers in IPFIX >> >> Dear all, >> >> In an attempt to summarize all this thread conclusion, I have >> inserted the following text. >> >> Regards, Benoit. >> 6R6.2 Reduced Size Encoding of Integer and Float Types >> >> Information Elements containing integer, string, float, and >> octetarray types in the information model MAY be encoded using >> fewer octets than those implied by their type in the information >> model definition [IPFIX-INFO], based on the assumption that the >> smaller type is sufficient to carry any value the Exporter may >> need to deliver. This reduces the network bandwidth requirement >> between the Exporter and the Collector. Note that the Information >> Element definitions [IPFIX-INFO] will always define the maximum >> encoding size. >> >> For instance the information model [IPFIX-INFO] defines byteCount >> as an unsigned64 type, which would require 64-bits. However if >> the Exporter will never locally encounter the need to send a value >> larger than 4294967295, it may chose to send the value instead as >> an unsigned32. For example, a core router would require an >> unsigned64 byteCount while an unsigned32 might be sufficient for >> an access router. >> >> >> >> This behavior is indicated by the Exporter by specifying a type >> size with a smaller length than that associated with the assigned >> type of the Information Element. In the example above the >> Exporter would place a length of 4 versus 8 in the template. >> >> If reduced sizing is used, it MUST only be applied to the >> following integer types: unsigned64, signed64, unsigned32, >> signed32, unsigned16, signed16. The same signed versus unsigned >> property MUST be preserved. The reduction in size can be to any >> number of octets smaller than the original type if the data value >> still fits, i.e. so that only leading zeroes are dropped. For >> example, an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, >> or 1 octet(s). >> >> Reduced sizing can also be used on the float64 and float32. The >> float32 not only has a reduced number range, but due to the >> smaller mantissa is also less precise. >> >> The reduced size encoding MUST NOT be applied to >> dateTimeMicroSeconds or to dateTimeNanoSeconds because these >> represent an inherent structure that would be destroyed by using >> less than the original number of bytes. >> >> >>> Hi all >>> >>> In the IPFIX protocol draft, section 3.1.5, we have a definition >>> of a floating point number. This definition allows export of >>> floating point numbers using the 32-bit format as specified in >>> IEEE.754. This same standard also allows floating point numbers >>> to be defined in a 64-bit format. >>> >>> I would like to see a float64 type added and the abiltity to >>> send float64 fields using float32 using a variation of the >>> Reduced Size Encoding as used with the integers. >>> >>> I would like to propose that at the next editing phase we add >>> the following type to the information model: >>> >>> 3.1.6. float64 >>> >>> The type "float64" corresponds to an IEEE double-precision 64-bit >>> floating point type as defined in [IEEE.754.1985]. >>> >>> >>> In the protocol, section 6.2 could also be expanded to encompase >>> the Reduced Size encoding for the floating point types. i.e. >>> >>> 6.2 Reduced Size Encoding of Integer Types >>> Information Elements containing integer, float, string, and ... >>> ^^^^^^^ >>> octetarray types in the information model MAY be encoded using >>> fewer >>> octets than those implied by their type in the information model >>> definition [IPFIX-INFO], ... >>> >>> ... >>> If reduced sizing is used, it MUST only be applied to the >>> following integer types: unsigned64, signed64, unsigned32, >>> signed32, unsigned16, signed16. ... >>> >>> @@[NOTE: the signed types above are not in the data model]@@ >>> >>> Reduced sizing can also be used on the float64 and float32. The >>> float32 not only has a reduced number range, but due to the >>> smaller mantissa is also less precise. >>> >>> The reduced size encoding MUST NOT be applied to ... >>> >>> >>> Andrew >>> >>> >>> -- >>> 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/ >> > --Apple-Mail-1-128691953 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.4.2 (Darwin) iD8DBQFD61jQ4/8LCZ4pwvYRAsNsAJ9CXrjf8MMv4FSdAQaiYCi9i3zD/ACg2gyc MWSozUOealfi0p3Vr3T5bHc= =Wcb3 -----END PGP SIGNATURE----- --Apple-Mail-1-128691953-- -- 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 malatiachap@harter.com Thu Feb 09 11:40:41 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7EqW-0001W6-TF for ipfix-archive@megatron.ietf.org; Thu, 09 Feb 2006 11:40:40 -0500 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 LAA07276 for ; Thu, 9 Feb 2006 11:38:57 -0500 (EST) Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F7EkU-0007hg-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Feb 2006 10:34:26 -0600 Received: from harter.com (210.213.139.121.pldt.net [210.213.139.121] (may be forged)) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k19GYNek030240 for ; Thu, 9 Feb 2006 10:34:24 -0600 Message-ID: <000001c62d96$aa9abdd0$d46ba8c0@burlesque> Reply-To: "Malati Chappel" From: "Malati Chappel" To: "Abimael Kleinschmidt" Subject: Re: c9 T news Date: Thu, 9 Feb 2006 11:34:15 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62D6C.C1C4B5D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62D6C.C1C4B5D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, http://www.reladesgo.com =20 VxAeLhlmUcMj b$g1x,k2w1l CbIkAhLnIhSi a$y3o,s3x3z VlIjAcGiRyAq m$e3t,y7b5p ------=_NextPart_000_0001_01C62D6C.C1C4B5D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
VxAeLhlmUcMj b$g1x,k2w1l
CbIkAhLnIhSi a$y3o,s3x3z
VlIjAcGiRyAq m$e3t,y7b5p
------=_NextPart_000_0001_01C62D6C.C1C4B5D0-- From majordomo@mil.doit.wisc.edu Thu Feb 09 12:55:56 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7G1B-0004uC-Bm for ipfix-archive@megatron.ietf.org; Thu, 09 Feb 2006 12:55:56 -0500 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 MAA13522 for ; Thu, 9 Feb 2006 12:54:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F7Frw-0005MJ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Feb 2006 11:46:12 -0600 Received: from a.6f2.net ([213.189.5.89]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F7Fru-0005Lw-00 for ipfix-info@net.doit.wisc.edu; Thu, 09 Feb 2006 11:46:10 -0600 Received: by a.6f2.net (Postfix, from userid 66) id 8A677BF8D6D; Thu, 9 Feb 2006 18:46:09 +0100 (CET) Received: by localhost.localdomain (Postfix, from userid 500) id 63821454A00; Thu, 9 Feb 2006 18:46:56 +0100 (CET) Date: Thu, 9 Feb 2006 18:46:56 +0100 From: Alexandre Dulaunoy To: Brian Trammell Cc: Alexandre Dulaunoy , ipfix-info@net.doit.wisc.edu, Elisa Boschi , Lutz Mark , Elisa Boschi , yann@bashibuzuk.net, flowop@lists.csrrt.org.lu Subject: [ipfix-info] Re: draft-boschi-ipfix-biflow and software implementation Message-ID: <20060209174656.GA32686@localhost.localdomain> References: <43E75136.9060509@fokus.fraunhofer.de> <85F86ADC-BB27-4617-A848-43CCC210945C@cert.org> <20060207151142.GA18424@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: GNU Emacs 22.0.50.2 Organization: Somewhere in Space X-fingerprint: 3B12 DCC2 82FA 2931 2F5B 709A 09E2 CD49 44E6 CBCD X-URL: http://www.foo.be/ X-DMCA-EUCD: False User-Agent: mutt-ng/devel-r655 (Linux) Precedence: bulk Sender: majordomo listserver On 07/Feb/06 10:47 -0500, Brian Trammell wrote: Hi Brian, > Alexandre, > > On Feb 7, 2006, at 10:11 AM, Alexandre Dulaunoy wrote: > > >I'll try to "over" summarize back what I understand with the > >information you gave me and the draft > >(draft-boschi-export-perpktinfo-01.txt) : > > > >The FlowID is a 32bit id unique across one observation point and is > >(always?) generated by the exporter. > > > >We (at SES ASTRA and CSRRT-LU) are trying to generate a > >"unique/calculable" FlowID among a specify dataset of records. Why ? > >We have a bunch of "exporters" (routers, devices) with various > >versions of Netflow and we have to live with that for the time > >being. What we are doing currently ? we use a simple hash function to > >generate a "unique" FlowID per data set based on source/destination > >IP, source/destination PORT and (protocol). We use the lowest > >source/destination (IP/PORT) to generate a unified hash id per biflow. > > > >So it seems that I was mixing our and your definition of FlowID but > >what do you think ? Can we call that a FlowID or something else ? > >Have you think of a 'possible' function to generate a FlowID based on > >records ? Like that, we can rebuild biflow(s) from uniflow(s) ? Does > >it make sense ? > > flowId, as defined in -info-11, does not presently appear flexible enough to cover this use case; its "unique within Observation Domain" > constraint appears to make multiple Flow Records sharing the same flowId impossible. Thinking about it for a moment, I think this is a fault in > the information model. To increase the flexibility of this IE, I'd propose changing its definition to the following: > > 5.1.7. flowId > > Description: > An identifier of a Flow that is unique within an Observation > Domain. This Information Element can be used to distinguish > between different Flows if Flow Keys such as IP addresses and port > numbers are not reported or reported in separate records. Multiple > Flow Records observed within the same Observation Domain may share > the same flowId if they describe the same Flow as determined by the > Metering Processes within that Domain. > Abstract Data Type: unsigned32 > Data Type Semantics: identifier > ElementId: 148 > Status: current > > (Elisa - this also expands flowId as required for -biflow-02 section 3.2) Thanks for the feedback. On our side (outside the scope of the draft), we will keep the approach to uniquely identify the flow among a dataset. In that case, the flowId is often bigger than 32 bits but it's not sequential(?) like the flowId expressed in the draft. Another question (more in scope with the draft), how do you deal with the uniqueness of the flowId ? Is it up to the implementation on the exporter to handle the uniqueness ? > >Brian : A site note, looking into naf source code (the pcap exporter), > >I can't find the part of generating the FlowID. Can you point me to > >the correct part ? > > We don't actually use the flowId anywhere (hence the cheating) - we do single-record biflow export per draft-boschi-ipfix-biflow section 3.4 > (section 4 in the forthcoming -02 draft), with CERT-private IEs standing in for IANA-assigned IEs pending completion of that draft. The > relevant code is in nafcore.c. NAF unifies uniflows (from pcap or SiLK) into biflows the hard way; SiLK asymmetric unidirectional data is > collected using the SiLK tools' proprietary protocol into a single database, relevant records are selected out of that database and sorted by > time, mingling incoming and outgoing records and re-matching them before aggregation. OK. understood. Thanks a lot for the feedback, Have a nice day, adulau -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://www.gnu.org/philosophy/free-sw.html -- "Knowledge can create problems, it is not through ignorance -- that we can solve them" Isaac Asimov -- 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 09 20:07:23 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Mks-0007tW-4Q for ipfix-archive@megatron.ietf.org; Thu, 09 Feb 2006 20:07:23 -0500 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 UAA29172 for ; Thu, 9 Feb 2006 20:05:36 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F7MUK-0007UV-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Feb 2006 18:50:16 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F7MUJ-0007UD-00 for ipfix@net.doit.wisc.edu; Thu, 09 Feb 2006 18:50:15 -0600 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Feb 2006 01:50:14 +0100 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 k1A0oA5i016585; Fri, 10 Feb 2006 01:50:11 +0100 (MET) Received: from [10.61.80.111] (ams-clip-vpn-dhcp4208.cisco.com [10.61.80.111]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id AAA04932; Fri, 10 Feb 2006 00:50:09 GMT Message-ID: <43EBE340.4050701@cisco.com> Date: Fri, 10 Feb 2006 00:50:08 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.10) Gecko/20050811 Fedora/1.7.10-1.2.1.legacy X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Brian Trammell CC: Stewart Bryant , Thomas Dietz , Benoit Claise , Andrew Johnson , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Floating point numbers in IPFIX References: <6637AD0B-BA63-4A9E-B12C-D4207FBD7D2F@cert.org> In-Reply-To: <6637AD0B-BA63-4A9E-B12C-D4207FBD7D2F@cert.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Brian, > There's something I'm missing here... Does IEEE 754 have anything to > say on arbitrary reduced-precision/reduced-range floating point > representations? Is there really a meaningful, say, six-byte > "float64" that everyone can agree on? [...] Noooo! This isn't what we want to do at all. > Or are we really, practically, just talking about a way to represent > a float64-specified IE as a float32? Exactly. Referring back to the email which started this thread: http://ipfix.doit.wisc.edu/archive/3034.html Andrew said: > I would like to see a float64 type added and the abiltity to send > float64 fields using float32 using a variation of the Reduced Size > Encoding as used with the integers. And Stewart's follow-up: > I think that we should add float64 with the export compresion to > float32. So perhaps Benoit's text could be clearer, eg: Reduced sizing can also be used to reduce float64 to float32. The float32 not only has a reduced number range, but due to the smaller mantissa is also less precise. Cheers. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- 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 10 05:11:12 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7VFA-0006Y1-3S for ipfix-archive@megatron.ietf.org; Fri, 10 Feb 2006 05:11:12 -0500 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 FAA05296 for ; Fri, 10 Feb 2006 05:09:28 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F7Uys-0007dR-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Feb 2006 03:54:22 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F7Uyq-0007dH-00 for ipfix@net.doit.wisc.edu; Fri, 10 Feb 2006 03:54:20 -0600 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Feb 2006 10:54:19 +0100 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 k1A9sG5i026961; Fri, 10 Feb 2006 10:54:17 +0100 (MET) Received: from [10.61.81.107] (ams-clip-vpn-dhcp4460.cisco.com [10.61.81.107]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA09307; Fri, 10 Feb 2006 09:54:10 GMT Message-ID: <43EC62C1.1020603@cisco.com> Date: Fri, 10 Feb 2006 09:54:09 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Aitken CC: Brian Trammell , Thomas Dietz , Benoit Claise , Andrew Johnson , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Floating point numbers in IPFIX References: <6637AD0B-BA63-4A9E-B12C-D4207FBD7D2F@cert.org> <43EBE340.4050701@cisco.com> In-Reply-To: <43EBE340.4050701@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Paul Aitken wrote: > Brian, > >> There's something I'm missing here... Does IEEE 754 have anything to >> say on arbitrary reduced-precision/reduced-range floating point >> representations? Is there really a meaningful, say, six-byte >> "float64" that everyone can agree on? [...] > > > Noooo! This isn't what we want to do at all. > >> Or are we really, practically, just talking about a way to represent >> a float64-specified IE as a float32? > > > Exactly. > > Referring back to the email which started this thread: > http://ipfix.doit.wisc.edu/archive/3034.html > > Andrew said: > >> I would like to see a float64 type added and the abiltity to send >> float64 fields using float32 using a variation of the Reduced Size >> Encoding as used with the integers. > > > And Stewart's follow-up: > >> I think that we should add float64 with the export compresion to >> float32. > > > > So perhaps Benoit's text could be clearer, eg: > > Reduced sizing can also be used to reduce float64 to float32. > The float32 not only has a reduced number range, but due to > the smaller mantissa is also less precise. > > Cheers. I agree - 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 Feb 10 05:27:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7VVG-0004xy-DN for ipfix-archive@megatron.ietf.org; Fri, 10 Feb 2006 05:27:50 -0500 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 FAA06240 for ; Fri, 10 Feb 2006 05:26:06 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F7VBo-0002FT-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Feb 2006 04:07:44 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F7VBn-0002FJ-00 for ipfix@net.doit.wisc.edu; Fri, 10 Feb 2006 04:07:43 -0600 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k1AA7fZ26621; Fri, 10 Feb 2006 11:07:41 +0100 (CET) Received: from [10.61.82.86] (ams-clip-vpn-dhcp4695.cisco.com [10.61.82.86]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k1AA7eC12833; Fri, 10 Feb 2006 11:07:40 +0100 (CET) Message-ID: <43EC65EA.6000804@cisco.com> Date: Fri, 10 Feb 2006 11:07:38 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Stewart Bryant CC: Paul Aitken , Brian Trammell , Thomas Dietz , andrjohn@cisco.com, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Floating point numbers in IPFIX References: <6637AD0B-BA63-4A9E-B12C-D4207FBD7D2F@cert.org> <43EBE340.4050701@cisco.com> <43EC62C1.1020603@cisco.com> In-Reply-To: <43EC62C1.1020603@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, >> >> >> >> So perhaps Benoit's text could be clearer, eg: >> >> Reduced sizing can also be used to reduce float64 to float32. >> The float32 not only has a reduced number range, but due to >> the smaller mantissa is also less precise. >> >> Cheers. Agreed and done. 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 Feb 10 05:30:45 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7VY5-0005bW-PJ for ipfix-archive@megatron.ietf.org; Fri, 10 Feb 2006 05:30:45 -0500 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 FAA06374 for ; Fri, 10 Feb 2006 05:28:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F7VJD-0003EM-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Feb 2006 04:15:23 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F7VJB-0003Di-00 for ipfix@net.doit.wisc.edu; Fri, 10 Feb 2006 04:15:22 -0600 Received: from EXCHSRV.fokus.fraunhofer.de (einstein [10.147.9.230]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id k1AAFHv27526; Fri, 10 Feb 2006 11:15:18 +0100 (MET) 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_01C62E2A.E41C43FE" Subject: RE: [ipfix] Floating point numbers in IPFIX Date: Fri, 10 Feb 2006 11:15:16 +0100 Message-ID: <70524A4436C03E43A293958B505008B60DE35C@EXCHSRV.fokus.fraunhofer.de> Thread-Topic: [ipfix] Floating point numbers in IPFIX Thread-Index: AcYtalmTst3peAp9TCK2DUYf+K62PAAFxegQACouo1A= From: "Carsten Schmoll" To: "Thomas Dietz" , "Benoit Claise" , "Andrew Johnson" Cc: Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------_=_NextPart_001_01C62E2A.E41C43FE Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 Dear Thomas, Benoit, all, =20 I think the reduction of precision is unavoidable (depending on the concrete exported value). Therefore I would suggest some text like: =20 "When using reduced encoding for double or float types make sure that the potential=20 loss of precision due to the smaller mantissa is acceptable for your application." =20 With best regards, Carsten. =20 =20 ________________________________ From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Thomas Dietz Sent: Thursday, February 09, 2006 3:06 PM To: Benoit Claise; Andrew Johnson Cc: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Floating point numbers in IPFIX =09 =09 Dear Benoit and all, =20 I agree to your proposal but would add a sentence like: =20 When reducing the size of a float type make sure that the precision is not reduced due to the smaller mantissa. =20 You could make it more strong in writing "MUST make sure" but I think that's not needed. =20 Best Regards, =20 Thomas =20 -- Thomas Dietz Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany =20 ________________________________ From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Benoit Claise Sent: Thursday, February 09, 2006 11:17 AM To: Andrew Johnson Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Floating point numbers in IPFIX =09 =09 Dear all, =09 In an attempt to summarize all this thread conclusion, I have inserted the following text. =09 Regards, Benoit. =09 6R6.2 Reduced Size Encoding of Integer and Float Types Information Elements containing integer, string, float, and octetarray types in the information model MAY be encoded using fewer octets than those implied by their type in the information model definition [IPFIX-INFO], based on the assumption that the smaller type is sufficient to carry any value the Exporter may need to deliver. This reduces the network bandwidth requirement between the Exporter and the Collector. Note that the Information Element definitions [IPFIX-INFO] will always define the maximum encoding size. For instance the information model [IPFIX-INFO] defines byteCount as an unsigned64 type, which would require 64-bits. However if the Exporter will never locally encounter the need to send a value larger than 4294967295, it may chose to send the value instead as an unsigned32. For example, a core router would require an unsigned64 byteCount while an unsigned32 might be sufficient for an access router. This behavior is indicated by the Exporter by specifying a type size with a smaller length than that associated with the assigned type of the Information Element. In the example above the Exporter would place a length of 4 versus 8 in the template. If reduced sizing is used, it MUST only be applied to the following integer types: unsigned64, signed64, unsigned32, signed32, unsigned16, signed16. The same signed versus unsigned property MUST be preserved. The reduction in size can be to any number of octets smaller than the original type if the data value still fits, i.e. so that only leading zeroes are dropped. For example, an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s). Reduced sizing can also be used on the float64 and float32. The float32 not only has a reduced number range, but due to the smaller mantissa is also less precise. The reduced size encoding MUST NOT be applied to dateTimeMicroSeconds or to dateTimeNanoSeconds because these represent an inherent structure that would be destroyed by using less than the original number of bytes. Hi all=20 =09 In the IPFIX protocol draft, section 3.1.5, we have a definition=20 of a floating point number. This definition allows export of=20 floating point numbers using the 32-bit format as specified in=20 IEEE.754. This same standard also allows floating point numbers=20 to be defined in a 64-bit format.=20 =09 I would like to see a float64 type added and the abiltity to=20 send float64 fields using float32 using a variation of the=20 Reduced Size Encoding as used with the integers. =09 I would like to propose that at the next editing phase we add=20 the following type to the information model:=20 =09 3.1.6. float64=20 =09 The type "float64" corresponds to an IEEE double-precision 64-bit=20 floating point type as defined in [IEEE.754.1985].=20 =09 =09 In the protocol, section 6.2 could also be expanded to encompase=20 the Reduced Size encoding for the floating point types. i.e.=20 =09 6.2 Reduced Size Encoding of Integer Types=20 Information Elements containing integer, float, string, and ...=20 =09 ^^^^^^^=20 octetarray types in the information model MAY be encoded using fewer=20 octets than those implied by their type in the information model=20 definition [IPFIX-INFO], ...=20 =09 ...=20 If reduced sizing is used, it MUST only be applied to the following integer types: unsigned64, signed64, unsigned32, signed32, unsigned16, signed16. ...=20 =09 @@[NOTE: the signed types above are not in the data model]@@=20 =09 Reduced sizing can also be used on the float64 and float32. The=20 float32 not only has a reduced number range, but due to the=20 smaller mantissa is also less precise.=20 =09 The reduced size encoding MUST NOT be applied to ...=20 =09 =09 Andrew=20 =09 =09 --=20 Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body=20 Unsubscribe mailto:majordomo@net.doit.wisc.edu and say=20 "unsubscribe ipfix" in message body=20 Archive http://ipfix.doit.wisc.edu/archive/=20 =09 ------_=_NextPart_001_01C62E2A.E41C43FE Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
 
Dear Thomas, Benoit, all,
 
I think the reduction of precision is = unavoidable=20 (depending on the concrete exported value).
Therefore I would suggest some text=20 like:
 
"When using=20 reduced encoding for double or float types make sure that the potential =
loss of = precision due=20 to the smaller mantissa is = acceptable for=20 your application."
 
With = best=20 regards,
Carsten.
 
 

From: majordomo listserver=20 [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Thomas=20 Dietz
Sent: Thursday, February 09, 2006 3:06 = PM
To: Benoit=20 Claise; Andrew Johnson
Cc:=20 ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] Floating point = numbers=20 in IPFIX

Dear Benoit and all,
 
I agree to your proposal but would add a = sentence=20 like:
 
When reducing the size of a float type make = sure that the=20 precision is not reduced due to the smaller = mantissa.
 
You could make it more strong in writing = "MUST make sure"=20 but I think that's not needed.
 
Best Regards,
 
Thomas
 
--
Thomas = Dietz
Network Laboratories, NEC Europe Ltd., 69115 Heidelberg,=20 Germany
  
From: majordomo listserver=20 [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Benoit=20 Claise
Sent: Thursday, February 09, 2006 11:17 = AM
To:=20 Andrew Johnson
Cc: = ipfix@net.doit.wisc.edu
Subject: Re:=20 [ipfix] Floating point numbers in IPFIX

Dear all,

In an attempt to summarize all this = thread=20 conclusion, I have inserted the following text.

Regards, = Benoit.

6R6.2 Reduced = Size=20 Encoding of Integer and Float Types

Information = Elements containing=20 integer, string, float, and octetarray = types in=20 the information model MAY be encoded using fewer octets than = those=20 implied by their type in the information model definition = [IPFIX-INFO],=20 based on the assumption that the smaller type is sufficient to carry = any=20 value the Exporter may need to deliver.  This reduces the = network=20 bandwidth requirement between the Exporter and the = Collector. =20 Note that the Information Element definitions [IPFIX-INFO] will = always=20 define the maximum encoding size.

For instance the = information=20 model [IPFIX-INFO] defines byteCount as an unsigned64 type, which = would=20 require 64-bits.  However if the Exporter will never locally = encounter=20 the need to send a value larger than 4294967295, it may chose to = send the=20 value instead as an unsigned32.  For example, a core router = would=20 require an unsigned64 byteCount while an unsigned32 might be = sufficient for=20 an access router.
<!--[if=20 !supportLineBreakNewLine]-->
<!--[endif]-->

This behavior is = indicated by=20 the Exporter by specifying a type size with a smaller length than = that=20 associated with the assigned type of the Information Element.  = In the=20 example above the Exporter would place a length of 4 versus 8 in the = template.

If reduced sizing is = used, it=20 MUST only be applied to the following integer types: unsigned64, signed64, unsigned32, signed32, = unsigned16,=20 signed16.  The same signed versus unsigned property MUST = be=20 preserved.  The reduction in size can be to any number of = octets=20 smaller than the original type if the data value still fits, i.e. so = that=20 only leading zeroes are dropped. For example, an unsigned64 can be = reduced=20 in size to 7, 6, 5, 4, 3, 2, or 1 octet(s).

Reduced=20 sizing can also be used on the float64 and float32.  = The float32=20 not only has a reduced number range, but due to the smaller mantissa = is also=20 less precise.

The reduced size = encoding MUST=20 NOT be applied to dateTimeMicroSeconds or to dateTimeNanoSeconds = because=20 these represent an inherent structure that would be destroyed by = using less=20 than the original number of bytes.


Hi = all=20

In the IPFIX protocol draft, section 3.1.5, we have a = definition=20
of a floating point number.  This definition allows = export of=20
floating point numbers using the 32-bit format as specified in =
IEEE.754.  This same standard also allows floating point = numbers=20
to be defined in a 64-bit format.

I would like to see = a=20 float64 type added and the abiltity to
send float64 fields = using=20 float32 using a variation of the
Reduced Size Encoding as used = with=20 the integers.

I would like to propose that at the next = editing=20 phase we add
the following type to the information model:=20

3.1.6.  float64

The type "float64" = corresponds to an=20 IEEE double-precision 64-bit
floating point type as defined in = [IEEE.754.1985].


In the protocol, section 6.2 could = also be=20 expanded to encompase
the Reduced Size encoding for the = floating point=20 types. i.e.

6.2      Reduced Size = Encoding of Integer Types
 Information Elements = containing=20 integer, float, string, and ...=20 =
           &nb= sp;           &nbs= p;            = ;     =20 ^^^^^^^
 octetarray types in the information model MAY be = encoded=20 using fewer
 octets than those implied by their type in = the=20 information model
 definition [IPFIX-INFO], ... =

 ...=20
   If reduced sizing is used, it MUST only be = applied to the=20 following  integer types: unsigned64, signed64, unsigned32, = signed32,=20  unsigned16, signed16.  ...

@@[NOTE: the signed = types=20 above are not in the data model]@@

 Reduced sizing = can also=20 be used on the float64 and float32.  The
 float32 = not only=20 has a reduced number range, but due to the
 smaller = mantissa is=20 also less precise.

 The reduced size encoding MUST = NOT be=20 applied to ...


Andrew


--=20
Help        mailto:majordomo@net.doit.wis= c.edu=20 and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wis= c.edu=20 and say
"unsubscribe ipfix" in message body=20
Archive     http://ipfix.doit.wisc.edu/a= rchive/=20

------_=_NextPart_001_01C62E2A.E41C43FE-- -- 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 10 05:31:31 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7VYn-0005gh-Sf for ipfix-archive@megatron.ietf.org; Fri, 10 Feb 2006 05:31:31 -0500 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 FAA06404 for ; Fri, 10 Feb 2006 05:29:38 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F7VK0-0003SZ-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Feb 2006 04:16:13 -0600 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F7VJw-0003RO-00 for ipfix@net.doit.wisc.edu; Fri, 10 Feb 2006 04:16:08 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id EC7032007D79; Fri, 10 Feb 2006 11:16:07 +0100 (CET) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20014-03; Fri, 10 Feb 2006 11:16:07 +0100 (CET) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id CD492200019C; Fri, 10 Feb 2006 11:16:07 +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] Floating point numbers in IPFIX Date: Fri, 10 Feb 2006 11:15:48 +0100 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_014F_01C62E33.5834C160" Message-ID: <6D28EBC684A4D94096217AD2FE400873075FBF@venus.office> X-MS-Has-Attach: yes Thread-Topic: [ipfix] Floating point numbers in IPFIX Thread-Index: AcYuKdYUXxoowdNtSQW6QxJDi1lzBwAAOC1A From: "Thomas Dietz" To: "Benoit Claise" , "Stewart Bryant" Cc: "Paul Aitken" , "Brian Trammell" , , X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_014F_01C62E33.5834C160 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi all, Assuming that somebody could reduce float64 to float32 even if the precision is reduced, because they do it on purpose then I would also agree to the current wording. Regards, Thomas -- Thomas Dietz Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Friday, February 10, 2006 11:08 AM > To: Stewart Bryant > Cc: Paul Aitken; Brian Trammell; Thomas Dietz; > andrjohn@cisco.com; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] Floating point numbers in IPFIX > > Hi, > >> > >> > >> > >> So perhaps Benoit's text could be clearer, eg: > >> > >> Reduced sizing can also be used to reduce float64 to float32. > >> The float32 not only has a reduced number range, but due to > >> the smaller mantissa is also less precise. > >> > >> Cheers. > Agreed and done. > > Regards, Benoit. > > ------=_NextPart_000_014F_01C62E33.5834C160 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcDCCAvgw ggJhoAMCAQICAw9RdTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE3MDkwOTE3WhcNMDYwODE3MDkwOTE3WjBjMQ4wDAYDVQQE EwVEaWV0ejEPMA0GA1UEKhMGVGhvbWFzMRUwEwYDVQQDEwxUaG9tYXMgRGlldHoxKTAnBgkqhkiG 9w0BCQEWGlRob21hcy5EaWV0ekBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA4nhGGaCtAFl95e262kXtWs33/Co8wu3qnQqpmgEkgADwZV1ZGoNphSGYXWmdAO4S C+M2HFzsJ0FJ3eG4KV0IaI+kvuKQdfHbqKSV8OfUTIhwrzjwZVJBvUYagIBF8ksvo37XR8YPg5Hw j/zPFAbRhbGg/mrKj/Za7/P9ouv1onhwigQtOG5qcr3+MHE+I6lmkZM7FrzzNwYSJ0Jq52Q8BUEg LWdhLHnXDFy1d+tCZdtdEK3bKga13+Udc5jC0Yvg8hmY+nrxhUPKcYR038q404eJplla2qtpEC3O IoGTKLYRtcxAtoMQ1VG32AylLKJ59/GQDqXOjr9iCI4qyyj7zwIDAQABozcwNTAlBgNVHREEHjAc gRpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAE2PK+6rLfxJ5o+m3N28Uj0XGeArIfvLtnzZQDvuzz2jaThTjJ7PqULqOzjPsCGT/UsT2Ayo 2ksMnxzcVVIK4iJJlaJ2qJRrORakM2CfmkaxFkrJweezRfMPSp7tlW8QnZ/Johw746jZj5bcnOsV 0gxcXkhfMr9OcjEVsJ6+2eg6MIIDLTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkG A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYD VQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBE aXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIz MTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmlj YXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIs YyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56 fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUw AwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuo SpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMm CZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJ KoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjA dQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn 8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjAp BgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6 GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh eILcIRk13iSx0x1G/11fZU8xggNQMIIDTAIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDD1F1MAkGBSsOAwIaBQCgggG8MBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDIxMDEwMTU0OFowIwYJKoZIhvcNAQkEMRYEFDjWrici bE0kPMh1gcHCwc+bEKqFMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPUXUwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDD1F1MA0GCSqGSIb3DQEBAQUABIIBAAwgzmGRpsxtqTQP31SL wtn1NLjUrPbtOEV7BMppXjYzDq20FQ94h+H1IMxD2xGT+ci6RDa9WZsq1EQSbJ9ZnB80SFw6yvwY M+rvcX5NPDOIU5HkTwQTc//ErwhOcgZVjCQXmPaJpq/zKZvza2nvjYdzx29730VKTvQ7SVnwWHAF umYVt5eoPkG5AEBvQSbncNwD38BXdhMYiI0+wXFihH+59UHzLoMyQfBCzr/1NSFOJtSL4yUJVn7U v2Qtc4AA8VdWHQpK8WFoGi1HqxBSizs/91YQ+02nsK7+qpxoSKm5tjVykPvkFMv4wdqzBYdyfZ9a uDuvTefy5qjaytmv3yMAAAAAAAA= ------=_NextPart_000_014F_01C62E33.5834C160-- -- 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 robert@hkc.net Fri Feb 10 05:36:20 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7VdU-0007kZ-88 for ipfix-archive@megatron.ietf.org; Fri, 10 Feb 2006 05:36:20 -0500 Received: from defkaqjfqh.info ([193.140.237.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06693 for ; Fri, 10 Feb 2006 05:34:18 -0500 (EST) Received: from mail by microsoft.com with local id 7-8-51; Fri, 10 Feb 2006 13:18:20 -0500 Message-ID: <8058966@orthodoxy> From: Logan Fry To: ipfix-archive@ietf.org Subject: Amazing, Vernon Date: Fri, 10 Feb 2006 13:30:02 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6814.88657.44792.8308 X-MimeOLE: Produced By Microsoft MimeOLE 92141.30663.121811.413337 Content-Type: multipart/mixed; boundary="------=724104883379274" Content-Transfer-Encoding: quoted-printable --------=724104883379274 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


Flirting is the gentle art of making a man feel pleased with himself.
I am what libraries and librarians have made me, with little assistance from a professor of Greek and poets.Friends, such as we desire, are dreams and fables.Light is the symbol of truth. --------=724104883379274 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Mauro-> http://gppahg.coolsos.info/?cophtxcdvkqx --------=724104883379274-- From majordomo@mil.doit.wisc.edu Fri Feb 10 05:55:01 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7VvZ-0006MZ-HW for ipfix-archive@megatron.ietf.org; Fri, 10 Feb 2006 05:55:01 -0500 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 FAA08164 for ; Fri, 10 Feb 2006 05:53:17 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F7Vnt-0007cO-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Feb 2006 04:47:05 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F7Vnr-0007c0-00 for ipfix@net.doit.wisc.edu; Fri, 10 Feb 2006 04:47:03 -0600 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Feb 2006 11:47:02 +0100 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 k1AAl05i011999; Fri, 10 Feb 2006 11:47:00 +0100 (MET) Received: from [10.61.64.161] (ams-clip-vpn-dhcp161.cisco.com [10.61.64.161]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA14438; Fri, 10 Feb 2006 10:46:59 GMT Message-ID: <43EC6F22.7010500@cisco.com> Date: Fri, 10 Feb 2006 10:46:58 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.10) Gecko/20050811 Fedora/1.7.10-1.2.1.legacy X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Carsten Schmoll CC: Thomas Dietz , Benoit Claise , Andrew Johnson , ipfix@net.doit.wisc.edu, Elisa Boschi Subject: Re: [ipfix] Floating point numbers in IPFIX References: <70524A4436C03E43A293958B505008B60DE35C@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: <70524A4436C03E43A293958B505008B60DE35C@EXCHSRV.fokus.fraunhofer.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carsten, > I think the reduction of precision is unavoidable (depending on the > concrete exported value). Therefore I would suggest some text like: > > "When using reduced encoding for double or float types make sure that > the potential loss of precision due to the smaller mantissa is > acceptable for your application." That sounds like an appropriate point for the implimentation guide? -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- 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 10 06:22:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7WMc-00083f-2z for ipfix-archive@megatron.ietf.org; Fri, 10 Feb 2006 06:22:58 -0500 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 GAA10190 for ; Fri, 10 Feb 2006 06:21:08 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F7WHr-0006kl-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Feb 2006 05:18:03 -0600 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F7WHp-0006kS-00 for ipfix@net.doit.wisc.edu; Fri, 10 Feb 2006 05:18:02 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 77324200C8E1; Fri, 10 Feb 2006 12:18:01 +0100 (CET) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21471-10; Fri, 10 Feb 2006 12:18:01 +0100 (CET) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 566502007D79; Fri, 10 Feb 2006 12:18:01 +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] Floating point numbers in IPFIX Date: Fri, 10 Feb 2006 12:17:47 +0100 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_016A_01C62E3C.01149780" Message-ID: <6D28EBC684A4D94096217AD2FE400873075FDC@venus.office> X-MS-Has-Attach: yes Thread-Topic: [ipfix] Floating point numbers in IPFIX Thread-Index: AcYuL1UmFnrVehLNTkK5A1U2LlxDGQABCe6g From: "Thomas Dietz" To: "Paul Aitken" , "Carsten Schmoll" Cc: "Benoit Claise" , "Andrew Johnson" , , "Elisa Boschi" X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_016A_01C62E3C.01149780 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Carsten and all, I think Paul is right. This should be taken to the implementation guidelines since this is not directly a protocol issue. Thomas -- Thomas Dietz Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany > -----Original Message----- > From: Paul Aitken [mailto:paitken@cisco.com] > Sent: Friday, February 10, 2006 11:47 AM > To: Carsten Schmoll > Cc: Thomas Dietz; Benoit Claise; Andrew Johnson; > ipfix@net.doit.wisc.edu; Elisa Boschi > Subject: Re: [ipfix] Floating point numbers in IPFIX > > Carsten, > > > I think the reduction of precision is unavoidable (depending on the > > concrete exported value). Therefore I would suggest some text like: > > > > "When using reduced encoding for double or float types make > sure that > > the potential loss of precision due to the smaller mantissa is > > acceptable for your application." > > That sounds like an appropriate point for the implimentation guide? > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > ------=_NextPart_000_016A_01C62E3C.01149780 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcDCCAvgw ggJhoAMCAQICAw9RdTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE3MDkwOTE3WhcNMDYwODE3MDkwOTE3WjBjMQ4wDAYDVQQE EwVEaWV0ejEPMA0GA1UEKhMGVGhvbWFzMRUwEwYDVQQDEwxUaG9tYXMgRGlldHoxKTAnBgkqhkiG 9w0BCQEWGlRob21hcy5EaWV0ekBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA4nhGGaCtAFl95e262kXtWs33/Co8wu3qnQqpmgEkgADwZV1ZGoNphSGYXWmdAO4S C+M2HFzsJ0FJ3eG4KV0IaI+kvuKQdfHbqKSV8OfUTIhwrzjwZVJBvUYagIBF8ksvo37XR8YPg5Hw j/zPFAbRhbGg/mrKj/Za7/P9ouv1onhwigQtOG5qcr3+MHE+I6lmkZM7FrzzNwYSJ0Jq52Q8BUEg LWdhLHnXDFy1d+tCZdtdEK3bKga13+Udc5jC0Yvg8hmY+nrxhUPKcYR038q404eJplla2qtpEC3O IoGTKLYRtcxAtoMQ1VG32AylLKJ59/GQDqXOjr9iCI4qyyj7zwIDAQABozcwNTAlBgNVHREEHjAc gRpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAE2PK+6rLfxJ5o+m3N28Uj0XGeArIfvLtnzZQDvuzz2jaThTjJ7PqULqOzjPsCGT/UsT2Ayo 2ksMnxzcVVIK4iJJlaJ2qJRrORakM2CfmkaxFkrJweezRfMPSp7tlW8QnZ/Johw746jZj5bcnOsV 0gxcXkhfMr9OcjEVsJ6+2eg6MIIDLTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkG A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYD VQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBE aXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIz MTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmlj YXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIs YyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56 fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUw AwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuo SpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMm CZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJ KoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjA dQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn 8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjAp BgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6 GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh eILcIRk13iSx0x1G/11fZU8xggNQMIIDTAIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDD1F1MAkGBSsOAwIaBQCgggG8MBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDIxMDExMTc0N1owIwYJKoZIhvcNAQkEMRYEFL6ICD9j SqdPfpXDgVlisBuN0sH4MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPUXUwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDD1F1MA0GCSqGSIb3DQEBAQUABIIBAACl93JxPCwnh4yx1x/I 8qnPzktzqfBkW0UBJbUAsqvHZDihB9WGgG6s4LWNfUMw7bM8bgsZu/DmQvEzebzbZyRp2t363r4F HNyMplKZ0GLCv1djgI2kb9tc86qaOFRNyLlbnWWdCE9+/KugkYIMMb3AlQ5zyuTjLRSIOK/AHrRt Ufel5x3vkcu78LcpYGyDRaQtYLElglyBNGL+/kSc9I2hLvSXVwVs6wQQuMgR8e4k3zxm53JP6Btw /CUG0mMwmCTg+W0p0PNWiLRrEfbGe+1xbKgledvMOZAz7gs7Kr40czmJ/vMEhRXbjeyHZeeWbE/3 D4m8XDB4I7zuevYRZHMAAAAAAAA= ------=_NextPart_000_016A_01C62E3C.01149780-- -- 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 10 06:23:53 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7WNV-0000cC-NI for ipfix-archive@megatron.ietf.org; Fri, 10 Feb 2006 06:23:53 -0500 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 GAA10269 for ; Fri, 10 Feb 2006 06:22:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F7WJe-0006xr-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Feb 2006 05:19:54 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F7WJc-0006xX-00 for ipfix@net.doit.wisc.edu; Fri, 10 Feb 2006 05:19:52 -0600 Received: from EXCHSRV.fokus.fraunhofer.de (einstein [10.147.9.230]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id k1ABJjv10232; Fri, 10 Feb 2006 12:19:45 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipfix] Floating point numbers in IPFIX Date: Fri, 10 Feb 2006 12:19:44 +0100 Message-ID: <70524A4436C03E43A293958B505008B60DE36A@EXCHSRV.fokus.fraunhofer.de> Thread-Topic: [ipfix] Floating point numbers in IPFIX Thread-Index: AcYuL1UmFnrVehLNTkK5A1U2LlxDGQABCe6gAAAZFMA= From: "Carsten Schmoll" To: "Thomas Dietz" , "Paul Aitken" Cc: "Benoit Claise" , "Andrew Johnson" , , "Elisa Boschi" Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Completely agree.=20 -----Original Message----- From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de]=20 Sent: Friday, February 10, 2006 12:18 PM To: Paul Aitken; Carsten Schmoll Cc: Benoit Claise; Andrew Johnson; ipfix@net.doit.wisc.edu; Elisa Boschi Subject: RE: [ipfix] Floating point numbers in IPFIX Carsten and all, I think Paul is right. This should be taken to the implementation guidelines since this is not directly a protocol issue. Thomas --=20 Thomas Dietz Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany =20 > -----Original Message----- > From: Paul Aitken [mailto:paitken@cisco.com]=20 > Sent: Friday, February 10, 2006 11:47 AM > To: Carsten Schmoll > Cc: Thomas Dietz; Benoit Claise; Andrew Johnson;=20 > ipfix@net.doit.wisc.edu; Elisa Boschi > Subject: Re: [ipfix] Floating point numbers in IPFIX >=20 > Carsten, >=20 > > I think the reduction of precision is unavoidable (depending on the=20 > > concrete exported value). Therefore I would suggest some text like: > >=20 > > "When using reduced encoding for double or float types make=20 > sure that > > the potential loss of precision due to the smaller mantissa is > > acceptable for your application." >=20 > That sounds like an appropriate point for the implimentation guide? >=20 > --=20 > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. >=20 -- 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 10 06:40:22 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7WdS-0006D2-Rb for ipfix-archive@megatron.ietf.org; Fri, 10 Feb 2006 06:40:22 -0500 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 GAA11381 for ; Fri, 10 Feb 2006 06:38:30 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F7WZa-0001zy-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Feb 2006 05:36:22 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F7WZY-0001zf-00 for ipfix@net.doit.wisc.edu; Fri, 10 Feb 2006 05:36:20 -0600 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Feb 2006 12:36:20 +0100 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 k1ABaH5i024545; Fri, 10 Feb 2006 12:36:17 +0100 (MET) Received: from [10.61.81.107] (ams-clip-vpn-dhcp4460.cisco.com [10.61.81.107]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA19303; Fri, 10 Feb 2006 11:36:16 GMT Message-ID: <43EC7AAF.5030703@cisco.com> Date: Fri, 10 Feb 2006 11:36:15 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carsten Schmoll CC: Thomas Dietz , Paul Aitken , Benoit Claise , Andrew Johnson , ipfix@net.doit.wisc.edu, Elisa Boschi Subject: Re: [ipfix] Floating point numbers in IPFIX References: <70524A4436C03E43A293958B505008B60DE36A@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: <70524A4436C03E43A293958B505008B60DE36A@EXCHSRV.fokus.fraunhofer.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carsten Schmoll wrote: >Completely agree. > >-----Original Message----- >From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de] >Sent: Friday, February 10, 2006 12:18 PM >To: Paul Aitken; Carsten Schmoll >Cc: Benoit Claise; Andrew Johnson; ipfix@net.doit.wisc.edu; Elisa Boschi >Subject: RE: [ipfix] Floating point numbers in IPFIX > >Carsten and all, > >I think Paul is right. This should be taken to the implementation >guidelines >since this is not directly a protocol issue. > >Thomas > > > Yes - permission to do it if you want and what it means if you get a smaller length in the template than you were expecting belongs in the protocol definition, but when you do it and what the implications are is an implementation guideline. - 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 Feb 10 07:36:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7XVN-0001gx-TC for ipfix-archive@megatron.ietf.org; Fri, 10 Feb 2006 07:36:05 -0500 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 HAA15477 for ; Fri, 10 Feb 2006 07:34:13 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F7XK9-0001jt-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Feb 2006 06:24:29 -0600 Received: from smtp.ee.ethz.ch ([129.132.2.219]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F7XK7-0001jP-00 for ipfix@net.doit.wisc.edu; Fri, 10 Feb 2006 06:24:27 -0600 Received: from localhost (tranquillity.ee.ethz.ch [129.132.2.222]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4F0ABD93C9; Fri, 10 Feb 2006 13:24:24 +0100 (MET) Received: from smtp.ee.ethz.ch ([129.132.2.217]) by localhost (tranquillity [129.132.2.222]) (amavisd-new, port 10024) with LMTP id 12161-02-2; Fri, 10 Feb 2006 13:24:24 +0100 (MET) Received: from [82.130.102.210] (nb-4995.ethz.ch [82.130.102.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1024ED93A7; Fri, 10 Feb 2006 13:24:24 +0100 (MET) Message-ID: <43EC86FB.60504@fokus.fraunhofer.de> Date: Fri, 10 Feb 2006 13:28:43 +0100 From: Elisa Boschi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Aitken Cc: Carsten Schmoll , Thomas Dietz , Benoit Claise , Andrew Johnson , ipfix@net.doit.wisc.edu, Elisa Boschi Subject: Re: [ipfix] Floating point numbers in IPFIX References: <70524A4436C03E43A293958B505008B60DE35C@EXCHSRV.fokus.fraunhofer.de> <43EC6F22.7010500@cisco.com> In-Reply-To: <43EC6F22.7010500@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at ee.ethz.ch Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all, >> I think the reduction of precision is unavoidable (depending on the >> concrete exported value). Therefore I would suggest some text like: >> >> "When using reduced encoding for double or float types make sure that >> the potential loss of precision due to the smaller mantissa is >> acceptable for your application." > > > That sounds like an appropriate point for the implimentation guide? I agree. I've added this issue to the guidelines. cheers, 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 mendeeann@vvi.net Sun Feb 12 22:16:22 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8UCM-0002VG-H0 for ipfix-archive@megatron.ietf.org; Sun, 12 Feb 2006 22:16:22 -0500 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 WAA05792 for ; Sun, 12 Feb 2006 22:14:37 -0500 (EST) Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F8TuR-0002Rx-00 for ipfix-list@mil.doit.wisc.edu; Sun, 12 Feb 2006 20:57:51 -0600 Received: from vvi.net (host224-229.pool877.interbusiness.it [87.7.229.224]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k1CHG4RG028665 for ; Sun, 12 Feb 2006 11:16:06 -0600 Message-ID: <000001c62ff7$875e0030$008da8c0@asphodel> Reply-To: "Annabelle Mendel" From: "Annabelle Mendel" To: "Kamal Petros" Subject: Re: eugenics figure Date: Sun, 12 Feb 2006 12:12:40 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C62FCD.9E87F830" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C62FCD.9E87F830 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, http://www.ompoun.com =20 VzIkArGzRtAl g$v3b,f7y5v VsAnLdlmUgMe f$t1g,i2q1g CpIiAlLoIkSx i$p3a,r3s3v ------=_NextPart_000_0001_01C62FCD.9E87F830 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
VzIkArGzRtAl g$v3b,f7y5v
VsAnLdlmUgMe f$t1g,i2q1g
CpIiAlLoIkSx i$p3a,r3s3v
------=_NextPart_000_0001_01C62FCD.9E87F830-- From su_bu_ta2000@yahoo.co.jp Mon Feb 13 02:31:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8YBL-0002h9-So for ipfix-archive@megatron.ietf.org; Mon, 13 Feb 2006 02:31:35 -0500 Received: from ocn.ne.jp ([221.212.59.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21181 for ; Mon, 13 Feb 2006 02:29:48 -0500 (EST) Date: Mon, 13 Feb 2006 02:29:48 -0500 (EST) Message-Id: <200602130729.CAA21181@ietf.org> Received: from wwaawgdi9 (unknown [239.37.87.69]) by smtp84 (Coremail) with SMTP id GXcTZZXRx85FRsK7.1 for ; Mon, 13 Feb 2006 16:32:02 +0800 (CST) X-Originating-IP: [239.37.87.69] Subject: =?iso-2022-jp?B?GyRCJV4lcyViJTklNSUkJUgbKEI=?= From: =?gb2312?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C627B4.0350C7A0" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C627B4.0350C7A0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCISEhISEnISEbKEIgIBskQiguIUQoLyguKCwoLyguIUQoLyguKCwoLyguIUQoLxsoQg0KGyRC IUQheiFEISEbKEIgGyRCTDUbKEIgICAgICAgGyRCTkEbKEIgICAgICAgGyRCPVAbKEIgICAgICAb JEIycRsoQiAgICAgICAbJEIkJBsoQg0KGyRCISEhISEnISEbKEIgIBskQigxKCwoMCgxIUQoMCgx KCwoMCgxIUQoMCgxKCwoMBsoQg0KGyRCISEhISEhISEhISguKCwoLyguIUQoLyguKCwoLyguIUQo LyguKCwoLyguIUQoLyEhIScbKEINChskQiEhISEhISEhISEbKEIgICAbJEI2YRsoQiAgICAgIBsk Qj5sGyhCICAgICAgICAbJEIkRxsoQiAgICAgIBskQj1QGyhCICAgICAgGyRCMnEbKEIgICAgICAg IBskQiQmGyhCICAbJEIhRCF6IUQbKEINChskQiEhISEhISEhISEoMSFEKDAoMSgsKDAoMSFEKDAo MSgsKDAoMSFEKDAoMSgsKDAhISEnGyhCICAgICAgICAgICAgICAgICAgICANCiAgDQobJEI9d0At JCskaTtIJCQkPyQkPVAycSQkN08lNSUkJUglaSVzJS0lcyUwJDQ2YT1qN09JdExnQmgbKEIxGyRC MEwbKEIhIQ0KaHR0cDovL3d3dy5kZWFpLXN0eWxlLm5ldC9jYXNhbm92YS8/MTkzNg0KGyRCIiIo LCgsKCwoLCgsKCwoLCgsIiIbKEI9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KGyRCKC0bKEJbXDBdGyRCQTQ5cTdHPChIRBsoQiEhGyRCKC0hISItIi0l bSUwJSQlc0NmJE49d0AtJHI8TD8/JEdDNSQ7JEEkYyQmISoiLSItGyhCDQobJEIoLUNPODUkTkQ+ JWEkQ0w8IXkoLSEhGyhCaHR0cDovL3d3dy5kZWFpLXN0eWxlLm5ldC9jYXNhbm92YS8/MTkzNg0K GyRCIiIoLCgsKCwoLCgsKCwoLCgsIiIbKEI9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PSAgDQobJEIhISE7JDkkMCRLMCkkJCQ/JCQ/TUksOCshKiEqIVQ0 MEE0TDVOQSFVGyhCDQobJEIhISE7Mmg0fEUqNSFHPSQsPzdFUD5sIVpMNU5BJCo7biQ3N0c8KEhE OCE6dyFbGyhCDQobJEIhISE7JW0lMCUkJXNDZiROPXdALSRyPEw/PyRHQzUkOyRBJGMkJiEqGyhC DQobJEIiLSItIi0iLSItIi0kMyQzJCskaTghOnciLSItIi0iLSItIi0bKEINCmh0dHA6Ly93d3cu ZGVhaS1zdHlsZS5uZXQvY2FzYW5vdmEvPzE5MzYNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NChskQiFEIUQhRCFEIUQhRCFEIUQhRCFE IUQhRCFEIUQhRCFEIUQhRCFEIUQhRCFEIUQhRCFEIUQhRCFEIUQhRBsoQg0KGyRCNS5KfSROPGok TkZPJC81d04lJEskJCRrJCskbyQkJCQ7UiRyNS5KfSROJGIkTiRLJDkkayQ/JGEkTiU1JSQlSCRH JDkheRsoQg0KGyRCRjEkODFoQH4kTjtSJEgycSQkJD8kJCEqNlBMM0BoJE42YSQvJEc4KyREJDEk PyQkISokSiRJTU0hOSRKTVdLPiRLJCpFeiQoGyhCDQobJEIkRyQtJF4kOSEjGyhCDQpodHRwOi8v d3d3LmRlYWktc3R5bGUubmV0L2Nhc2Fub3ZhLz8xOTM2DQobJEJNJSQ3JC8kRiNIJEokIiROTDwk SCRhITwkayQ3JEEkYyQoIXkbKEINChskQiReJDokT0w1TkEkRyQqO24kN0JOODM8QjtcQ2YheRso Qg0KGyRCIUQhRCFEIUQhRCFEIUQhRCFEIUQhRCFEIUQhRCFEIUQhRCFEIUQhRCFEIUQhRCFEIUQh RCFEIUQhRCFEGyhCDQoNCg0KDQoNChskQiVhITwla0lUTVckTkp9JE8kMyRBJGkiLRsoQg0KY29u Y2VwdDJfbmV0QHlhaG9vLmNhDQo= ------=_NextPart_000_0009_01C627B4.0350C7A0 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGlj IiBzaXplPTI+PEZPTlQgc2l6ZT0zPhskQiEhGyhCPC9GT05UPjxGT05UIHNpemU9Mj4bJEIhISEn ISEbKEIgDQombmJzcDsbJEIoLiFEKC8oLigsKC8oLiFEKC8oLigsKC8oLiFEKC8bKEI8QlI+GyRC IUQheiFEISEbKEIgGyRCTDUbKEImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQobJEJOQRsoQiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAbJEI9UBsoQiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANChskQjJxGyhCJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IBskQiQkGyhCPEJSPhskQiEhISEhJyEhGyhCJm5ic3A7IA0KGyRC KDEoLCgwKDEhRCgwKDEoLCgwKDEhRCgwKDEoLCgwGyhCPEJSPhskQiEhISEhISEhISEoLigsKC8o LiFEKC8oLigsKC8oLiFEKC8oLigsKC8oLiFEKC8hISEnGyhCPEJSPhskQiEhISEhISEhISEbKEIm bmJzcDsmbmJzcDsmbmJzcDsbJEI2YRsoQiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOxskQj5sGyhCJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K GyRCJEcbKEImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgGyRCPVAbKEImbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQobJEIycRsoQiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAbJEIkJhsoQiZuYnNwOyANChskQiFEIXohRBsoQjxCUj4bJEIhISEh ISEhISEhKDEhRCgwKDEoLCgwKDEhRCgwKDEoLCgwKDEhRCgwKDEoLCgwISEhJxsoQiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjwvRk9O VD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjxG T05UIHNpemU9Mj48Rk9OVCBzaXplPTM+Jm5ic3A7IA0KPC9GT05UPjxCUj4bJEI9d0AtJCskaTtI JCQkPyQkPVAycSQkN08lNSUkJUglaSVzJS0lcyUwJDQ2YT1qN09JdExnQmgbKEIxGyRCMEwbKEIh ITxCUj48L0ZPTlQ+PEEgDQpocmVmPSJodHRwOi8vd3d3LmRlYWktc3R5bGUubmV0L2Nhc2Fub3Zh Lz8xOTM2Ij5odHRwOi8vd3d3LmRlYWktc3R5bGUubmV0L2Nhc2Fub3ZhLz8xOTM2PC9BPjxCUj4b JEIiIigsKCwoLCgsKCwoLCgsKCwiIhsoQj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PEJSPhskQigtGyhCW1wwXRskQkE0OXE3RzwoSEQbKEIhIRskQigt ISEiLSItJW0lMCUkJXNDZiROPXdALSRyPEw/PyRHQzUkOyRBJGMkJiEqIi0iLRsoQjxCUj4bJEIo LUNPODUkTkQ+JWEkQ0w8IXkoLSEhGyhCPEEgDQpocmVmPSJodHRwOi8vd3d3LmRlYWktc3R5bGUu bmV0L2Nhc2Fub3ZhLz8xOTM2Ij5odHRwOi8vd3d3LmRlYWktc3R5bGUubmV0L2Nhc2Fub3ZhLz8x OTM2PC9BPjxCUj4bJEIiIigsKCwoLCgsKCwoLCgsKCwiIhsoQj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Jm5ic3A7IA0KPEJSPhskQiEhITskOSQwJEsw KSQkJD8kJD9NSSw4KyEqISohVDQwQTRMNU5BIVUbKEI8QlI+GyRCISEhOzJoNHxFKjUhRz0kLD83 RVA+bCFaTDVOQSQqO24kNzdHPChIRDghOnchWxsoQjxCUj4bJEIhISE7JW0lMCUkJXNDZiROPXdA LSRyPEw/PyRHQzUkOyRBJGMkJiEqGyhCPEJSPhskQiItIi0iLSItIi0iLSQzJDMkKyRpOCE6dyIt Ii0iLSItIi0iLRsoQjxCUj48QSANCmhyZWY9Imh0dHA6Ly93d3cuZGVhaS1zdHlsZS5uZXQvY2Fz YW5vdmEvPzE5MzYiPmh0dHA6Ly93d3cuZGVhaS1zdHlsZS5uZXQvY2FzYW5vdmEvPzE5MzY8L0E+ PEJSPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08QlI+GyRCIUQhRCFEIUQhRCFEIUQhRCFEIUQhRCFEIUQhRCFEIUQhRCFEIUQhRCFEIUQh RCFEIUQhRCFEIUQhRCFEGyhCPEJSPhskQjUuSn0kTjxqJE5GTyQvNXdOJSRLJCQkayQrJG8kJCQk O1IkcjUuSn0kTiRiJE4kSyQ5JGskPyRhJE4lNSUkJUgkRyQ5IXkbKEI8QlI+GyRCRjEkODFoQH4k TjtSJEgycSQkJD8kJCEqNlBMM0BoJE42YSQvJEc4KyREJDEkPyQkISokSiRJTU0hOSRKTVdLPiRL JCpFeiQoGyhCPEJSPhskQiRHJC0kXiQ5ISMbKEI8QlI+PEEgDQpocmVmPSJodHRwOi8vd3d3LmRl YWktc3R5bGUubmV0L2Nhc2Fub3ZhLz8xOTM2Ij5odHRwOi8vd3d3LmRlYWktc3R5bGUubmV0L2Nh c2Fub3ZhLz8xOTM2PC9BPjxCUj4bJEJNJSQ3JC8kRiNIJEokIiROTDwkSCRhITwkayQ3JEEkYyQo IXkbKEI8QlI+GyRCJF4kOiRPTDVOQSRHJCo7biQ3Qk44MzxCO1xDZiF5GyhCPEJSPhskQiFEIUQh RCFEIUQhRCFEIUQhRCFEIUQhRCFEIUQhRCFEIUQhRCFEIUQhRCFEIUQhRCFEIUQhRCFEIUQhRBso QjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0y PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj4bJEIlYSE8JWtJVE1XJE5KfSRPJDMkQSRpIi0bKEI8QlI+PC9GT05UPjxGT05UIGZhY2U9GyRC QVdCThsoQiBzaXplPTI+PEEgDQpocmVmPSJtYWlsdG86Y29uY2VwdDJfbmV0QHlhaG9vLmNhIj5j b25jZXB0Ml9uZXRAeWFob28uY2E8L0E+PC9GT05UPjxBIA0KaHJlZj0ibWFpbHRvOmNvbmNlcHRf bmV0QHlhaG9vLmNhIj48Rk9OVCANCnNpemU9Mj48L0ZPTlQ+PC9BPjxCUj48L0RJVj48L0JPRFk+ PC9IVE1MPg0K ------=_NextPart_000_0009_01C627B4.0350C7A0-- From majordomo@mil.doit.wisc.edu Mon Feb 13 04:07:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8Zfr-0004uY-Oz for ipfix-archive@megatron.ietf.org; Mon, 13 Feb 2006 04:07:13 -0500 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 EAA27329 for ; Mon, 13 Feb 2006 04:05:26 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F8ZVs-00065v-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Feb 2006 02:56:52 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F8ZVr-00065i-00 for ipfix@net.doit.wisc.edu; Mon, 13 Feb 2006 02:56:51 -0600 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k1D8ump11589; Mon, 13 Feb 2006 09:56:48 +0100 (CET) Received: from [10.61.81.9] (ams-clip-vpn-dhcp4362.cisco.com [10.61.81.9]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k1D8ukC05706; Mon, 13 Feb 2006 09:56:46 +0100 (CET) Message-ID: <43F049BA.2000503@cisco.com> Date: Mon, 13 Feb 2006 09:56:26 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Juergen Quittek CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX followup charter References: <399327FA4D1893115F68503B@[192.168.1.128]> In-Reply-To: <399327FA4D1893115F68503B@[192.168.1.128]> Content-Type: multipart/alternative; boundary="------------030309060406000000060508" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------030309060406000000060508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Juergen and all, Thanks for proposing a new charter. I agree that there are a lot of activities and interest around IPFIX, and that a new charter is suitable. 1. The implementation guidelines draft is a must in this new charter. Note that I gave a long list of issues regarding this draft, and that I don't think its status is close to completion yet. Regarding the per packet draft, I think the right choice to do is to make this concept generic, as discussed already. As a consequence, I would see its content as a new section in the implementation guideline draft, called something such as "implementation choice for the reduction of export". Anyway, I really consider the concepts behind the per-packet info as implementation guideline! If we combine those two drafts, we can kill one bird with half a stone :) (private joke) 2. The flow aggregation is interesting. I must admit that I haven't spent a great of deal of time reviewing it though. 3. If we take the initial idea to have 3 work items in the WG charter, I'm wondering which one to take next. I tend to think that only looking at the current maturity of the drafts might not be appropriate, as opposed to ask ourselves the question: do we solve the right issue in this new charter? Next to the IPFIX transport issue, the second highest amount of emails generated on the list concerned "IPFIX for billing" I sketched a few initial ideas in draft-bclaise-ipfix-reliability-00.txt. I agree so that we're missing some meat at this point, but a second draft version will be posted before Dallas. So my vote would go for this work: not because I'm the author, but because this is an important item to solve. Note: I'm personally not convinced by the bi-flow draft. I browsed through the bi-flow draft, and had some non-trivial concerns. Regards, Benoit. > Dear all, > > As you know, the IPFIX working group has completed its charter > by submitting all planned documents (with a delay of several years) > to the IESG for publication as RFC. Also the PSAMP WG will reach > this status soon. > > Building on the results of these WGs, there are a lot of related > ongoing activities that are producing Internet drafts related to > IPFIX. Several of them have already been presented at recent IPFIX > and PSAMP sessions. But working on them is not covered by the IPFIX > or PSAMP charter. If we want to continue this IPFIX-related work, > we need a new charter that gives it a home at the IETF. > > The text below lists and discusses related work and suggests a > charter for a follow-up WG. It is the output of several discussions > with Tanja, Benoit, and Nevil. > > The proposed charter is very short-lived and includes only the three > most mature work items out of a longer list of candidates. The basic > idea is completing this charter within less than a year and then > re-chartering to cover further work items that have progressed until > then. This lean work model with short-lived charters allows the group > to focus on a limited number of issues and is preferable to long-lived > WGs working on many issues in parallel. (It is highly recommended > by the IESG.) > > Please have a look at it and state whether or not you think it makes > sense to have an IPFIX follow-up WG. Also please read the proposed > charter carefully and express your objections, concerns, comments, > requests for modifications, etc. > > The plan is to elaborate the new charter proposal on this list and > submit an agreed version to our area directors soon. The deadline > for requesting BoF sessions at the next IETF meeting in Dallas is > February 13. > > Thanks, > > Juergen > > > ======================================================= > Why do we need to continue the work of IPFIX and PSAMP? > ======================================================= > > IPFIX has completed its charter and PSAMP will do so very soon. > Still, there > are a lot of ongoing activities in the community of these two WGs: > > 1. Flow aggregation > draft-dressler-ipfix-aggregation-01.txt > > 2. reducing redundancy in IPFIX and PSAMP reports > draft-boschi-export-perpktinfo-00.txt > > 3. IPFIX implementation guidelines > draft-boschi-ipfix-implementation-guidelines-00.txt > > 4. Path-coupled meter configuration > draft-fessi-nsis-m-nslp-framework-02.txt > draft-dressler-nsis-metering-nslp-03.txt > (currently under discussion in the NSIS WG, but not covered > by the NSIS charter. It is a candidate work item for NSIS > re-chartering, but the NSIS WG asks if it would not be better > covered by IPFIX) > > 5. IPFIX reliability > draft-bclaise-ipfix-reliability-00.txt > > 6. Reporting bi-directional flows with IPFIX > draft-boschi-ipfix-biflow-01.txt > > 7. a format for storing IPFIX records > draft-trammell-ipfix-file-00.txt > > 8. IPFIX MIB module > no I-D yet, but two teams working on it independently. > > 9. Common IPFIX templates > draft-stephan-isp-templates-01.txt > > 10. Reliable server pooling for IPFIX > draft-coene-rserpool-applic-ipfix-01.txt > > 11. Flow sampling > draft-molina-flow-selection-00.txt (expired) > > Did I miss something? > > > 1.-4. and 9. have already been discussed at past IPFIX or PSAMP sessions. > > This list shows two things. > - There is a community interested in IPFIX that is not too small. > - This community and is willing to further work on issues IPFIX-related > issues in the IETF. > This is a very good starting point for a charter discussion. > > > ============================ > Which work items are suited? > ============================ > > Not all of the issues listed above are at a stage, where they should be > considered as a WG work item, but 1.-4. are quite well developed and 5. > and 6. are candidates. Since 4. is a candidate for NSIS re-chartering, > I dropped it from the following considerations. > > Each of 1.-3. has been presented at IPFIX or PSAMP sessions already > two times > with some discussion on the suggested approach. For all I sense an > agreement > in the IPFIX WG (at least no objections so far) that these issues are > relevant > work and potential WG work items (to be confirmed on the list, of > course). > > - The flow aggregation work is rather mature. Actually this draft > covers > something that is missing in IPFIX: How to tell the collector that the > metering probe does not have the standard (Netflow default) > configuration, > but filters and aggregates certain flows. > There are some terminology problems and a set of technical issues > to be > solved, but there is not problem with the general direction and the > chosen > approach. Still, thorough reviews are missing as well as a > discussion on > how to fit it well into the IPFIX architecture. > > - Reducing redundancy in IPFIX and PSAMP reports is an issue that was > received very well by both WGs when past versions of the IDs were > presented. > It is considered a useful method of applying IPFIX efficiently. > Still, the current drafts were considered as to specific. They apply > the optimization to packet reports only. At the last PSAMP meeting > it was > noted that the method should be generalized such that it can be > applied to > all redundant IPFIX transmissions. This generalization needs to be > done, > but the way to go is clear and basically agreed on. > > - The implementation guidelines are considered the most important > work item > by many WG members (including myself). Many people are currently > implementing > IPFIX and several recommendations were identified at the first > IPFIX interop > (next one is scheduled for end of February). The sooner this > document is > available, the more will help improving ongoing implementations. > My problem with this item is that the current individual draft is > in a bad > shape. Therefore, the milestones for this item are later than for the > others. > > The two weaker candidates for WG items are IPFIX reliability and > reporting of > bidirectional flows. Both have been requested on the IPFIX mailing > list several > time in the past years, but we could not agree on making them part of > the basic > IPFIX standard. > But as add-ons, that integrate well with the standard, they can be > considered, > particularly since I heard about operator requests for both of them. > A problem of these issues is that so far they have not been presented > at IPFIX > or PSAMP sessions and there has not been a discussion yet on the > approaches > followed by the existing drafts. Therefore, these two are not > included in the > draft proposal below. > > > ================================= > Charter Proposal: > Efficient Use of IPFIX (USEIPFIX) > ================================= > > The IPFIX working group has specified the IPFIX protocol for exporting > flow records. The PSAMP working group has specified the usage of the > IPFIX protocol for exporting packet records. With both specifications > available, several implementers have started building applications > using the IPFIX protocol. > > At a first interoperability testing event, several IPFIX protocol > implementations were tested. The experiences made at this event were > fed back to IPFIX protocol specification, particularly for removing > ambiguities. In addition, several lessons were learned about how to > implement and use IPFIX correctly and efficiently. The exchange among > different implementers further led to new ideas for advanced usage of > IPFIX. Many of these ideas are currently documented in individual > Internet drafts. > > The goal of the USEIPFIX working group is producing best current > practice and guideline documents concerning implementation, application > and usage of the IPFIX protocol. > > Out of scope are modifications of the core IPFIX and PSAMP protocol > specifications. In scope is the definition of new IPFIX and PSAMP > information elements within the documents produced by the USEIPFIX WG. > > Specific Goals of the USEIPFIX WG are: > > o Developing guidelines for implementers based on experiences > gained individually by implementers and jointly at interoperability > testing events. The guidelines will give recommendations for > integrating IPFIX observation points, measurement processes, and > exporting processes into the packet flow at different kinds of IPFIX > devices. They will make suggestions for efficient implementation of > the IPFIX protocol features and identify parts of the IPFIX > specification that have already been misunderstood by several > implementers. For some implementation choices that the protocol > specification leaves to the implementer, the guidelines will discuss > advantages and disadvantages of the different choices. > > o Developing methods and means for an efficient use of the IPFIX > protocol that reduces redundancy in flow reports. The basic idea > to be followed is very simple. For multiple flow records that all > report the same value in one or more of the contained IPFIX > information elements, these values are removed from the flow records > and instead reported once for all in a separate record. Such an > approach integrates very well with the IPFIX protocol and only needs > few means for expressing the relationship between flow records and > corresponding separate records. > > o Develop a method for flow aggregation reducing the amount of > measurement data exchanged between IPFIX exporters and IPFIX > collectors. Using aggregation techniques, measurement information of > multiple similar flows is aggregated into few meta-flow records. > Applied aggregation rules need to be communicate. > > o Investigate further ways of efficiently using the IPFIX protocols > including but not limited to > - providing reliability for IPFIX transmissions, > - reporting bi-directional flows, > - path-coupled configuration of IPFIX devices, > - reporting the configuration of IPFIX devices, > - flow sampling at IPFIX devices, > - storing IPFIX flow records and packet records. > These issues are not current work items of the USEIPFIX WG but are > evaluated as candidates for potential future work items. > > > Milestones: > > Mar 2006 Initial version of flow aggregation methods > Mar 2006 Initial version of reducing redundandy in IPFIX records > Mar 2006 IPFIX and PSAMP interoperability testing event (not a real > WG milestone?) > Apr 2006 Initial version of implementation guidelines > Jul 2006 Submit flow aggregation methods to IESG > Sep 2006 Submit reducing redundancy in IPFIX records to IESG > Sep 2006 Submit implementation guidelines to IESG > > > -- > 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/ --------------030309060406000000060508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Juergen and all,

Thanks for proposing a new charter. I agree that there are a lot of activities and interest around IPFIX, and that a new charter is suitable.

1. The implementation guidelines draft is a must in this new charter. Note that I gave a long list of issues regarding this draft, and that I don't think its status is close to completion yet.
Regarding the per packet draft, I think the right choice to do is to make this concept generic, as discussed already. As a consequence, I would see its content as a new section in the implementation guideline draft, called something such as "implementation choice for the reduction of export". Anyway, I really consider the concepts behind the per-packet info as implementation guideline!
If we combine those two drafts, we can kill one bird with half a stone :) (private joke)

2. The flow aggregation is interesting. I must admit that I haven't spent a great of deal of time reviewing it though.

3. If we take the initial idea to have 3 work items in the WG charter, I'm wondering which one to take next. I tend to think that only looking at the current maturity of the drafts might not be appropriate, as opposed to ask ourselves the question: do we solve the right issue in this new charter?
Next to the IPFIX transport issue, the second highest amount of emails generated on the list concerned "IPFIX for billing"
I sketched a few initial ideas in draft-bclaise-ipfix-reliability-00.txt. I agree so that we're missing some meat at this point, but a second draft version will be posted before Dallas. So my vote would go for this work: not because I'm the author, but because this is an important item to solve.

Note: I'm personally not convinced by the bi-flow draft. I browsed through the bi-flow draft, and had some non-trivial concerns. 
Regards, Benoit.
Dear all,

As you know, the IPFIX working group has completed its charter
by submitting all planned documents (with a delay of several years)
to the IESG for publication as RFC.  Also the PSAMP WG will reach
this status soon.

Building on the results of these WGs, there are a lot of related
ongoing activities that are producing Internet drafts related to
IPFIX.  Several of them have already been presented at recent IPFIX
and PSAMP sessions.  But working on them is not covered by the IPFIX
or PSAMP charter.  If we want to continue this IPFIX-related work,
we need a new charter that gives it a home at the IETF.

The text below lists and discusses related work and suggests a
charter for a follow-up WG.  It is the output of several discussions
with Tanja, Benoit, and Nevil.

The proposed charter is very short-lived and includes only the three
most mature work items out of a longer list of candidates.  The basic
idea is completing this charter within less than a year and then
re-chartering to cover further work items that have progressed until
then.  This lean work model with short-lived charters allows the group
to focus on a limited number of issues and is preferable to long-lived
WGs working on many issues in parallel.  (It is highly recommended
by the IESG.)

Please have a look at it and state whether or not you think it makes
sense to have an IPFIX follow-up WG.  Also please read the proposed
charter carefully and express your objections, concerns, comments,
requests for modifications, etc.

The plan is to elaborate the new charter proposal on this list and
submit an agreed version to our area directors soon.  The deadline
for requesting BoF sessions at the next IETF meeting in Dallas is
February 13.

Thanks,

   Juergen


=======================================================
Why do we need to continue the work of IPFIX and PSAMP?
=======================================================

IPFIX has completed its charter and PSAMP will do so very soon.  Still, there
are a lot of ongoing activities in the community of these two WGs:

1. Flow aggregation
  draft-dressler-ipfix-aggregation-01.txt

2. reducing redundancy in IPFIX and PSAMP reports
  draft-boschi-export-perpktinfo-00.txt

3. IPFIX implementation guidelines
  draft-boschi-ipfix-implementation-guidelines-00.txt

4. Path-coupled meter configuration
  draft-fessi-nsis-m-nslp-framework-02.txt
  draft-dressler-nsis-metering-nslp-03.txt
  (currently under discussion in the NSIS WG, but not covered
  by the NSIS charter. It is a candidate work item for NSIS
  re-chartering, but the NSIS WG asks if it would not be better
  covered by IPFIX)

5. IPFIX reliability
  draft-bclaise-ipfix-reliability-00.txt

6. Reporting bi-directional flows with IPFIX
  draft-boschi-ipfix-biflow-01.txt

7. a format for storing IPFIX records
  draft-trammell-ipfix-file-00.txt

8. IPFIX MIB module
  no I-D yet, but two teams working on it independently.

9. Common IPFIX templates
  draft-stephan-isp-templates-01.txt

10. Reliable server pooling for IPFIX
   draft-coene-rserpool-applic-ipfix-01.txt

11. Flow sampling
   draft-molina-flow-selection-00.txt (expired)

Did I miss something?


1.-4. and 9. have already been discussed at past IPFIX or PSAMP sessions.

This list shows two things.
 - There is a community interested in IPFIX that is not too small.
 - This community and is willing to further work on issues IPFIX-related
   issues in the IETF.
This is a very good starting point for a charter discussion.


============================
Which work items are suited?
============================

Not all of the issues listed above are at a stage, where they should be
considered as a WG work item, but 1.-4. are quite well developed and 5.
and 6. are candidates.  Since 4. is a candidate for NSIS re-chartering,
I dropped it from the following considerations.

Each of 1.-3. has been presented at IPFIX or PSAMP sessions already two times
with some discussion on the suggested approach.  For all I sense an agreement
in the IPFIX WG (at least no objections so far) that these issues are relevant
work and potential WG work items (to be confirmed on the list, of course).

 - The flow aggregation work is rather mature.  Actually this draft covers
   something that is missing in IPFIX: How to tell the collector that the
   metering probe does not have the standard (Netflow default) configuration,
   but filters and aggregates certain flows.
   There are some terminology problems and a set of technical issues to be
   solved, but there is not problem with the general direction and the chosen
   approach.  Still, thorough reviews are missing as well as a discussion on
   how to fit it well into the IPFIX architecture.

 - Reducing redundancy in IPFIX and PSAMP reports is an issue that was
   received very well by both WGs when past versions of the IDs were presented.
   It is considered a useful method of applying IPFIX efficiently.
   Still, the current drafts were considered as to specific.  They apply
   the optimization to packet reports only. At the last PSAMP meeting it was
   noted that the method should be generalized such that it can be applied to
   all redundant IPFIX transmissions.  This generalization needs to be done,
   but the way to go is clear and basically agreed on.

 - The implementation guidelines are considered the most important work item
   by many WG members (including myself).  Many people are currently implementing
   IPFIX and several recommendations were identified at the first IPFIX interop
   (next one is scheduled for end of February).  The sooner this document is
   available, the more will help improving ongoing implementations.
   My problem with this item is that the current individual draft is in a bad
   shape.  Therefore, the milestones for this item are later than for the
   others.

The two weaker candidates for WG items are IPFIX reliability and reporting of
bidirectional flows.  Both have been requested on the IPFIX mailing list several
time in the past years, but we could not agree on making them part of the basic
IPFIX standard.
But as add-ons, that integrate well with the standard, they can be considered,
particularly since I heard about operator requests for both of them.
A problem of these issues is that so far they have not been presented at IPFIX
or PSAMP sessions and there has not been a discussion yet on the approaches
followed by the existing drafts.  Therefore, these two are not included in the
draft proposal below.


=================================
Charter Proposal:
Efficient Use of IPFIX (USEIPFIX)
=================================

The IPFIX working group has specified the IPFIX protocol for exporting
flow records. The PSAMP working group has specified the usage of the
IPFIX protocol for exporting packet records. With both specifications
available, several implementers have started building applications
using the IPFIX protocol.

At a first interoperability testing event, several IPFIX protocol
implementations were tested. The experiences made at this event were
fed back to IPFIX protocol specification, particularly for removing
ambiguities.  In addition, several lessons were learned about how to
implement and use IPFIX correctly and efficiently.  The exchange among
different implementers further led to new ideas for advanced usage of
IPFIX.  Many of these ideas are currently documented in individual
Internet drafts.

The goal of the USEIPFIX working group is producing best current
practice and guideline documents concerning implementation, application
and usage of the IPFIX protocol.

Out of scope are modifications of the core IPFIX and PSAMP protocol
specifications.  In scope is the definition of new IPFIX and PSAMP
information elements within the documents produced by the USEIPFIX WG.

Specific Goals of the USEIPFIX WG are:

o Developing guidelines for implementers based on experiences
 gained individually by implementers and jointly at interoperability
 testing events.  The guidelines will give recommendations for
 integrating IPFIX observation points, measurement processes, and
 exporting processes into the packet flow at different kinds of IPFIX
 devices.  They will make suggestions for efficient implementation of
 the IPFIX protocol features and identify parts of the IPFIX
 specification that have already been misunderstood by several
 implementers.  For some implementation choices that the protocol
 specification leaves to the implementer, the guidelines will discuss
 advantages and disadvantages of the different choices.

o Developing methods and means for an efficient use of the IPFIX
 protocol that reduces redundancy in flow reports.  The basic idea
 to be followed is very simple.  For multiple flow records that all
 report the same value in one or more of the contained IPFIX
 information elements, these values are removed from the flow records
 and instead reported once for all in a separate record.  Such an
 approach integrates very well with the IPFIX protocol and only needs
 few means for expressing the relationship between flow records and
 corresponding separate records.

o Develop a method for flow aggregation reducing the amount of
 measurement data exchanged between IPFIX exporters and IPFIX
 collectors.  Using aggregation techniques, measurement information of
 multiple similar flows is aggregated into few meta-flow records.
 Applied aggregation rules need to be communicate.

o Investigate further ways of efficiently using the IPFIX protocols
 including but not limited to
   - providing reliability for IPFIX transmissions,
   - reporting bi-directional flows,
   - path-coupled configuration of IPFIX devices,
   - reporting the configuration of IPFIX devices,
   - flow sampling at IPFIX devices,
   - storing IPFIX flow records and packet records.
 These issues are not current work items of the USEIPFIX WG but are
 evaluated as candidates for potential future work items.


Milestones:

Mar 2006  Initial version of flow aggregation methods
Mar 2006  Initial version of reducing redundandy in IPFIX records
Mar 2006  IPFIX and PSAMP interoperability testing event (not a real WG milestone?)
Apr 2006  Initial version of implementation guidelines
Jul 2006  Submit flow aggregation methods to IESG
Sep 2006  Submit reducing redundancy in IPFIX records to IESG
Sep 2006  Submit implementation guidelines to IESG


--
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/

--------------030309060406000000060508-- -- 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 chesney@acninc.net Mon Feb 13 09:02:25 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8eHX-00006I-Tp for ipfix-archive@megatron.ietf.org; Mon, 13 Feb 2006 09:02:25 -0500 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 JAA21606 for ; Mon, 13 Feb 2006 09:00:37 -0500 (EST) Received: from e178046136.adsl.alicedsl.de ([85.178.46.136]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1F8e0P-0001t4-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Feb 2006 07:44:42 -0600 Message-ID: From: "Steven A. Norman" To: ipfix-list@mil.doit.wisc.edu Subject: =?iso-8859-1?B?U3dpc3Mgd2F0Y2hlcyAtIHJlcGxpY2E=?= Date: Mon, 13 Feb 2006 13:38:19 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_CB8E39EE.951802CB" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0000_CB8E39EE.951802CB Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_C8768C08.B60ED337" ------=_NextPart_001_0001_C8768C08.B60ED337 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit TRUE COPIES OF SWISS WATCHES - exact copies of V.I.P. watches - perfect as a gift for your colleagues and friends - free gift box Rolex, Patek Philippe, Omega Cartier, Bvlgari, Franck Muller .. and 15 other most famous manufacturers. http://121.yeswatches.net All watches are for only $239.95 - $279.95! ________________________________ To change your mail preferences, go here ------=_NextPart_001_0001_C8768C08.B60ED337 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
TRUE COPIES OF SWISS WATCHES

- exact copies of V.I.P. watches
- perfect as a gift for your colleagues and friends
- free gift box

Rolex, Patek Philippe, Omega
Cartier, Bvlgari, Franck Muller

.. and 15 other most famous manufacturers.

http://121.yeswatches.net

All watches are for only $239.95 - $279.95!


________________________________
To change your mail preferences, go here

------=_NextPart_001_0001_C8768C08.B60ED337-- ------=_NextPart_000_0000_CB8E39EE.951802CB-- From gratiament@ceng.usc.edu Mon Feb 13 12:09:38 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8hCk-0004Sw-E7 for ipfix-archive@megatron.ietf.org; Mon, 13 Feb 2006 12:09:38 -0500 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 MAA08079 for ; Mon, 13 Feb 2006 12:07:52 -0500 (EST) Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F8h3o-0006Qt-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Feb 2006 11:00:24 -0600 Received: from ceng.usc.edu (201-1-33-46.dsl.telesp.net.br [201.1.33.46]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k1DH0MLD008594 for ; Mon, 13 Feb 2006 11:00:23 -0600 Message-ID: <000001c630be$f4bd1630$1bdea8c0@solidify> Reply-To: "Gratien Ament" From: "Gratien Ament" To: ipfix-list@mil.doit.wisc.edu Subject: Re: good news Date: Mon, 13 Feb 2006 12:00:13 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C63095.0BE97F30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C63095.0BE97F30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, http://www.portuniy.com =20 =20 V j A o L c l e U u M k w $ q 1 a , g 2 f 1 k=20 V t I f A p G i R f A m e $ k 3 i , k 7 c 5 a=20 C k I e A o L o I p S f g $ b 3 v , d 3 r 3 l=20 ------=_NextPart_000_0001_01C63095.0BE97F30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
V j A o L c l e U u M k   w $ q 1 a , g 2 f 1 k
V t I f A p G i R f A m   e $ k 3 i , k 7 c 5 a
C k I e A o L o I p S f   g $ b 3 v , d 3 r 3 l
------=_NextPart_000_0001_01C63095.0BE97F30-- From majordomo@mil.doit.wisc.edu Tue Feb 14 11:13:31 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F92nx-0007D3-OY for ipfix-archive@megatron.ietf.org; Tue, 14 Feb 2006 11:13:31 -0500 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 LAA07560 for ; Tue, 14 Feb 2006 11:11:43 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F92Sk-0000xw-00 for ipfix-list@mil.doit.wisc.edu; Tue, 14 Feb 2006 09:51:34 -0600 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F92Sj-0000xA-00 for ipfix@net.doit.wisc.edu; Tue, 14 Feb 2006 09:51:33 -0600 Received: from dhcp-18-188-3-114.dyn.mit.edu (dhcp-18-188-3-114.dyn.mit.edu [18.188.3.114]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 756291BAC4D; Tue, 14 Feb 2006 16:53:04 +0100 (CET) Date: Tue, 14 Feb 2006 16:51:26 +0100 From: Juergen Quittek To: Benoit Claise Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX followup charter Message-ID: In-Reply-To: <43F049BA.2000503@cisco.com> References: <399327FA4D1893115F68503B@[192.168.1.128]> <43F049BA.2000503@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 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit, I agree that IPFIX reliability is an important issue for IPFIX And I agree as well with others that bi-flow reporting is important. However, we do not have discussed these issues yet on the mailing list or in IPFIX (or PSAMP) sessions. Therefore I would suggest handling these issues similarly to the way it is done in the RADEXT, DHC, and other WGs. There, new issues are handled as individual drafts and included in the charter when they are mature enough and often already ready for WG last call. I think we can proceed in this way with the two mentioned issues. We can discuss them on the list at each meeting (monitoirng also the progress that is made). Then we can include them in the charter as soon as we sense sufficient stability and/or a broad support by the WG for working on the issues. Please find further comments inline. --On 2/13/06 9:56 AM +0100 Benoit Claise wrote: > Juergen and all, > > Thanks for proposing a new charter. I agree that there are a lot of activities and interest around IPFIX, and that a new charter is suitable. > > 1. The implementation guidelines draft is a must in this new charter. Note that I gave a long list of issues regarding this draft, and that I don't think its status is close to completion yet. > Regarding the per packet draft, I think the right choice to do is to make this concept generic, as discussed already. As a consequence, I would see its content as a new section in the implementation guideline draft, called something such as > "implementation choice for the reduction of export". Anyway, I really consider the concepts behind the per-packet info as implementation guideline! > If we combine those two drafts, we can kill one bird with half a stone :) (private joke) I see your point. However, the redundancy reduction might prove to have sufficient substance for covering it in a separate document. Also, the reduction of redundancy is on a higher level than most of the guidelines to be covered by the other document. So there are good reasons for both alternatives. Are there further opinions? Thanks, Juergen > 2. The flow aggregation is interesting. I must admit that I haven't spent a great of deal of time reviewing it though. > > 3. If we take the initial idea to have 3 work items in the WG charter, I'm wondering which one to take next. I tend to think that only looking at the current maturity of the drafts might not be appropriate, as opposed to ask ourselves the question: do > we solve the right issue in this new charter? > Next to the IPFIX transport issue, the second highest amount of emails generated on the list concerned "IPFIX for billing" > I sketched a few initial ideas in draft-bclaise-ipfix-reliability-00.txt. I agree so that we're missing some meat at this point, but a second draft version will be posted before Dallas. So my vote would go for this work: not because I'm the author, but > because this is an important item to solve. > > Note: I'm personally not convinced by the bi-flow draft. I browsed through the bi-flow draft, and had some non-trivial concerns. > > Regards, Benoit. > > Dear all, > > As you know, the IPFIX working group has completed its charter > by submitting all planned documents (with a delay of several years) > to the IESG for publication as RFC. Also the PSAMP WG will reach > this status soon. > > Building on the results of these WGs, there are a lot of related > ongoing activities that are producing Internet drafts related to > IPFIX. Several of them have already been presented at recent IPFIX > and PSAMP sessions. But working on them is not covered by the IPFIX > or PSAMP charter. If we want to continue this IPFIX-related work, > we need a new charter that gives it a home at the IETF. > > The text below lists and discusses related work and suggests a > charter for a follow-up WG. It is the output of several discussions > with Tanja, Benoit, and Nevil. > > The proposed charter is very short-lived and includes only the three > most mature work items out of a longer list of candidates. The basic > idea is completing this charter within less than a year and then > re-chartering to cover further work items that have progressed until > then. This lean work model with short-lived charters allows the group > to focus on a limited number of issues and is preferable to long-lived > WGs working on many issues in parallel. (It is highly recommended > by the IESG.) > > Please have a look at it and state whether or not you think it makes > sense to have an IPFIX follow-up WG. Also please read the proposed > charter carefully and express your objections, concerns, comments, > requests for modifications, etc. > > The plan is to elaborate the new charter proposal on this list and > submit an agreed version to our area directors soon. The deadline > for requesting BoF sessions at the next IETF meeting in Dallas is > February 13. > > Thanks, > > Juergen > > > ======================================================= > Why do we need to continue the work of IPFIX and PSAMP? > ======================================================= > > IPFIX has completed its charter and PSAMP will do so very soon. Still, there > are a lot of ongoing activities in the community of these two WGs: > > 1. Flow aggregation > draft-dressler-ipfix-aggregation-01.txt > > 2. reducing redundancy in IPFIX and PSAMP reports > draft-boschi-export-perpktinfo-00.txt > > 3. IPFIX implementation guidelines > draft-boschi-ipfix-implementation-guidelines-00.txt > > 4. Path-coupled meter configuration > draft-fessi-nsis-m-nslp-framework-02.txt > draft-dressler-nsis-metering-nslp-03.txt > (currently under discussion in the NSIS WG, but not covered > by the NSIS charter. It is a candidate work item for NSIS > re-chartering, but the NSIS WG asks if it would not be better > covered by IPFIX) > > 5. IPFIX reliability > draft-bclaise-ipfix-reliability-00.txt > > 6. Reporting bi-directional flows with IPFIX > draft-boschi-ipfix-biflow-01.txt > > 7. a format for storing IPFIX records > draft-trammell-ipfix-file-00.txt > > 8. IPFIX MIB module > no I-D yet, but two teams working on it independently. > > 9. Common IPFIX templates > draft-stephan-isp-templates-01.txt > > 10. Reliable server pooling for IPFIX > draft-coene-rserpool-applic-ipfix-01.txt > > 11. Flow sampling > draft-molina-flow-selection-00.txt (expired) > > Did I miss something? > > > 1.-4. and 9. have already been discussed at past IPFIX or PSAMP sessions. > > This list shows two things. > - There is a community interested in IPFIX that is not too small. > - This community and is willing to further work on issues IPFIX-related > issues in the IETF. > This is a very good starting point for a charter discussion. > > > ============================ > Which work items are suited? > ============================ > > Not all of the issues listed above are at a stage, where they should be > considered as a WG work item, but 1.-4. are quite well developed and 5. > and 6. are candidates. Since 4. is a candidate for NSIS re-chartering, > I dropped it from the following considerations. > > Each of 1.-3. has been presented at IPFIX or PSAMP sessions already two times > with some discussion on the suggested approach. For all I sense an agreement > in the IPFIX WG (at least no objections so far) that these issues are relevant > work and potential WG work items (to be confirmed on the list, of course). > > - The flow aggregation work is rather mature. Actually this draft covers > something that is missing in IPFIX: How to tell the collector that the > metering probe does not have the standard (Netflow default) configuration, > but filters and aggregates certain flows. > There are some terminology problems and a set of technical issues to be > solved, but there is not problem with the general direction and the chosen > approach. Still, thorough reviews are missing as well as a discussion on > how to fit it well into the IPFIX architecture. > > - Reducing redundancy in IPFIX and PSAMP reports is an issue that was > received very well by both WGs when past versions of the IDs were presented. > It is considered a useful method of applying IPFIX efficiently. > Still, the current drafts were considered as to specific. They apply > the optimization to packet reports only. At the last PSAMP meeting it was > noted that the method should be generalized such that it can be applied to > all redundant IPFIX transmissions. This generalization needs to be done, > but the way to go is clear and basically agreed on. > > - The implementation guidelines are considered the most important work item > by many WG members (including myself). Many people are currently implementing > IPFIX and several recommendations were identified at the first IPFIX interop > (next one is scheduled for end of February). The sooner this document is > available, the more will help improving ongoing implementations. > My problem with this item is that the current individual draft is in a bad > shape. Therefore, the milestones for this item are later than for the > others. > > The two weaker candidates for WG items are IPFIX reliability and reporting of > bidirectional flows. Both have been requested on the IPFIX mailing list several > time in the past years, but we could not agree on making them part of the basic > IPFIX standard. > But as add-ons, that integrate well with the standard, they can be considered, > particularly since I heard about operator requests for both of them. > A problem of these issues is that so far they have not been presented at IPFIX > or PSAMP sessions and there has not been a discussion yet on the approaches > followed by the existing drafts. Therefore, these two are not included in the > draft proposal below. > > > ================================= > Charter Proposal: > Efficient Use of IPFIX (USEIPFIX) > ================================= > > The IPFIX working group has specified the IPFIX protocol for exporting > flow records. The PSAMP working group has specified the usage of the > IPFIX protocol for exporting packet records. With both specifications > available, several implementers have started building applications > using the IPFIX protocol. > > At a first interoperability testing event, several IPFIX protocol > implementations were tested. The experiences made at this event were > fed back to IPFIX protocol specification, particularly for removing > ambiguities. In addition, several lessons were learned about how to > implement and use IPFIX correctly and efficiently. The exchange among > different implementers further led to new ideas for advanced usage of > IPFIX. Many of these ideas are currently documented in individual > Internet drafts. > > The goal of the USEIPFIX working group is producing best current > practice and guideline documents concerning implementation, application > and usage of the IPFIX protocol. > > Out of scope are modifications of the core IPFIX and PSAMP protocol > specifications. In scope is the definition of new IPFIX and PSAMP > information elements within the documents produced by the USEIPFIX WG. > > Specific Goals of the USEIPFIX WG are: > > o Developing guidelines for implementers based on experiences > gained individually by implementers and jointly at interoperability > testing events. The guidelines will give recommendations for > integrating IPFIX observation points, measurement processes, and > exporting processes into the packet flow at different kinds of IPFIX > devices. They will make suggestions for efficient implementation of > the IPFIX protocol features and identify parts of the IPFIX > specification that have already been misunderstood by several > implementers. For some implementation choices that the protocol > specification leaves to the implementer, the guidelines will discuss > advantages and disadvantages of the different choices. > > o Developing methods and means for an efficient use of the IPFIX > protocol that reduces redundancy in flow reports. The basic idea > to be followed is very simple. For multiple flow records that all > report the same value in one or more of the contained IPFIX > information elements, these values are removed from the flow records > and instead reported once for all in a separate record. Such an > approach integrates very well with the IPFIX protocol and only needs > few means for expressing the relationship between flow records and > corresponding separate records. > > o Develop a method for flow aggregation reducing the amount of > measurement data exchanged between IPFIX exporters and IPFIX > collectors. Using aggregation techniques, measurement information of > multiple similar flows is aggregated into few meta-flow records. > Applied aggregation rules need to be communicate. > > o Investigate further ways of efficiently using the IPFIX protocols > including but not limited to > - providing reliability for IPFIX transmissions, > - reporting bi-directional flows, > - path-coupled configuration of IPFIX devices, > - reporting the configuration of IPFIX devices, > - flow sampling at IPFIX devices, > - storing IPFIX flow records and packet records. > These issues are not current work items of the USEIPFIX WG but are > evaluated as candidates for potential future work items. > > > Milestones: > > Mar 2006 Initial version of flow aggregation methods > Mar 2006 Initial version of reducing redundandy in IPFIX records > Mar 2006 IPFIX and PSAMP interoperability testing event (not a real WG milestone?) > Apr 2006 Initial version of implementation guidelines > Jul 2006 Submit flow aggregation methods to IESG > Sep 2006 Submit reducing redundancy in IPFIX records to IESG > Sep 2006 Submit implementation guidelines to IESG > > > -- > 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 Feb 14 12:00:56 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F93Xq-000704-HC for ipfix-archive@megatron.ietf.org; Tue, 14 Feb 2006 12:00:56 -0500 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 LAA11544 for ; Tue, 14 Feb 2006 11:59:08 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F93Rc-0005y6-00 for ipfix-list@mil.doit.wisc.edu; Tue, 14 Feb 2006 10:54:28 -0600 Received: from smtp.ee.ethz.ch ([129.132.2.219]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F93Rb-0005xw-00 for ipfix@net.doit.wisc.edu; Tue, 14 Feb 2006 10:54:27 -0600 Received: from localhost (tranquillity.ee.ethz.ch [129.132.2.222]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 34F93D9336; Tue, 14 Feb 2006 17:54:25 +0100 (MET) Received: from smtp.ee.ethz.ch ([129.132.2.217]) by localhost (tranquillity [129.132.2.222]) (amavisd-new, port 10024) with LMTP id 11841-02-4; Tue, 14 Feb 2006 17:54:24 +0100 (MET) Received: from [82.130.102.210] (nb-4995.ethz.ch [82.130.102.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ee.ethz.ch (Postfix) with ESMTP id E5142D934F; Tue, 14 Feb 2006 17:54:24 +0100 (MET) Message-ID: <43F20C48.1030601@fokus.fraunhofer.de> Date: Tue, 14 Feb 2006 17:58:48 +0100 From: Elisa Boschi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek Cc: Benoit Claise , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX followup charter References: <399327FA4D1893115F68503B@[192.168.1.128]> <43F049BA.2000503@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: by amavisd-new at ee.ethz.ch Content-Transfer-Encoding: quoted-printable Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Juergen, Benoit, >> >> 1. The implementation guidelines draft is a must in this new charter. >> Note that I gave a long list of issues regarding this draft, and that >> I don't think its status is close to completion yet. >> Regarding the per packet draft, I think the right choice to do is to >> make this concept generic, as discussed already. As a consequence, I >> would see its content as a new section in the implementation >> guideline draft, called something such as >> "implementation choice for the reduction of export". Anyway, I really >> consider the concepts behind the per-packet info as implementation >> guideline! >> If we combine those two drafts, we can kill one bird with half a >> stone :) (private joke) > > > I see your point. However, the redundancy reduction might prove to > have sufficient > substance for covering it in a separate document. Also, the reduction > of redundancy > is on a higher level than most of the guidelines to be covered by the > other document. > So there are good reasons for both alternatives. > > Are there further opinions? I don't think that the redundancy reduction draft should be included in the guidelines. I agree with J=FCrgen that the redundancy reduction draft is on a higher level then the implementation guidelines and I think that this is a good reason to keep them separate . Its content is also more "mature" than the guidelines: while we still need to make the concept described in the per packet draft generic, which we are doing right now, the way to go is basically agreed on. Another thought is that merging two drafts into one is not always the faster way to complete them. I'd rather prefer keeping the two issues into two separate drafts. cheers, Elisa > Thanks, > > Juergen > >> 2. The flow aggregation is interesting. I must admit that I haven't >> spent a great of deal of time reviewing it though. >> >> 3. If we take the initial idea to have 3 work items in the WG >> charter, I'm wondering which one to take next. I tend to think that >> only looking at the current maturity of the drafts might not be >> appropriate, as opposed to ask ourselves the question: do >> we solve the right issue in this new charter? >> Next to the IPFIX transport issue, the second highest amount of >> emails generated on the list concerned "IPFIX for billing" >> I sketched a few initial ideas in >> draft-bclaise-ipfix-reliability-00.txt. I agree so that we're missing >> some meat at this point, but a second draft version will be posted >> before Dallas. So my vote would go for this work: not because I'm the >> author, but >> because this is an important item to solve. >> >> Note: I'm personally not convinced by the bi-flow draft. I browsed >> through the bi-flow draft, and had some non-trivial concerns. >> >> Regards, Benoit. >> >> Dear all, >> >> As you know, the IPFIX working group has completed its charter >> by submitting all planned documents (with a delay of several years) >> to the IESG for publication as RFC. Also the PSAMP WG will reach >> this status soon. >> >> Building on the results of these WGs, there are a lot of related >> ongoing activities that are producing Internet drafts related to >> IPFIX. Several of them have already been presented at recent IPFIX >> and PSAMP sessions. But working on them is not covered by the IPFIX >> or PSAMP charter. If we want to continue this IPFIX-related work, >> we need a new charter that gives it a home at the IETF. >> >> The text below lists and discusses related work and suggests a >> charter for a follow-up WG. It is the output of several discussions >> with Tanja, Benoit, and Nevil. >> >> The proposed charter is very short-lived and includes only the three >> most mature work items out of a longer list of candidates. The basic >> idea is completing this charter within less than a year and then >> re-chartering to cover further work items that have progressed until >> then. This lean work model with short-lived charters allows the group >> to focus on a limited number of issues and is preferable to long-lived >> WGs working on many issues in parallel. (It is highly recommended >> by the IESG.) >> >> Please have a look at it and state whether or not you think it makes >> sense to have an IPFIX follow-up WG. Also please read the proposed >> charter carefully and express your objections, concerns, comments, >> requests for modifications, etc. >> >> The plan is to elaborate the new charter proposal on this list and >> submit an agreed version to our area directors soon. The deadline >> for requesting BoF sessions at the next IETF meeting in Dallas is >> February 13. >> >> Thanks, >> >> Juergen >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> Why do we need to continue the work of IPFIX and PSAMP? >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> >> IPFIX has completed its charter and PSAMP will do so very soon.=20 >> Still, there >> are a lot of ongoing activities in the community of these two WGs: >> >> 1. Flow aggregation >> draft-dressler-ipfix-aggregation-01.txt >> >> 2. reducing redundancy in IPFIX and PSAMP reports >> draft-boschi-export-perpktinfo-00.txt >> >> 3. IPFIX implementation guidelines >> draft-boschi-ipfix-implementation-guidelines-00.txt >> >> 4. Path-coupled meter configuration >> draft-fessi-nsis-m-nslp-framework-02.txt >> draft-dressler-nsis-metering-nslp-03.txt >> (currently under discussion in the NSIS WG, but not covered >> by the NSIS charter. It is a candidate work item for NSIS >> re-chartering, but the NSIS WG asks if it would not be better >> covered by IPFIX) >> >> 5. IPFIX reliability >> draft-bclaise-ipfix-reliability-00.txt >> >> 6. Reporting bi-directional flows with IPFIX >> draft-boschi-ipfix-biflow-01.txt >> >> 7. a format for storing IPFIX records >> draft-trammell-ipfix-file-00.txt >> >> 8. IPFIX MIB module >> no I-D yet, but two teams working on it independently. >> >> 9. Common IPFIX templates >> draft-stephan-isp-templates-01.txt >> >> 10. Reliable server pooling for IPFIX >> draft-coene-rserpool-applic-ipfix-01.txt >> >> 11. Flow sampling >> draft-molina-flow-selection-00.txt (expired) >> >> Did I miss something? >> >> >> 1.-4. and 9. have already been discussed at past IPFIX or PSAMP >> sessions. >> >> This list shows two things. >> - There is a community interested in IPFIX that is not too small. >> - This community and is willing to further work on issues IPFIX-relat= ed >> issues in the IETF. >> This is a very good starting point for a charter discussion. >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> Which work items are suited? >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> >> Not all of the issues listed above are at a stage, where they should b= e >> considered as a WG work item, but 1.-4. are quite well developed and 5= . >> and 6. are candidates. Since 4. is a candidate for NSIS re-chartering= , >> I dropped it from the following considerations. >> >> Each of 1.-3. has been presented at IPFIX or PSAMP sessions already >> two times >> with some discussion on the suggested approach. For all I sense an >> agreement >> in the IPFIX WG (at least no objections so far) that these issues are >> relevant >> work and potential WG work items (to be confirmed on the list, of >> course). >> >> - The flow aggregation work is rather mature. Actually this draft >> covers >> something that is missing in IPFIX: How to tell the collector that >> the >> metering probe does not have the standard (Netflow default) >> configuration, >> but filters and aggregates certain flows. >> There are some terminology problems and a set of technical issues >> to be >> solved, but there is not problem with the general direction and >> the chosen >> approach. Still, thorough reviews are missing as well as a >> discussion on >> how to fit it well into the IPFIX architecture. >> >> - Reducing redundancy in IPFIX and PSAMP reports is an issue that was >> received very well by both WGs when past versions of the IDs were >> presented. >> It is considered a useful method of applying IPFIX efficiently. >> Still, the current drafts were considered as to specific. They app= ly >> the optimization to packet reports only. At the last PSAMP meeting >> it was >> noted that the method should be generalized such that it can be >> applied to >> all redundant IPFIX transmissions. This generalization needs to >> be done, >> but the way to go is clear and basically agreed on. >> >> - The implementation guidelines are considered the most important >> work item >> by many WG members (including myself). Many people are currently >> implementing >> IPFIX and several recommendations were identified at the first >> IPFIX interop >> (next one is scheduled for end of February). The sooner this >> document is >> available, the more will help improving ongoing implementations. >> My problem with this item is that the current individual draft is >> in a bad >> shape. Therefore, the milestones for this item are later than for >> the >> others. >> >> The two weaker candidates for WG items are IPFIX reliability and >> reporting of >> bidirectional flows. Both have been requested on the IPFIX mailing >> list several >> time in the past years, but we could not agree on making them part of >> the basic >> IPFIX standard. >> But as add-ons, that integrate well with the standard, they can be >> considered, >> particularly since I heard about operator requests for both of them. >> A problem of these issues is that so far they have not been presented >> at IPFIX >> or PSAMP sessions and there has not been a discussion yet on the >> approaches >> followed by the existing drafts. Therefore, these two are not >> included in the >> draft proposal below. >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> Charter Proposal: >> Efficient Use of IPFIX (USEIPFIX) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> The IPFIX working group has specified the IPFIX protocol for exporting >> flow records. The PSAMP working group has specified the usage of the >> IPFIX protocol for exporting packet records. With both specifications >> available, several implementers have started building applications >> using the IPFIX protocol. >> >> At a first interoperability testing event, several IPFIX protocol >> implementations were tested. The experiences made at this event were >> fed back to IPFIX protocol specification, particularly for removing >> ambiguities. In addition, several lessons were learned about how to >> implement and use IPFIX correctly and efficiently. The exchange among >> different implementers further led to new ideas for advanced usage of >> IPFIX. Many of these ideas are currently documented in individual >> Internet drafts. >> >> The goal of the USEIPFIX working group is producing best current >> practice and guideline documents concerning implementation, applicatio= n >> and usage of the IPFIX protocol. >> >> Out of scope are modifications of the core IPFIX and PSAMP protocol >> specifications. In scope is the definition of new IPFIX and PSAMP >> information elements within the documents produced by the USEIPFIX WG. >> >> Specific Goals of the USEIPFIX WG are: >> >> o Developing guidelines for implementers based on experiences >> gained individually by implementers and jointly at interoperability >> testing events. The guidelines will give recommendations for >> integrating IPFIX observation points, measurement processes, and >> exporting processes into the packet flow at different kinds of IPFIX >> devices. They will make suggestions for efficient implementation of >> the IPFIX protocol features and identify parts of the IPFIX >> specification that have already been misunderstood by several >> implementers. For some implementation choices that the protocol >> specification leaves to the implementer, the guidelines will discuss >> advantages and disadvantages of the different choices. >> >> o Developing methods and means for an efficient use of the IPFIX >> protocol that reduces redundancy in flow reports. The basic idea >> to be followed is very simple. For multiple flow records that all >> report the same value in one or more of the contained IPFIX >> information elements, these values are removed from the flow records >> and instead reported once for all in a separate record. Such an >> approach integrates very well with the IPFIX protocol and only needs >> few means for expressing the relationship between flow records and >> corresponding separate records. >> >> o Develop a method for flow aggregation reducing the amount of >> measurement data exchanged between IPFIX exporters and IPFIX >> collectors. Using aggregation techniques, measurement information of >> multiple similar flows is aggregated into few meta-flow records. >> Applied aggregation rules need to be communicate. >> >> o Investigate further ways of efficiently using the IPFIX protocols >> including but not limited to >> - providing reliability for IPFIX transmissions, >> - reporting bi-directional flows, >> - path-coupled configuration of IPFIX devices, >> - reporting the configuration of IPFIX devices, >> - flow sampling at IPFIX devices, >> - storing IPFIX flow records and packet records. >> These issues are not current work items of the USEIPFIX WG but are >> evaluated as candidates for potential future work items. >> >> >> Milestones: >> >> Mar 2006 Initial version of flow aggregation methods >> Mar 2006 Initial version of reducing redundandy in IPFIX records >> Mar 2006 IPFIX and PSAMP interoperability testing event (not a real >> WG milestone?) >> Apr 2006 Initial version of implementation guidelines >> Jul 2006 Submit flow aggregation methods to IESG >> Sep 2006 Submit reducing redundancy in IPFIX records to IESG >> Sep 2006 Submit implementation guidelines to IESG >> >> >> --=20 >> 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/ >> >> > > > > --=20 > 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 loreto@vincentleger.com Tue Feb 14 12:22:48 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F93t2-00075Z-7R for ipfix-archive@megatron.ietf.org; Tue, 14 Feb 2006 12:22:48 -0500 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 MAA13258 for ; Tue, 14 Feb 2006 12:21:01 -0500 (EST) Received: from s0106001346b79925.ok.shawcable.net ([24.70.226.207] helo=vincentleger.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1F93nw-00003L-00 for ipfix-list@mil.doit.wisc.edu; Tue, 14 Feb 2006 11:17:32 -0600 Message-ID: <000001c6318a$74e943d0$732ea8c0@veridical> Reply-To: "Scarlet Loreto" From: "Scarlet Loreto" To: ipfix-list@mil.doit.wisc.edu Subject: Re: news Date: Tue, 14 Feb 2006 12:16:56 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C63160.8C133BD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?24.70.226.207 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C63160.8C133BD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello =20 VsI l AyGaRsAx x$g3r, k 7h5f CdIpAbLeI p S s d$x3m, a 3 j 3h VnA e LqlxUmMe g$z1l,u2 u 1h =20 and many other http://www.bubeglas.com =20 ------=_NextPart_000_0001_01C63160.8C133BD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello
 
VsI l = AyGaRsAx x$g3r, k 7h5f
CdIpAbLeI p = S s =  d$x3m, a = 3 j 3h
VnA e = LqlxUmMe g$z1l,u2 u 1h
 
------=_NextPart_000_0001_01C63160.8C133BD0-- From gearizolda@tourexpo.com Thu Feb 16 00:25:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9bdi-00049m-3i for ipfix-archive@megatron.ietf.org; Thu, 16 Feb 2006 00:25:14 -0500 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 AAA16158 for ; Thu, 16 Feb 2006 00:23:27 -0500 (EST) Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F9bIb-0005Sd-00 for ipfix-list@mil.doit.wisc.edu; Wed, 15 Feb 2006 23:03:25 -0600 Received: from tourexpo.com (c-66-176-88-229.hsd1.fl.comcast.net [66.176.88.229]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k1G53LaQ002514 for ; Wed, 15 Feb 2006 23:03:21 -0600 Message-ID: <000001c632b6$3c7476a0$31efa8c0@aftergame> Reply-To: "Izolda Gearhart" From: "Izolda Gearhart" To: ipfix-list@mil.doit.wisc.edu Subject: Re: news Date: Thu, 16 Feb 2006 00:02:50 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6328C.539E6EA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6328C.539E6EA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 VeAtLxl v U d Mm h$ m 1l,b2q1p V j IlAhGhRkAg h$x3c,e7o5 f=20 CoI t AdLaIrSn k$u3p,l3 n 3 r=20 =20 http://www.tadeserte.com =20 ------=_NextPart_000_0001_01C6328C.539E6EA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
VeAtLxl v U d Mm h$ m 1l,b2q1p
V j IlAhGhRkAg h$x3c,e7o5 f
CoI t AdLaIrSn k$u3p,l3 n 3 r
 
------=_NextPart_000_0001_01C6328C.539E6EA0-- From mit_sone@sina.com.cn Thu Feb 16 00:35:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9bnG-00067r-59 for ipfix-archive@megatron.ietf.org; Thu, 16 Feb 2006 00:35:06 -0500 Received: from allabout.co.jp ([221.212.58.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11798 for ; Wed, 15 Feb 2006 22:48:48 -0500 (EST) Date: Wed, 15 Feb 2006 22:48:48 -0500 (EST) Message-Id: <200602160348.WAA11798@ietf.org> Received: from hwxai9 (unknown [109.227.166.254]) by smtp72 (Coremail) with SMTP id UeBdaXqwgokcIrhz.1 for ; Sat, 08 Feb 2003 21:56:18 +0800 (CST) X-Originating-IP: [109.227.166.254] From: =?gb2312?B?eXV1a2E=?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C2C97B.D2C5BD50" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C2C97B.D2C5BD50 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCIXklNSUkJUg0MEE0JWolSyVlITwlIiVrIXkbKEINChskQjdIQlNJVE1XISolVSVqITwlYSE8 JWskR0VQTz8kRyQtJGskKyRpPGo3WiRLTTckWSRrJGgidiEhGyhCKG1zbhskQiRkGyhCeWFob28b JEIkSiRJJE4lVSVqITwlYSE8JWskR0VQTz8jTyNLISohKhsoQikNCg0KGyRCISEhISEhIXk0MEE0 TDVOQSU1JSQlSD9NNSQlSiVzJVAhPC0hISohKiF5GyhCDQobJEIhISEhNSFHPSRPS346XCEqISo7 SCQkJGQkOSQkJDchIiUvJWolIiVpJXMlOSRKJUYlJCU5JUYlIyVzJTAidhsoQg0KGyRCISEhISEh ISE7SCQkSnxCaiEqJGQkakp8QmohKiRkJGokXiQvJGwhKhsoQg0KDQobJEI6IyRKJGkkSiRzJEhM NU5BJV0lJCVzJUgbKEIxGyRCS3wxXyRWJHMhKiVTJUMlLyVqKCwoLBsoQigbJEIhLBsoQigbJEIh LCdVGyhCKBskQiEsJ1UhLBsoQikbJEInVSEsGyhCKRskQiEsGyhCKRskQigsKCwbKEIhISEhGyRC O1ckJkI4SixNNyRzJEckLyRAJDUkJCEqGyhCDQpodHRwOi8vd3d3LmF3ZzUubmV0Lz8yMDA3DQoN Cg0KGyRCNFYkSzlnJEMkRiRrJEgkJCQmP00kTxsoQnByaW9yaXR5N19uZXRAeWFob28uY2EbJEIh ISReJEcbKEI= ------=_NextPart_000_0006_01C2C97B.D2C5BD50 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgDQpmYWNlPSJNUyBVSSBHb3Ro aWMiPhskQiF5JTUlJCVINDBBNCVqJUslZSE8JSIlayF5GyhCPEJSPhskQjdIQlNJVE1XISolVSVq ITwlYSE8JWskR0VQTz8kRyQtJGskKyRpPGo3WiRLTTckWSRrJGgidiEhGyhCKG1zbhskQiRkGyhC eWFob28bJEIkSiRJJE4lVSVqITwlYSE8JWskR0VQTz8jTyNLISohKhsoQik8QlI+PEJSPhskQiEh ISEhISF5NDBBNEw1TkElNSUkJUg/TTUkJUolcyVQITwtISEqISoheRsoQjxCUj4bJEIhISEhNSFH PSRPS346XCEqISo7SCQkJGQkOSQkJDchIiUvJWolIiVpJXMlOSRKJUYlJCU5JUYlIyVzJTAidhso QjxCUj4bJEIhISEhISEhITtIJCRKfEJqISokZCRqSnxCaiEqJGQkaiReJC8kbCEqGyhCPEJSPjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgDQpmYWNlPSJNUyBVSSBHb3RoaWMiPhskQjojJEokaSRK JHMkSEw1TkElXSUkJXMlSBsoQjEbJEJLfDFfJFYkcyEqJVMlQyUvJWooLCgsGyhCKBskQiEsGyhC KBskQiEsJ1UbKEIoGyRCISwnVSEsGyhCKRskQidVISwbKEIpGyRCISwbKEIpGyRCKCwoLBsoQiEh ISEbJEI7VyQmQjhKLE03JHMkRyQvJEAkNSQkISobKEI8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjxGT05UIHNpemU9Mz48QSANCmhyZWY9Imh0dHA6 Ly93d3cuYXdnNS5uZXQvPzIwMDciPmh0dHA6Ly93d3cuYXdnNS5uZXQvPC9GT05UPjxGT05UIA0K ZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PzIwMDc8L0E+PC9GT05UPjwvRk9OVD48L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0y PjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgDQpzaXplPTI+PC9GT05UPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+GyRCNFYkSzlnJEMk RiRrJEgkJCQmP00kTxsoQjxBIA0KaHJlZj0ibWFpbHRvOnByaW9yaXR5N19uZXRAeWFob28uY2Ei PnByaW9yaXR5N19uZXRAeWFob28uY2E8L0E+GyRCISEkXiRHGyhCPC9GT05UPjwvRElWPjwvQk9E WT48L0hUTUw+DQo= ------=_NextPart_000_0006_01C2C97B.D2C5BD50-- From mit_sone@sina.com.cn Thu Feb 16 04:46:37 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9fif-0007jB-1q for ipfix-archive@megatron.ietf.org; Thu, 16 Feb 2006 04:46:37 -0500 Received: from ocn.ne.jp ([221.207.130.146]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04635 for ; Thu, 16 Feb 2006 04:44:46 -0500 (EST) Date: Thu, 16 Feb 2006 04:44:46 -0500 (EST) Message-Id: <200602160944.EAA04635@ietf.org> Received: from urwapyjk2 (unknown [211.97.112.243]) by smtp75 (Coremail) with SMTP id G54RLav68enL6QsR.1 for ; Thu, 16 Feb 2006 18:44:39 +0800 (CST) X-Originating-IP: [211.97.112.243] Subject: =?iso-2022-jp?B?GyRCN24bKEI1MBskQiFBJE41VSU1JV0bKEI=?= From: =?gb2312?B?bWVpX29taQ==?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C6325B.3372C490" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C6325B.3372C490 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCISE5YjVpSVg/TSRIJE5MNU5BJE49UDJxJCQkckRzNiEkNyRGJF4kOSEjGyhCDQobJEI9d0At JE9FUE8/TkEbKEI1GyRCS3wxXyEiQ0tALSRPTDVOQSRIJEokQyRGJF4kOSROJEchIj8/N3UkSj13 QC0kNxsoQg0KGyRCJCskKiRqJF4kOyRzISMbKEINChskQiQ5JFkkRiROJTslbCVWJCw0aTJoQXwk ckU6JCgkRiVhJWslIiVJJGI6XCQ7JEYkKkJUJEEkRyQ5ISMkKhsoQg0KGyRCNmIkTyQiJGskLDAm JEs3QyReJGwkSiQkPXdALUMjJHI/SEJOJEdMfiQ3JEYkIiQyJEYkLyRAJDUkJCEjGyhCDQobJEI3 bhsoQjEbJEIhQRsoQjMbJEIycyROJUchPCVIJEc3bhsoQjUwGyRCJE41VSU1JV0kLDpHRGM4QiRO JWklJCVzJEokTiRHISI9d0AtJEsbKEINChskQiRoJEMkRiRPJD0kbDBKPmUkTjVVJTUlXSQsNHxC VCRHJC0kXiQ5JGghIxsoQg0KGyRCISEhISEhGyhCaHR0cDovL3d3dy5neWFrdXRlbjYubmV0L3Nl cmVidS8/MTkyMA0KGyRCJDUkaSRLISI/Pzd1JEo4cjpdJHI0dUs+JDUkbCRrSn0kTiQ/JGEkSyEi TDVOQSRHNS5KfSROJCo9OyReGyhCDQobJEIkJCRONmEkLyROPXdALSU7JWwlViRyTDVOQSRHOCE6 dyQ5JGs/NyQ3JCQkND5SMnAlNSE8JVMlOSRyRHMbKEINChskQjYhJCQkPyQ3JF4kOSEjGyhCDQob JEIhISEhISEbKEJodHRwOi8vd3d3Lmd5YWt1dGVuNi5uZXQvc2VyZWJ1Lz8xOTIwDQoNChskQjoj JEokaTJxMHdIcSEmRy8ycUhxRXkwbEBaTDVOQSEqJDUkaSRLGyhCMTAsMDAwGyRCMV9KLCROTDVO QSVdJSQlcxsoQg0KGyRCJUgkciVXJWwlPCVzJUghKhsoQg0KDQoNCg0KDQoNChskQiVhITwla0lU TVckTkp9JE8kMyRBJGkkSyItGyhCDQpjb25jZXB0Ml9uZXRAeWFob28uY2ENCg== ------=_NextPart_000_0009_01C6325B.3372C490 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGlj Ij48Rk9OVCANCnNpemU9Mj4bJEIhITliNWlJWD9NJEgkTkw1TkEkTj1QMnEkJCRyRHM2ISQ3JEYk XiQ5ISMbKEI8QlI+GyRCPXdALSRPRVBPP05BGyhCNRskQkt8MV8hIkNLQC0kT0w1TkEkSCRKJEMk RiReJDkkTiRHISI/Pzd1JEo9d0AtJDcbKEI8QlI+GyRCJCskKiRqJF4kOyRzISMbKEI8QlI+GyRC JDkkWSRGJE4lOyVsJVYkLDRpMmhBfCRyRTokKCRGJWElayUiJUkkYjpcJDskRiQqQlQkQSRHJDkh IyQqGyhCPEJSPhskQjZiJE8kIiRrJCwwJiRLN0MkXiRsJEokJD13QC1DIyRyP0hCTiRHTH4kNyRG JCIkMiRGJC8kQCQ1JCQhIxsoQjxCUj4bJEI3bhsoQjEbJEIhQRsoQjMbJEIycyROJUchPCVIJEc3 bhsoQjUwGyRCJE41VSU1JV0kLDpHRGM4QiROJWklJCVzJEokTiRHISI9d0AtJEsbKEI8QlI+GyRC JGgkQyRGJE8kPSRsMEo+ZSRONVUlNSVdJCw0fEJUJEckLSReJDkkaCEjGyhCPC9GT05UPjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIj48Rk9OVCBzaXplPTI+GyRC ISEhISEhGyhCPEEgDQpocmVmPSJodHRwOi8vd3d3Lmd5YWt1dGVuNi5uZXQvc2VyZWJ1Lz8xOSI+ aHR0cDovL3d3dy5neWFrdXRlbjYubmV0L3NlcmVidS8/MTk8L0E+PC9GT05UPjxGT05UIA0Kc2l6 ZT0yPjxBIGhyZWY9Imh0dHA6Ly93d3cuZGVhaS1zdHlsZS5uZXQvY2FzYW5vdmEvPzE5MjAiPjIw PC9BPjwvRk9OVD48QlI+PEZPTlQgDQpzaXplPTI+GyRCJDUkaSRLISI/Pzd1JEo4cjpdJHI0dUs+ JDUkbCRrSn0kTiQ/JGEkSyEiTDVOQSRHNS5KfSROJCo9OyReGyhCPEJSPhskQiQkJE42YSQvJE49 d0AtJTslbCVWJHJMNU5BJEc4ITp3JDkkaz83JDckJCQ0PlIycCU1ITwlUyU5JHJEcxsoQjxCUj4b JEI2ISQkJD8kNyReJDkhIxsoQjxCUj4bJEIhISEhISEbKEI8QSANCmhyZWY9Imh0dHA6Ly93d3cu Z3lha3V0ZW42Lm5ldC9zZXJlYnUvPzE5Ij5odHRwOi8vd3d3Lmd5YWt1dGVuNi5uZXQvc2VyZWJ1 Lz8xOTwvQT48L0ZPTlQ+PEZPTlQgDQpzaXplPTI+PEEgDQpocmVmPSJodHRwOi8vd3d3LmRlYWkt c3R5bGUubmV0L2Nhc2Fub3ZhLz8xOTIwIj4yMDwvQT48L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBV SSBHb3RoaWMiIA0Kc2l6ZT0yPhskQjojJEokaTJxMHdIcSEmRy8ycUhxRXkwbEBaTDVOQSEqJDUk aSRLGyhCMTAsMDAwGyRCMV9KLCROTDVOQSVdJSQlcxsoQjxCUj4bJEIlSCRyJVclbCU8JXMlSCEq GyhCPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMg VUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJN UyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBm YWNlPSJNUyBVSSBHb3RoaWMiPjxGT05UIHNpemU9Mj4bJEIlYSE8JWtJVE1XJE5KfSRPJDMkQSRp JEsiLRsoQjxCUj48L0ZPTlQ+PEZPTlQgDQpmYWNlPRskQkFXQk4bKEIgc2l6ZT0yPjxBIA0KaHJl Zj0ibWFpbHRvOmNvbmNlcHQyX25ldEB5YWhvby5jYSI+Y29uY2VwdDJfbmV0QHlhaG9vLmNhPC9B PjwvRk9OVD48QSANCmhyZWY9Im1haWx0bzpjb25jZXB0X25ldEB5YWhvby5jYSI+PEZPTlQgDQpz aXplPTI+PC9GT05UPjwvQT48QlI+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0009_01C6325B.3372C490-- From majordomo@mil.doit.wisc.edu Thu Feb 16 12:41:42 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9n8Q-0007VL-LD for ipfix-archive@megatron.ietf.org; Thu, 16 Feb 2006 12:41:42 -0500 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 MAA14942 for ; Thu, 16 Feb 2006 12:39:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1F9moF-0003BR-00 for ipfix-list@mil.doit.wisc.edu; Thu, 16 Feb 2006 11:20:51 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1F9moE-0003BG-00 for ipfix@net.doit.wisc.edu; Thu, 16 Feb 2006 11:20:50 -0600 Received: from EXCHSRV.fokus.fraunhofer.de (einstein [10.147.9.230]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id k1GHKkv22920; Thu, 16 Feb 2006 18:20:46 +0100 (MET) 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_01C6331D.52944528" Subject: [ipfix] new draft with regard to: IPFIX testing Date: Thu, 16 Feb 2006 18:20:42 +0100 Message-ID: <70524A4436C03E43A293958B505008B60DE559@EXCHSRV.fokus.fraunhofer.de> Thread-Topic: new draft with regard to: IPFIX testing Thread-Index: AcYzHVBxLhA5m1B4TqS6nUdarXMa4g== From: "Carsten Schmoll" To: Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------_=_NextPart_001_01C6331D.52944528 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 Dear all, this mail is to kindly inform you that: =20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Flow Information Exchange (IPFIX) Testing =20 Author(s) : C. Schmoll, P. Aitken Filename : draft-schmoll-ipfix-testing-00.txt Pages : 17 Date : 2006-2-15 =20 This document presents a list of tests which implementers of IP Flow Information Export (IPFIX) compliant systems are encouraged to perform on their IPFIX system. This document has been created to help implementers test the functionality of their IPFIX exporter and/or collector component. The goal of these tests is to ensure that all important functions are covered by tests and thereby to gain a level of confidence in the system which allows the implementer to perform interoperabilty or plug tests with other IPFIX systems. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schmoll-ipfix-testing-00.txt alternateively on ftp: ftp://ftp.nordu.net/internet-drafts/draft-schmoll-ipfix-testing-00.txt =20 =20 Feedback and comments for improving the draft are highly appreciated! =20 =20 If you like to perform these tests (or a substantial subset) on real software (i.e. your IPFIX implementation) then you might want to take the chance to attend the IPFIX Interoperability Event,=20 March 1-2, 2006 in Salzburg/Austria. http://www.ips2006.org/index.php?option=3Dcom_content&task=3Dview&id=3D8&= Itemi d=3D14 =20 =20 I see this draft as an accompanying document to the guidelines draft, therefore I am also looking forward to your opinion about including=20 them together in the agenda of the upcoming USEIPFIX WG. =20 Kind regards, Carsten. =20 =20 -- "The difference between theory and practice is that in theory theory and practice are the same but in practice they are not." Dipl.Ing. Carsten Schmoll Fraunhofer Institute FOKUS schmoll@fokus.fraunhofer.de National Research Institute Fraunhofer FOKUS / dept. ANTS for Open Communication Systems Tel: +49-30-3463-7136 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8000 D-10589 Berlin, Germany =20 ------_=_NextPart_001_01C6331D.52944528 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
 
Dear=20 all,
this = mail is to=20 kindly inform you that:
 
A New Internet-Draft is available from = the on-line=20 Internet-Drafts directories.

 Title  : IP Flow Information = Exchange (IPFIX)=20 Testing
 
 Author(s) : C. Schmoll, P.=20 Aitken
 Filename :=20 draft-schmoll-ipfix-testing-00.txt
 Pages  :=20 17
 Date  : 2006-2-15
 
This document = presents a=20 list of tests which implementers of IP Flow
Information Export = (IPFIX)=20 compliant systems are encouraged to
perform on their IPFIX = system.  This=20 document has been created to
help implementers test the functionality = of=20 their IPFIX exporter
and/or collector component.  The goal of = these=20 tests is to ensure
that all important functions are covered by tests = and=20 thereby to gain
a level of confidence in the system which allows the=20 implementer to
perform interoperabilty or plug tests with other IPFIX = systems.
 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-schmoll-ipfix-testing-= 00.txt
alternateively on = ftp:
ftp://ftp.nordu.net/internet-drafts/draft-schmoll-ipfix-testing-00= .txt
 
 
Feedback and=20 comments for improving the draft are highly = appreciated!
 
 
If you = like to=20 perform these tests (or a substantial subset) on
real = software (i.e.=20 your IPFIX implementation) then you might
want = to take the=20 chance to attend the
 IPFIX=20 Interoperability Event,
March 1-2, 2006 in Salzburg/Austria.
http://www.ips2006.org/index.php?option=3D= com_content&task=3Dview&id=3D8&Itemid=3D14<= /DIV>
 
 
I see = this draft as=20 an accompanying document to the guidelines draft,
therefore=20 I am also=20 looking forward to your opinion about including
them = together in the=20 agenda of the upcoming USEIPFIX WG.
 
Kind=20 regards,
Carsten.
 
 
--"The difference between theory and = practice is=20 that in theory
theory and practice are the same but in practice they = are=20 not."

Dipl.Ing. Carsten=20 Schmoll           = Fraunhofer=20 Institute FOKUS
schmoll@fokus.fraunhofer.de      = ;  =20 National Research Institute
Fraunhofer FOKUS / dept.=20 ANTS       for Open Communication=20 Systems
Tel:=20 +49-30-3463-7136         &nb= sp;    =20 Kaiserin-Augusta-Allee 31
Fax:=20 +49-30-3463-8000         &nb= sp;    =20 D-10589 Berlin, Germany
 
------_=_NextPart_001_01C6331D.52944528-- -- 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 reinouefrai@republic.com Fri Feb 17 06:38:56 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA3wu-0001pU-8T for ipfix-archive@megatron.ietf.org; Fri, 17 Feb 2006 06:38:56 -0500 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 GAA20966 for ; Fri, 17 Feb 2006 06:37:07 -0500 (EST) Received: from [222.50.209.23] (helo=republic.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1F9zIe-0006Ee-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 Feb 2006 00:41:06 -0600 Message-ID: <000001c6338d$06f0fda0$7e8fa8c0@convalesce> Reply-To: "Efraim Reinoso" From: "Efraim Reinoso" To: ipfix-list@mil.doit.wisc.edu Subject: Re: ch andelier news Date: Fri, 17 Feb 2006 01:40:22 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C63363.1E1AF5A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?222.50.209.23 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C63363.1E1AF5A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 CgIyAoLqIcSn s$ q 3a,n3t3g V g IsAaGeRrAw b$w3a,k7 l 5 f=20 VyAbLfl m U j Mt g$ y 1 u ,r2g1 e=20 =20 http://www.ebarbec.com =20 ------=_NextPart_000_0001_01C63363.1E1AF5A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
CgIyAoLqIcSn s$ q 3a,n3t3g
V g IsAaGeRrAw b$w3a,k7 l 5 f
VyAbLfl m U j Mt g$ y 1 u ,r2g1 e
 
------=_NextPart_000_0001_01C63363.1E1AF5A0-- From dreams@findingstone.com Fri Feb 17 15:54:40 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FACci-0007Jt-AC for ipfix-archive@megatron.ietf.org; Fri, 17 Feb 2006 15:54:40 -0500 Received: from 113-54-235-201.fibertel.com.ar (113-54-235-201.fibertel.com.ar [201.235.54.113]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04331 for ; Fri, 17 Feb 2006 15:52:48 -0500 (EST) Received: (from allegro@microsoft.com) by microsoft.com (28.00.3/30.0.13/Submit) id chicagoan; Fri, 17 Feb 2006 17:14:02 -0500 Message-ID: <96043356@ceremony> From: Jodi Mckinnon To: ipfix-archive@ietf.org Subject: RE[0]: Don't be left behing- the enlargement revolution!... romeo Date: Fri, 17 Feb 2006 18:21:34 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 65800992.920552.39986.5972924 X-MimeOLE: Produced By Microsoft MimeOLE 6135193.741793.9829321.38411 Content-Type: multipart/mixed; boundary="------=626003665779" Content-Transfer-Encoding: 7bit --------=626003665779 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit hypothyroidbrowbeaten jacobuswigging

Hi, nice talking to you the other day.

here's that site I was telling you about. I got some for myself cause they were on sale, you should check out the site, I added the link below. They are offering huge disscounts now on Peniss Enhancmeent Patches

Steel Package: 10 Patches reg $69.95 Now $49.95! Free shipping too! You Save $30!

Silver Package: 25 Patches reg $139.95, Now $99.95! Free shipping and free exercise manual included! You Save $40!

Gold Package: 40 Patches reg $189.95, Now $149.95! Free shipping and free exercise manual included! You Save $50!

Platinum Package: 65 Patches reg $269.95, Now $199.95! Free shipping and free exercise manual included! (Best Value!) You Save $70!

I know like 10 guys who have already stocked up on these. Don't be left behind!

"Thank you Peniss Enhancmeent Patch for enriching my marriage through an enhanced sexaul relationship. My wife has become so much more interested in sex and now often initiates."

-Marietta Isaac

Give it a shot... Peniss Enhancmeent Patchs and see how it will change your life!

--------=626003665779 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, nice talking to you the other day. Here's that site I was telling you about. I got some for myself cause they were on sale, you should check out the site, I added the link below. They are offering huge disscounts now on Peniss Enhancmeent Patches Steel Package: 10 Patches reg $69.95...Now $49.95!...Free shipping too!...You Save $30! Silver Package: 25 Patches reg $139.95...Now $99.95!...Free shipping and free exercise manual included!...You Save $40! Gold Package: 40 Patches reg $189.95...Now $149.95!...Free shipping and free exercise manual included!...You Save $50! Platinum Package: 65 Patches reg $269.95...Now $199.95!...Free shipping and free exercise manual included!...(Best Value!) You Save $70! I know like 10 guys who have already stocked up on these. Don't be left behind! "Thank you Peniss Enhancmeent Patch for enriching my marriage through an enhanced sexaul relationship. My wife has become so much more interested in sex and now often initiates." -Christian Dove Give it a shot... Peniss Enhancmeent Patchs and see how it will change your life http://www.fgerut.biz/pt/?34&55876947035728 --------=626003665779-- From barsiddh@dasc.mod.uk Fri Feb 17 19:45:11 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAGDn-0004wR-41 for ipfix-archive@megatron.ietf.org; Fri, 17 Feb 2006 19:45:11 -0500 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 TAA06518 for ; Fri, 17 Feb 2006 19:43:22 -0500 (EST) Received: from [65.73.113.233] (helo=dasc.mod.uk) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FAFtQ-0007nP-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 Feb 2006 18:24:08 -0600 Message-ID: <000001c63421$8e1b8090$b283a8c0@orthographical> Reply-To: "Siddharta Barbe" From: "Siddharta Barbe" To: ipfix-list@mil.doit.wisc.edu Subject: Re: national ly news Date: Fri, 17 Feb 2006 19:23:34 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C633F7.A5457890" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?65.73.113.233 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C633F7.A5457890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 VgAjLvlqUtMv e$ g 1 a ,c2a1r VpI b A r GaR m Ad t$ y 3y,e7 n 5e CeIpAwLgI j Sk c $c3q,n3 z 3 r=20 =20 http://www.awaromita.com =20 ------=_NextPart_000_0001_01C633F7.A5457890 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
VgAjLvlqUtMv e$ g 1 a ,c2a1r
VpI b A r GaR m Ad t$ y 3y,e7 n 5e
CeIpAwLgI j Sk  c $c3q,n3 z 3 r
 
------=_NextPart_000_0001_01C633F7.A5457890-- From release@gobiernofederal.com Fri Feb 17 23:04:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAJKC-0005Wa-MC for ipfix-archive@megatron.ietf.org; Fri, 17 Feb 2006 23:04:00 -0500 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 XAA17743 for ; Fri, 17 Feb 2006 23:02:11 -0500 (EST) Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FAJEq-0001Tk-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 Feb 2006 21:58:28 -0600 Received: from -1240152832 ([211.108.228.99]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k1I3vvwf020332 for ; Fri, 17 Feb 2006 21:58:17 -0600 Received: from gobiernofederal.com (-1212183664 [-1239768352]) by guadalupano.com (Qmailv1) with ESMTP id 433AA6E856 for ; Fri, 17 Feb 2006 05:02:31 -0500 Date: Fri, 17 Feb 2006 05:02:31 -0500 From: dollarcrew X-Mailer: The Bat! (v2.00.4) Personal X-Priority: 3 Message-ID: <5601092609.20060217050231@gobiernofederal.com> To: Ipfix Subject: Work From Home! 2000 dol p'r week! MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 mion Content-Transfer-Encoding: 7bit You can participate in our money forwarding program! you can earn up to $2000 a week. please visit http://www.dollarcrew.com for more details noreply@dollarcrew.com From wicklifo@ashrafs.com.bh Mon Feb 20 05:49:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7ZC-0003LY-Th for ipfix-archive@lists.ietf.org; Mon, 20 Feb 2006 04:42:50 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB7Rn-000084-L5 for ipfix-archive@lists.ietf.org; Mon, 20 Feb 2006 04:35:13 -0500 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FB7HJ-0006VV-00 for ipfix-list@mil.doit.wisc.edu; Mon, 20 Feb 2006 03:24:21 -0600 Received: from ashrafs.com.bh (i60-34-240-199.s05.a001.ap.plala.or.jp [60.34.240.199]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k1K9OAWd009142 for ; Mon, 20 Feb 2006 03:24:19 -0600 Message-ID: <000001c635ff$579dcd90$a635a8c0@citrate> Reply-To: "Isis Wickliffe" From: "Isis Wickliffe" To: ipfix-list@mil.doit.wisc.edu Subject: Re: remo ve news Date: Mon, 20 Feb 2006 04:23:42 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C635D5.6EC7C590" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.7 (++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C635D5.6EC7C590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable V u A p L n l y U e M f=20 X i a i n z a k x g=20 V s I z A o G y R v A u=20 C f I q A q L v I p S v=20 A m m n b g i j e p n z=20 http://www.sopolarin.com =20 ------=_NextPart_000_0001_01C635D5.6EC7C590 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
V u A p L n l y U e M f
X i a i n z a k x g
V s I z A o G y R v A u
C f I q A q L v I p S v
A m m n b g i j e p n z
------=_NextPart_000_0001_01C635D5.6EC7C590-- From kirsialitch@laerdal.no Tue Feb 21 00:10:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBPmt-0007ia-0M for ipfix-archive@lists.ietf.org; Tue, 21 Feb 2006 00:10:11 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBPmr-0002LY-NM for ipfix-archive@lists.ietf.org; Tue, 21 Feb 2006 00:10:10 -0500 Received: from c-24-127-39-71.hsd1.ca.comcast.net ([24.127.39.71] helo=laerdal.no) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FBPWW-0006ie-00 for ipfix-list@mil.doit.wisc.edu; Mon, 20 Feb 2006 22:53:16 -0600 Message-ID: <000001c636a2$adeefb80$d951a8c0@steamship> Reply-To: "Kirsi Litchford" From: "Kirsi Litchford" To: ipfix-list@mil.doit.wisc.edu Subject: Re: benum b news Date: Mon, 20 Feb 2006 23:52:55 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C63678.C51B3D70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?24.127.39.71 X-Spam-Score: 4.0 (++++) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C63678.C51B3D70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, http://www.mastouris.com =20 VlItAoGiRxAd x$s3e,f7e5t CpIeAhLaInSv x$n3w,c3u3o VzAvLflvUqMd s$m1h,l2g1g ------=_NextPart_000_0001_01C63678.C51B3D70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
VlItAoGiRxAd x$s3e,f7e5t
CpIeAhLaInSv x$n3w,c3u3o
VzAvLflvUqMd s$m1h,l2g1g
------=_NextPart_000_0001_01C63678.C51B3D70-- From lofla@ltv1861.de Tue Feb 21 21:16:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBjYW-0002ih-QU for ipfix-archive@lists.ietf.org; Tue, 21 Feb 2006 21:16:40 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBjYU-0008Ev-Hi for ipfix-archive@lists.ietf.org; Tue, 21 Feb 2006 21:16:40 -0500 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FBjIM-00002j-00 for ipfix-list@mil.doit.wisc.edu; Tue, 21 Feb 2006 19:59:58 -0600 Received: from ltv1861.de ([210.207.25.32]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k1M1xs6u012661 for ; Tue, 21 Feb 2006 19:59:55 -0600 Message-ID: <000001c63753$9f6ef4a0$3f70a8c0@apologetics> Reply-To: "Gavrel Lofland" From: "Gavrel Lofland" To: ipfix-list@mil.doit.wisc.edu Subject: Re: N ewfoundland news Date: Tue, 21 Feb 2006 20:59:32 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C63729.B69B3690" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.0 (++++) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C63729.B69B3690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, http://www.ostalanca.com =20 VgAsLilnUyMt f$w1o,n2p1k VbItAlGvRbAr d$u3s,g7d5a CtIhAfLhIbSr r$j3j,r3t3w ------=_NextPart_000_0001_01C63729.B69B3690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
VgAsLilnUyMt f$w1o,n2p1k
VbItAlGvRbAr d$u3s,g7d5a
CtIhAfLhIbSr r$j3j,r3t3w
------=_NextPart_000_0001_01C63729.B69B3690-- From majordomo@mil.doit.wisc.edu Wed Feb 22 17:27:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC2SX-0000Wn-TL for ipfix-archive@lists.ietf.org; Wed, 22 Feb 2006 17:27:45 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC2SU-0006Wz-Jl for ipfix-archive@lists.ietf.org; Wed, 22 Feb 2006 17:27:45 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FC2O3-0003pM-00 for ipfix-list@mil.doit.wisc.edu; Wed, 22 Feb 2006 16:23:07 -0600 Received: from harpo.itss.auckland.ac.nz ([130.216.190.13]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FC2O2-0003pB-00 for ipfix@net.doit.wisc.edu; Wed, 22 Feb 2006 16:23:06 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id E5FD4351C0 for ; Thu, 23 Feb 2006 11:23:04 +1300 (NZDT) Received: from harpo.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 26299-10 for ; Thu, 23 Feb 2006 11:23:04 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id C6059351EE for ; Thu, 23 Feb 2006 11:23:04 +1300 (NZDT) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id k1MMN4j26437 for ipfix@net.doit.wisc.edu; Thu, 23 Feb 2006 11:23:04 +1300 Received: from nevil-laptop.cs.auckland.ac.nz (nevil-laptop.cs.auckland.ac.nz [130.216.38.130]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Thu, 23 Feb 2006 11:23:04 +1300 Message-ID: <1140646984.aa18b97b7db83@webmail.auckland.ac.nz> Date: Thu, 23 Feb 2006 11:23:04 +1300 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] DRAFT agenda for IPFIX meeting at Dallas IETF 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.38.130 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Hi all: **DRAFT** IPFIX Agenda for IETF 65, Dallas ------------------------------------------ We have scheduled an IPFIX meeting in Dallas, our time slot is currently Wednesday 22 March, 1300-1500. Items to be discussed are: 1) Drafts currently with IESG * Report on current status of - draft-ietf-ipfix-as-06.txt - draft-ietf-ipfix-architecture-09.txt - draft-ietf-ipfix-protocol-19.txt - draft-ietf-ipfix-info-11.txt Note that there has been onging discussion of some of these drafts on the IPFIX mailing list. 'Minor, editorial' changes to them can be made as we work through any changes suggested by the AD review. 2) IPFIX charter review * The following IPFIX-related indiviual drafts have been published: - boschi-export-perpktinfo-01.txt - boschi-ipfix-biflow-01.txt - boschi-ipfix-implementation-guidelines-00.txt - draft-bclaise-ipfix-reliability-00.txt - draft-schmoll-ipfix-testing-00.txt - draft-trammell-ipfix-file-00.txt - dressler-ipfix-aggregation-02.txt - stephan-isp-templates-01.txt * We want to select a few of these to become IPFIX WG items. The items selected should be those that are most important for IPFIX, particularly in helping users to deploy it. And of course, we want to select items that can be completed within a short time frame, i.e. < one year! If you have other items you'd like to see discussed, please advise the WG chairs by email to ipfix-chairs@net.doit.wisc.edu ----------------------------------------------------------------------- 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 westeonat@fatman.com Thu Feb 23 10:27:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCINn-0001xQ-1j for ipfix-archive@lists.ietf.org; Thu, 23 Feb 2006 10:27:55 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCINl-0007Gk-PG for ipfix-archive@lists.ietf.org; Thu, 23 Feb 2006 10:27:55 -0500 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FCHzs-0002xc-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Feb 2006 09:03:12 -0600 Received: from fatman.com (lns-bzn-37-82-253-39-74.adsl.proxad.net [82.253.39.74]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k1NF37hC011877 for ; Thu, 23 Feb 2006 09:03:10 -0600 Message-ID: <000001c6388a$3d8ad9b0$b841a8c0@phlegmon> Reply-To: "Natalee Westergard" From: "Natalee Westergard" To: ipfix-list@mil.doit.wisc.edu Subject: Re: mo ll news Date: Thu, 23 Feb 2006 10:03:01 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C63860.54B4D1B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.4 (++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C63860.54B4D1B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, http://www.doteathe.com =20 n C o I m A w L x I g S d a $ n 3 j , r 3 a 3 d=20 q V d A a L g l v U o M w i $ d 1 x , c 2 s 1 j=20 s V z I d A v G h R x A i h $ s 3 d , i 7 x 5 m=20 ------=_NextPart_000_0001_01C63860.54B4D1B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
n C o I m A w L x I g S d   a $ n 3 j , r 3 a 3 d
q V d A a L g l v U o M w   i $ d 1 x , c 2 s 1 j
s V z I d A v G h R x A i   h $ s 3 d , i 7 x 5 m
------=_NextPart_000_0001_01C63860.54B4D1B0-- From boneya@value.net.nz Fri Feb 24 06:59:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCbbE-0004RK-AJ for ipfix-archive@lists.ietf.org; Fri, 24 Feb 2006 06:59:04 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCbbD-0000Ay-21 for ipfix-archive@lists.ietf.org; Fri, 24 Feb 2006 06:59:04 -0500 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FCbGW-0005iM-00 for ipfix-list@mil.doit.wisc.edu; Fri, 24 Feb 2006 05:37:40 -0600 Received: from value.net.nz ([221.208.87.21]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k1OBbWv8001879 for ; Fri, 24 Feb 2006 05:37:37 -0600 Message-ID: <000001c63936$b0f60c10$ae6aa8c0@cannot> Reply-To: "Esi Boney" From: "Esi Boney" To: ipfix-list@mil.doit.wisc.edu Subject: Re: schol asticism Date: Fri, 24 Feb 2006 06:37:28 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6390C.C8200410" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.2 (++) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6390C.C8200410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 http://www.tookelopter.com =20 C j I b A n L w I l S u a $ q 3 a , z 3 w 3 j=20 V n A i L u l v U m M c b $ v 1 m , q 2 j 1 y=20 V r I n A z G w R f A m r $ i 3 r , w 7 m 5 k=20 ------=_NextPart_000_0001_01C6390C.C8200410 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
 
C j I b A n L w I l S u   a $ q 3 a , z 3 w 3 j
V n A i L u l v U m M c   b $ v 1 m , q 2 j 1 y
V r I n A z G w R f A m   r $ i 3 r , w 7 m 5 k
------=_NextPart_000_0001_01C6390C.C8200410-- From janec@lakesunbank.com Sun Feb 26 04:40:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDIOB-0007A1-8f for ipfix-archive@lists.ietf.org; Sun, 26 Feb 2006 04:40:27 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDIOA-0005K0-04 for ipfix-archive@lists.ietf.org; Sun, 26 Feb 2006 04:40:27 -0500 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FDIIF-0002Bf-00 for ipfix-list@mil.doit.wisc.edu; Sun, 26 Feb 2006 03:34:19 -0600 Received: from lakesunbank.com ([213.13.209.79]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k1Q9YHiU028894 for ; Sun, 26 Feb 2006 03:34:18 -0600 Message-ID: <000001c63ab7$c4d4e2b0$a95ea8c0@avv91> Reply-To: "Janecek Benning" From: "Janecek Benning" To: ipfix-list@mil.doit.wisc.edu Subject: brea kage news Date: Sun, 26 Feb 2006 04:33:58 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C63A8D.DBFEDAB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.9 (++) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C63A8D.DBFEDAB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable V=20 C=20 A=20 X=20 L=20 P=20 V=20 A=20 I=20 m=20 a=20 e=20 r=20 I=20 L=20 A=20 b=20 n=20 v=20 o=20 A=20 I=20 L=20 i=20 a=20 i=20 z=20 G=20 U=20 I=20 e=20 x=20 t=20 a=20 R=20 M=20 S=20 n=20 r=20 c=20 A=20 =20 =20 a=20 =20 =20 http://www.swellasdem.com =20 ------=_NextPart_000_0001_01C63A8D.DBFEDAB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
V
C
=
A
X
L
P
= V
A
I
=
m
a
e
r
= I
L
A
=
b
n
v
o
= A
I
L
=
i
a
i
z
= G
U
I
=
e
x
t
a
= R
M
S
=
n

r
c
= A
 
 

=
a

 
 
------=_NextPart_000_0001_01C63A8D.DBFEDAB0-- From hugesusanji@activemedia.cz Mon Feb 27 07:35:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDhbW-0007yY-N7 for ipfix-archive@lists.ietf.org; Mon, 27 Feb 2006 07:35:54 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDhbU-000056-PJ for ipfix-archive@lists.ietf.org; Mon, 27 Feb 2006 07:35:54 -0500 Received: from [220.187.127.139] (helo=activemedia.cz) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FDhVM-00038Z-00 for ipfix-list@mil.doit.wisc.edu; Mon, 27 Feb 2006 06:29:33 -0600 Message-ID: <000001c63b99$5f88e540$ed4ba8c0@bhk27> Reply-To: "Sanjit Huges" From: "Sanjit Huges" To: ipfix-list@mil.doit.wisc.edu Subject: ex tinguish news Date: Mon, 27 Feb 2006 07:28:54 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C63B6F.76B2DD40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.0 (+) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C63B6F.76B2DD40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A=20 C=20 P=20 V=20 L=20 X=20 V=20 m=20 I=20 r=20 I=20 e=20 a=20 A=20 b=20 A=20 o=20 A=20 v=20 n=20 L=20 i=20 L=20 z=20 G=20 i=20 a=20 I=20 e=20 I=20 a=20 R=20 t=20 x=20 U=20 n=20 S=20 c=20 A=20 r=20 M=20 =20 =20 a=20 =20 =20 http://www.canalwago.com =20 ------=_NextPart_000_0001_01C63B6F.76B2DD40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
A
C
P
=
V
L
X
= V
m
I
r
=
I
e
a
= A
b
A
o
=
A
v
n
= L
i
L
z
=
G
i
a
= I
e
I
a
=
R
t
x
= U
n
S
c
=
A
r

= M

 

=  
a

 
 
------=_NextPart_000_0001_01C63B6F.76B2DD40-- From majordomo@mil.doit.wisc.edu Mon Feb 27 21:55:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDv13-0002Ka-06 for ipfix-archive@lists.ietf.org; Mon, 27 Feb 2006 21:55:09 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDv10-00013I-Nw for ipfix-archive@lists.ietf.org; Mon, 27 Feb 2006 21:55:08 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FDudw-0005Yb-00 for ipfix-list@mil.doit.wisc.edu; Mon, 27 Feb 2006 20:31:16 -0600 Received: from mail.nttv6.net ([192.68.245.115]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FDudu-0005YQ-00 for ipfix@net.doit.wisc.edu; Mon, 27 Feb 2006 20:31:14 -0600 Received: from [127.0.0.1] (dhcp-3-151.nttv6.com [192.47.163.151]) by mail.nttv6.net (8.13.5/8.13.5) with ESMTP id k1S2VBJ4046724 for ; Tue, 28 Feb 2006 11:31:12 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 28 Feb 2006 11:31:13 +0900 From: kobayashi atsushi To: ipfix@net.doit.wisc.edu Subject: [ipfix] discussion about IPFIX concentrator Message-Id: <20060228105020.BF73.AKOBA@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.12.01 [ja] Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Dear all, I have submitted new drafts. These drafts are concerning to IPFIX concentrators. One is about the reference model of IPFIX concentrator, the other is about MIB objects of IPFIX concentrator and IPFIX collector. I would like to discuss with you about these topics. Comments are welcome. Subject: I-D ACTION:draft-kobayashi-ipfix-concentrator-mib-00.txt http://www.ietf.org/internet-drafts/draft-kobayashi-ipfix-concentrator-mib-00.txt Subject: I-D ACTION:draft-kobayashi-ipfix-concentrator-model-00.txt http://www.ietf.org/internet-drafts/draft-kobayashi-ipfix-concentrator-model-00.txt I have plan to revise to two drafts within current week, I will add just one co-author without changing body text. Sorry, if it might confuse you. Best Regards, Atsushi KOBAYASHI --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5652 -- 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 advertising@4webmarketing.biz Mon Feb 27 22:37:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDvgQ-0005vl-Vy for ipfix-archive@lists.ietf.org; Mon, 27 Feb 2006 22:37:54 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDvgP-0002bW-Ne for ipfix-archive@lists.ietf.org; Mon, 27 Feb 2006 22:37:54 -0500 Received: from sls-da4p19.eicononline.com ([66.36.242.112]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FDvNM-0002aW-00 for ipfix-list@mil.doit.wisc.edu; Mon, 27 Feb 2006 21:18:12 -0600 Received: from bquhcnw (25.6.25.201) by sls-da4p19.eicononline.com; Mon, 27 Feb 2006 22:18:15 -0500 Date: Mon, 27 Feb 2006 22:18:15 -0500 From: X-Mailer: The Bat! (v2.01) Reply-To: X-Priority: 2 (High) Message-ID: <996513245.20050519095449@4webmarketing.biz> To: Subject: =?iso-8859-5?B?QUNFIENoZWNrIEV4cHJlc3Mg?= =?iso-8859-5?B?SW5jLiBoYXMgaW1tZWRpYXRl?= =?iso-8859-5?B?IHdvcmsgZm9yIEF1c3RyYWxp?= =?iso-8859-5?B?YW4gYW5kIE5ldyBaZWFsYW5k?= =?iso-8859-5?B?IGNpdGl6ZW5z?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------BFF8FF5A9B2BE1" X-Spam-Score: 2.9 (++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca ------------BFF8FF5A9B2BE1 Content-Type: text/plain; charset=iso-8859-5 Content-Transfer-Encoding: 8bit ACE Check Express Inc. was founded in 1996 as a partner and connecting link between hundreds of banks in the world engaged in e-commerce. Our specialists from the Institute of Economic Research created the ACE Money TurnoverŪ - the system that ensured quality, high speed and reliability of money transfer. As of today, ACE Check Express Inc. is not only a link in a big chain of the world financial flows, but also an independent segment whose services are impossible to do without even for such bank as the Citibank (www.citibank.com). That is why our managers, from beginners to professionals in the money transfer, use the accounts of the Citibank for the Citibank has been our customer in the field of on-line money transfer and conversion into cash services since 2002. We are proud of the reliability of our system, which ensures safe money transfers via Internet between our clients wherever they are. Dream of becoming a manager with a high salary? We can help you fulfill your dream of having a reliable, stable profit each month from working in the Internet. You may ask why. It is very simple - most probably, you know that the World Wide Web, or the Internet develops very quickly and now connects billions of people around the world and the Internet business really brings profits. We have arranged and organized the flows of out customers' funds into the ACE Money TurnoverŪ system (hereinafter referred to as the AMTŪ) whose integral part you may become by making very little effort. And indeed, in order to become a manager for money transfer processing you need to have an account with a Australian or New Zealand bank, a computer connected to the Internet and a little free time. Don't miss chance to work as our financial representative! Start new career with ACE Check Cashing Group, our motto - Financial stability for us and our partners. Please advise: The source of the information about this open position ( a person, an e-mail letter, a newspaper, an ICQ message). Could you describe educational background and professional experience, and your current position. Please feel free to ask us any questions you may have. If you would like to join our team contact us via e-mail at: acecheckcash@aol.com Regards, Julia Bordovsky HR recruiter ACE Cashing Team ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4 Web Marketing Internet Advertising Agency Australia Manager 194 The Esplanade Scarborough Beach Perth Western Australia 6019 No Soliciting Business to Business Advertising ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you have questions or comments for 4 Web Marketing, please use our feedback form. This email was sent from Account ID AQ72X5Y9XY8RJMQDDX and by this logged in User U8A38P5WVT2TS1YX6BF ------------BFF8FF5A9B2BE1-- From gaudincaoilfh@puydufou.tm.fr Tue Feb 28 01:20:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDyDc-00080J-S3 for ipfix-archive@lists.ietf.org; Tue, 28 Feb 2006 01:20:20 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDyDb-0007CM-5S for ipfix-archive@lists.ietf.org; Tue, 28 Feb 2006 01:20:20 -0500 Received: from [60.209.65.240] (helo=puydufou.tm.fr) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FDy2A-0001tD-00 for ipfix-list@mil.doit.wisc.edu; Tue, 28 Feb 2006 00:08:30 -0600 Message-ID: <000001c63c2d$5ea2f2d0$5424a8c0@nzg92> Reply-To: "Caoilfhionn Gaudin" From: "Caoilfhionn Gaudin" To: ipfix-list@mil.doit.wisc.edu Subject: mor n news Date: Tue, 28 Feb 2006 01:08:18 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C63C03.75CCEAD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.0 (+) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C63C03.75CCEAD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable L=20 V=20 A=20 V=20 P=20 C=20 X=20 e=20 I=20 m=20 A=20 r=20 I=20 a=20 v=20 A=20 b=20 L=20 o=20 A=20 n=20 i=20 G=20 i=20 I=20 z=20 L=20 a=20 t=20 R=20 e=20 U=20 a=20 I=20 x=20 r=20 A=20 n=20 M=20 c=20 S=20 a=20 =20 =20 =20 =20 http://www.sinclued.com =20 ------=_NextPart_000_0001_01C63C03.75CCEAD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
L
V
A
=
V
P
C =
X
e
I
m
=
A
r
I =
a
v
A
b
=
L
o
A =
n
i
G
i
=
I
z
L =
a
t
R
e
=
U
a
I =
x
r
A
n
=
M
c
S =

a
 

  =

 

 
------=_NextPart_000_0001_01C63C03.75CCEAD0--