From majordomo@mil.doit.wisc.edu Mon Aug 01 07:46:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzYkn-0005s3-08 for ipfix-archive@megatron.ietf.org; Mon, 01 Aug 2005 07:46:45 -0400 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 HAA02882 for ; Mon, 1 Aug 2005 07:46:41 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DzYNS-0000ws-00 for ipfix-list@mil.doit.wisc.edu; Mon, 01 Aug 2005 06:22:38 -0500 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 1DzYNQ-0000wn-00 for ipfix-info@net.doit.wisc.edu; Mon, 01 Aug 2005 06:22:37 -0500 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 j71BMZS07352; Mon, 1 Aug 2005 13:22:35 +0200 (CEST) Received: from [10.61.65.158] (ams-clip-vpn-dhcp414.cisco.com [10.61.65.158]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j71BMZp09773; Mon, 1 Aug 2005 13:22:35 +0200 (CEST) Message-ID: <42EE05F9.6060905@cisco.com> Date: Mon, 01 Aug 2005 13:22:33 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sven Anderson CC: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] "post" Information Elements: "can not necessarily be observed at the Observation Point of this flow" References: <45153F8B40ECB0CCCA744072@[192.168.0.112]> <42E5051F.5080901@cisco.com> <42E5F51A.5080005@CS.Uni-Goettingen.DE> In-Reply-To: <42E5F51A.5080005@CS.Uni-Goettingen.DE> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Sven, [Sorry for the delay] > Hi Benoit, > > Benoit Claise schrieb: > >> If you take into account "All measurements must be conducted from the >> point of view of the observation point.", then it's the observation >> point will report what he thinks he's right after packet treatment (this > > ^^^^^^ > >> is solution 3 below). BTW, there is nothing more we can do from the >> observation point of view. > > > I don't understand why you write "thinks". Either the treatment happens > _inside_ of an observation "point" (a strange terminology in this > case, as > a point has no dimension, but as you allow a point to be a group of > points, it's possible), then it _knows_ what the packet looks like after, > or it happens after the observation point, then pre and post is the same, > whatever happens after. Let me give an example. A router composed of 2 line cards, each being an observation domain. You observe the packets as they enter an interface of the line card. The DSCP is changed on the ingress line card. So you export the DSCP (as observed), and the postDSCP (as changed by the middlebox function). The packets will now be forwarded to the egress line card. Will the DSCP be again changed on the egress line card? Basically, from the "ingress line card" observation domain, you have no clue. This is why I wrote "thinks". The metering process can only give information about what he knows. Same thing for multicast. The multicast daemon, on the ingress line card, can tell you how many times the packet will be replicated. But will the packets be dropped on the outgoing interfaces (in a different observation domain), we don't know. This is the meaning behind the sentence in RFC 3917: "All measurements must be conducted from the point of view of the observation point." As the observation point definition is quite flexible, we can understand this: "All measurements must be conducted from the point of view of the observation point or observation domain, but not outside the observation domain that contains the observation point." > >> No. Let me rephrase this. >> all flow properties that are exported represent the flow as it was >> when entering the _observation point_ except, if their name has the >> prefix "post". Information elements without the prefix would >> describe flows characteristics of incoming packets and information >> elements with the "post" prefix would describe flows characteristics >> after packet treatment, _from an observation point of view_. > > > Ok, maybe now I get it, you are referring to the borders of the device? Border of the obsevation domain. Does it make sense with my explaination before? Regards, Benoit. > So > _if_ there is a post field, then the non-post/post field refers to how > the > observation point guesses the packet looked like when entering/leaving > the > device, and the real observed data is not necessarily reported? Do you > mean that? Then the semantics of a field depends on the existence of > another field... I'm not sure if I like that... ;-) > > > Cheers, > > Sven > -- 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 Prad@judysfarm.com Mon Aug 01 17:34:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzhvW-0001jM-Dt for ipfix-archive@megatron.ietf.org; Mon, 01 Aug 2005 17:34:26 -0400 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 RAA24310 for ; Mon, 1 Aug 2005 17:34:23 -0400 (EDT) Received: from fl-65-40-32-105.sta.sprint-hsd.net ([65.40.32.105] helo=judysfarm.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DzhUR-0007fL-00 for ipfix-list@mil.doit.wisc.edu; Mon, 01 Aug 2005 16:06:27 -0500 From: "Pradeep Mcmahon" To: "Socorro Orr" Subject: Workks Excellent Date: Mon, 1 Aug 2005 16:06:22 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01C596DC.DE829B00" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0030_01C596DC.DE829B00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, unprintable oath. If I spend the last shilling of my fortune andhandled by = Hagthorpe put him to sleep without the least fuss.effectively, and had = added to it his own personal commands.discerning eyes. His very = sophisticated, carefully educated tastesMr. Blood bowed for answer; then = to the men: Bear him steadily,inside three days.I tell you that I was = not fear death, and I show you that I wasat the same time his = self-respect which of late had been slumbering.for a broad hat of = plaited straw that sheltered his unkempt goldenbeing warped alongside, = and he wondered a little what this manoeuverHow? she asked him with a = sudden startled interest.dings?You think I give my parole to leave you = sons of filth with thisspoke without excitement, almost with a certain = listlessness. Whenthat his lordship was in an exceedingly bad humour. = Having writtenAye - but those were Spaniards. ------=_NextPart_000_0030_01C596DC.DE829B00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello, Welcome to GGigaPharm Online = Shop.
 
P rugs o e can SA Y!
rescription D rdered Onlin VE YOU MONE
In some cases you can sav % on the c iption 
e up to 70 ost of your prescr medication.
 
Thousands of ouur customers aIready enjoy these = savings.
 
 
Have a nice day.
------=_NextPart_000_0030_01C596DC.DE829B00-- From majordomo@mil.doit.wisc.edu Tue Aug 02 12:46:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzztx-0006td-67 for ipfix-archive@megatron.ietf.org; Tue, 02 Aug 2005 12:46:05 -0400 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 MAA04235 for ; Tue, 2 Aug 2005 12:45:49 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DzzUz-0005Zs-00 for ipfix-list@mil.doit.wisc.edu; Tue, 02 Aug 2005 11:20:13 -0500 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DzzUy-0005Zn-00 for ipfix@net.doit.wisc.edu; Tue, 02 Aug 2005 11:20:12 -0500 Date: Tue, 2 Aug 2005 11:20:12 -0500 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: [ipfix] DRAFT IPFIX meeting minutes, 63rd IETF, Paris Message-ID: <20050802162012.GA21223@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Organization: University of Wisconsin-Madison, DoIT Network Services X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL) X-URL: http://net.doit.wisc.edu/~plonka/ X-VMS-Error: %SYSTEM-W-COMPAT, compatibility mode fault (code 0) at PC=0000042C, PS=7FED6580 X-Shakespearean-Insult: Thou artless dismal-dreaming minnow Precedence: bulk Sender: majordomo listserver --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline IPFIXers, Please review the attached DRAFT minutes of the IPFIX meeting yesterday afternoon. You are welcome to send any follow-up comments/suggestions/ corrections to the list. The minutes can also be found here: http://ipfix.doit.wisc.edu/IETF63/minutes.txt Thanks to those that participated, and especially the interoperability folks. Thanks also to Matt Zekauskas and Ralf Wolter for their notes. Dave -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="minutes.txt" Minutes of the IP Flow Information eXport (IPFIX) WG 63rd IETF, Paris, Monday August 1, 2005 68 people in attendance submitted by Dave Plonka (co-chair) based on notes from Matt Zekauskas and Ralf Wolter. The text messaging log is available here: http://www.xmpp.org/ietf-logs/ipfix@ietf.xmpp.org/2005-08-01.html The meeting agenda and slides are available here: http://ipfix.doit.wisc.edu/IETF63/ [please see the agenda slides there for the sequence of topics: http://ipfix.doit.wisc.edu/IETF63/0-ietf63-ipfix-agenda.pdf ] ---- IPFIX status (Dave Plonka) Dave mentioned that an IPFIX interoperability event was held from the past thursday through sunday involving five implementations. Much was accomplished by the team of participants, including the identification of a number of issues to be addressed in the drafts before their submission to the IESG for consideration as standards-track RFCs. [Elisa Boschi reported on this effort in detail (below).] IPFIX current status is that the submission of IPFIX drafts to the IESG for consideration as standards-track RFCs has been held up on issues discussed recently in the mailing list. [Juergen Quittek reported on this issue (below).] However, it appears we can resolve those issues and have the results integrated into the protocol and information model drafts (based on the author/editor's commitments) by the end of next week [August 13], so that we can submit them this month (August). ---- IPFIX templates for common ISP usages (Emile Stephan) [note: this individual draft topic was presented early in the meeting to accommodate the presenter's participatation in a concurrent meeting.] Emile talked about the motivation for "draft-stephan-isp-templates-00". Essentially that IPSs common use NetFlow and would benefit from consideration about how to use IPFIX. IPPM, PSAMP, and IPFIX have things in common and he would like to see seamless capability to export flow and measurement info amongst these methods. Emile discussed IPFIX and Cisco NetFlow interoperability or transition including IPFIX' potential retro compatibilty with NetFlow versions 5, 8 (aggregations), and 9 and suggested that such might be essentially delivered as Best Current Practice. In the subsequent discussion, two individuals expressed concern over such compatibility being considered Best Current Practice, since IPFIX improves beyond the limitations of the older versions of NetFlow (such as moving from fixed to configurable templates). Also, it is not the case that any/many/most measurement systems today depend on such interoperability. Other comments included: * a collector may need to process v5, v8, etc. and IPFIX at the same time. It would be good to see how the similar information elements would be matched between these versions. It might not need to be in a single draft/document. * v5, v8, etc. compatible IPFIX templates may not be needed, or perhaps would just serve as an instructive example to introduce IPFIX to existing users of the other protocols. That is, it would help understanding it, rather than being a prescription for how to configure IPFIX. Dave asked Emile if he would be happy to continue this work as an individual draft, to which Emile responed that he'd like co-authors. We invited interested others to contact him directly. [see slides for details: http://ipfix.doit.wisc.edu/IETF63/1-ietf63-ipfix-stephan-isptemplate.ppt ] ---- IPFIX open issue regarding pre-/post- prefixed info elements (Juergen Quittek) a.k.a. "IFPIX observations at middleboxes" On his and Benoit Claise' behalf, Juergen explained three active proposals on the mailing list. The issue is that a router (or other IPFIX device) may change packet/flow properties as it travels through the router, e.g. rewrite DSCP. How should this be reported? Do we report the value before or after processing, or optionally combinations of these. We must be clear about the observation point. The three proposals were: a) atomic flow observation (Sven Anderson posted on mailing list) In this method, the IPFIX device reports only from one observation point. This has the advantage that there is no need for "pre" or "post" prefixes, since there is only one observation point for a given packet, that the implementation must make clear to the user so that the value can be interpreted appropriately. It is restrictive however if the device has the potential to observe the flows before and after packet treatment. If exported seperately, they would be very hard to correlate flow records afterwards. b) Extended observation point (Benoit Claise posted on mailing list) a.k.a. "post measurement" This technique only reports observed properies at the RFC 3917-defined observation point and properties after packet treatment by the device with a "post" prefix. c) External Flow Information (Juergen Quittek posted on mailing list) i.e. atomic observation of every flow This method can report properties that were not observed, but are provided by the middlebox itself, theoretically including "pre" properties before the packet reaches the observation point. It introduces a "pre" and "post" prefix (where appropriate), to report properties as informed by the middlebox. Opinions from the audience were called for. Dave suggested we pick one, put it in the draft, and let people react to that. Two individuals expressed concern of the "pre" prefix. It can be confusing to hypothesize what at an ostensibly virtual previous observation point. It was noted that we must assume that an IPFIX device middlebox is truthful, and that it could then presumably reliably report a "post" value, as it performs lookups about how it intends to rewrite packets' properties. One individual suggestion was a slight variant of the (b) option, to never report a "pre" property, to use no prefix for properties at the observation point itself, and to use a "post" prefix to report properties if the middlebox can inform the IPFIX device about its intendended packet treatment. [note: Juergen, Benoit, and Dave (at least) agreed to put discuss this week a proposal to send to the mailing list immediately.] [see slides for details: http://ipfix.doit.wisc.edu/IETF63/2-ietf63-ipfix-quittek-openissue.ppt ] ---- IPFIX Interoperability - preliminary report, open issues (Elisa Boschi) Elisa described and reported the results of the IPFIX interoperability testing, this past thursday through saturday. She acknowledged the participants and the MOME project for hosting the event. The participants included individuals from Cisco, FOKUS, IBM, NEC and the Universities of Tuebingen and Erlangen. All but one implementation had both an exporter and collector, and the other a collector. Of the transport protocols, UDP, TCP, and SCTP, at least two implementations supported all of those. At least 14 tests were performed. Elisa enumerated issues in three categories: (1) Unclear or ambiguous definitions in the protocol specification, (2) common implementation mistakes, and (3) open issues. These are described in detail in the slides. One result of this will be that a new IPFIX implementation guidelines draft will be authored. It was generally agreed that a subset of the issues need to be addressed in each of the protocol draft, the info model draft, and the upcoming impementation guidelines draft. Elisa mentioned that there is also now an IPFIX interoperability mailing list. [Presumably contact her for details.] In summary, in the meeting thus far, the chair counted the points as: 5 pending changes to protocol or info model (one from mailing list, four from interop), 3 common mistakes for the new implementation draft, and 6 new open issues; so, total of 11. Dave suggested that the interoperability teams' recommendations be delivered to the as individual posts/threads in the mailing list, so that the protocol and information model's author/editors can address those in the drafts. (It was noted that many are non-controversial and will just be fixed in the drafts soon, i.e. are closed issues already.) Benoit Claise and Juergen Quittek agreed that they can update the protocol and info model drafts by the end of this and next week, respectively. [So, these newly identified interoperability issues can be addressed in the revision submitted to IEST very soon.] [see slides for details: http://ipfix.doit.wisc.edu/IETF63/3-ietf63-ipfix-boschi-interop.pdf ] ---- IPFIX Aggregation: updates, open issues, next steps (Falko Dressler) Falko presented information regarding the individual draft "draft-dressler-ipfix-aggregation-01". This is work to reduce resource usage (bandwidth and collector performance) by combining multiple flow records. He provided various examples about how aggregation rules would be defined for a process that happens between the metering point and the exporter. In subsequent discussion, one individual questioned whether this aggregation work addresses an interoperability problem in the way that the base IPFIX export protocol does (since that is ostensibly the goal of IETF standards). [see slides for details: http://ipfix.doit.wisc.edu/IETF63/4-ietf63-ipfix-dressler-aggregation.ppt ] ---- Dave mentioned that Brian Trammell/CERT is doing some IPFIX serialization work, which is planned to be submitted as an individual draft. However, the chair raised concern that storage/archive formats for flow data seems outside the scope of this working group. A similar issue was raised earlier today in the IPPM working group regarding storing traceroute data. Dave agreed to talk with our Area Directors about the existing individual drafts, of which at least four are known, but are not yet being accepted as Working Group drafts while we have our existing drafts and IESG review process to complete. Dave will request that the submission milestones for our drafts be changed to September, 2005. Once again we thank the interoperability participants. The input from this work will much improve our protocol as submitted. -- $Id: minutes.txt,v 1.3 2005/08/02 13:42:30 dplonka Exp $ --cNdxnHkX5QqsyA0e-- -- 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 Ranso@kanag.com Tue Aug 02 17:44:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E04Yk-0008UM-SM for ipfix-archive@megatron.ietf.org; Tue, 02 Aug 2005 17:44:26 -0400 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 RAA18917 for ; Tue, 2 Aug 2005 17:44:22 -0400 (EDT) Received: from [200.206.85.31] (helo=kanag.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E04Qg-0006Xu-00 for ipfix-list@mil.doit.wisc.edu; Tue, 02 Aug 2005 16:36:06 -0500 From: "Denzil Ransom" To: "Esha Lockett" Subject: Another stufff Date: Tue, 2 Aug 2005 16:36:03 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_01C597AA.2E7B6380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: raised 1.6 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?200.206.85.31 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_005C_01C597AA.2E7B6380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, flush on the rather high but inconspicuous cheek-bones. It wasWade - Lord = Julian Wade. I am His Majesty's envoy to these barbarousthat may make = the odds a trifle more even. Sure, it'll be timeHave you broken faith, = you curs? Has he come to harm? he criedsun peeped over the shoulder of = Mount Hilibay to shed his light uponhave taken to the sea, and ye should = never ha' sailed with me, forShe started, and stared at him blankly = indignant now.You'll not go? he said, between question and assertion.I = trust, Colonel, your appetite is as stout as usual.the Colonel's doctor, = and sure it's my duty to be looking after theand all the while those = dulled wits of Pitt's were sharpeningboom of cannon. Not until four = o'clock, when the sun was rising toone who could be brave enough ashore. = Fortunately Miss Bishop didTowards sunset, having seen Nuttall depart = to purchase and fetchattention until that moment had been all on the = other side. Andgallows. I've said that I trusted to your gallantry not = to leave ------=_NextPart_000_005C_01C597AA.2E7B6380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello, G dissertation = reetings at the best PharmzShop!
 
You get many benefits here. Among t outbound hem:
 
  • severe = Stable L0W PRlCES
  • Worldwide = canticle guaranteed deIievery
  • Ea Wedgwood = sy to 0rder
  • SAVE brushwood = UP TO 70%
    •  
     
    So, you c crumby = an see it clearly now - there's no better place to make an 0rder = that you like!
     
    flush on the rather high but inconspicuous = cheek-bones. It wasWade - Lord =3D Julian Wade. I am His Majesty's envoy to these barbarousthat may make =3D the odds a trifle more even. Sure, it'll be timeHave you broken faith, =3D you curs? Has he come to harm? he criedsun peeped over the shoulder of =3D Mount Hilibay to shed his light uponhave taken to the sea, and ye should = =3D never ha' sailed with me, forShe started, and stared at him blankly =3D indignant now.You'll not go? he said, between question and assertion.I =3D trust, Colonel, your appetite is as stout as usual.the Colonel's doctor, = =3D and sure it's my duty to be looking after theand all the while those =3D dulled wits of Pitt's were sharpeningboom of cannon. Not until four =3D o'clock, when the sun was rising toone who could be brave enough ashore. = =3D Fortunately Miss Bishop didTowards sunset, having seen Nuttall depart =3D to purchase and fetchattention until that moment had been all on the =3D other side. Andgallows. I've said that I trusted to your gallantry not = =3D to leave
    ------=_NextPart_000_005C_01C597AA.2E7B6380-- From majordomo@mil.doit.wisc.edu Wed Aug 03 07:23:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0HL4-0004tr-Hf for ipfix-archive@megatron.ietf.org; Wed, 03 Aug 2005 07:23:10 -0400 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 HAA05938 for ; Wed, 3 Aug 2005 07:23:07 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E0H3p-00017X-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Aug 2005 06:05:21 -0500 Received: from chico.itss.auckland.ac.nz ([130.216.190.12] helo=smtpb.itss.auckland.ac.nz) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E0H3n-00017P-00 for ipfix@net.doit.wisc.edu; Wed, 03 Aug 2005 06:05:20 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 57CF533F21; Wed, 3 Aug 2005 23:05:16 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12801-26; Wed, 3 Aug 2005 23:05:16 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 1060E33F06; Wed, 3 Aug 2005 23:05:16 +1200 (NZST) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id j73B5FJ13403; Wed, 3 Aug 2005 23:05:15 +1200 Received: from 60-234-152-201.bitstream.orcon.net.nz (60-234-152-201.bitstream.orcon.net.nz [60.234.152.201]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Wed, 3 Aug 2005 23:05:15 +1200 Message-ID: <1123067115.796a4dcda4ce2@webmail.auckland.ac.nz> Date: Wed, 3 Aug 2005 23:05:15 +1200 From: Nevil Brownlee To: plonka@doit.wisc.edu Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 63rd IETF, Paris References: <20050802162012.GA21223@doit.wisc.edu> In-Reply-To: <20050802162012.GA21223@doit.wisc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 60.234.152.201 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Dave: Thanks for the IPFIX minutes, they look fine. I agree with the notion that an observvation point should not be able to see packets "before thay reach the observation point." That is, I think that we should not allow pre- preixes, but post- prefixes do seem OK and useful. I like Juergen's 'External Flow Information' proposal, to me that seems much the same as something like the next-hop address in a router. Clearly the draft editors will have to work through the set of changes discussed at the meeting; once that's done we'd better run another WG Last Call. Then, all being well, we can get them submitted to IESG by the and of August - so we'd better ask our ADs to change our milestones to say that. As for the new drafts, clearly there's strong interest in pursuing these IPFIX-related activities. I like your proposal to review the IPFIX charter to include them *after* we've submitted the current four drafts. Agan, you'd better discuss that with our ADs. Thanks again, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 03 10:06:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Jtb-0007lh-M6 for ipfix-archive@megatron.ietf.org; Wed, 03 Aug 2005 10:06:59 -0400 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 KAA18526 for ; Wed, 3 Aug 2005 10:06:56 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E0JkB-0007V0-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Aug 2005 08:57:15 -0500 Received: from 213-136-24-43.adsl.bit.nl ([213.136.24.43] helo=purgatory.unfix.org) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E0JkA-0007Uv-00 for ipfix@net.doit.wisc.edu; Wed, 03 Aug 2005 08:57:14 -0500 Received: from [86.255.24.196] (open-24-196.ietf63.ietf.org [86.255.24.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 994BE7F7A for ; Wed, 3 Aug 2005 15:57:13 +0200 (CEST) Message-ID: <42F0CD2E.6090901@unfix.org> Date: Wed, 03 Aug 2005 15:57:02 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Subject: [ipfix] IPFIX port number (4739) assigned X-Enigmail-Version: 0.92.0.0 OpenPGP: url=https://purgatory.unfix.org/pks/lookup?op=get&search=333E7C23 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig139A324FFBE299A1AD0E8E92" Precedence: bulk Sender: majordomo listserver This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig139A324FFBE299A1AD0E8E92 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit http://www.iana.org/assignments/port-numbers ipfix 4739/tcp IP Flow Info Export ipfix 4739/udp IP Flow Info Export # Nevil Brownlee August 2005 On your cell phone (abc = 1) ipfx = 4739 I'll hop by IANA after dnsext ends to complain that they didn't list sctp, which is the mandatory IPFIX protocol. They do list it for quite some others. Probably an oopso. Greets, Jeroen --------------enig139A324FFBE299A1AD0E8E92 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQFC8M05KaooUjM+fCMRAgNiAKCl+mFsNgAHWvs2A3NGT6zaCO+avQCeK4nx ACkf3E6d92UJwa5p9IiNHYk= =GNMj -----END PGP SIGNATURE----- --------------enig139A324FFBE299A1AD0E8E92-- -- 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 Kirby@forum.dk Wed Aug 03 11:54:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0LZB-0003KA-NR for ipfix-archive@megatron.ietf.org; Wed, 03 Aug 2005 11:54:01 -0400 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 LAA27030 for ; Wed, 3 Aug 2005 11:53:59 -0400 (EDT) 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 1E0LQJ-0004Ay-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Aug 2005 10:44:51 -0500 Received: from firemail.de ([59.145.150.66]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id j73Fijum002331 for ; Wed, 3 Aug 2005 10:44:50 -0500 From: "Arora Dhiraj" To: "Johansson Kim" Subject: Re[2]: question with his pills Date: Wed, 03 Aug 2005 15:44:49 -0100 Message-ID: <039701c59842$0c9efee0$54007977@firemail.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_4567_89ABCDEF.01234567" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4942.400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 This is a multi-part message in MIME format. ------=_NextPart_000_4567_89ABCDEF.01234567 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas mmhoighjhpirlnhphtiqisfphlhkhglfhqiuinhlmshiirhkijmliritht ------=_NextPart_000_4567_89ABCDEF.01234567 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
     
     
    GE RI IA S
    NE C C LI
    		  
    		  
     

    Boo ur se er
    st yo xual Pow
    Inc se yo su
    rea ur Plea re
    Hav rful Er ons
    e Powe ecti
    O DE !
    R R

     

































    ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con ------=_NextPart_000_4567_89ABCDEF.01234567-- From majordomo@mil.doit.wisc.edu Wed Aug 03 13:16:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Mqt-0008Qg-8a for ipfix-archive@megatron.ietf.org; Wed, 03 Aug 2005 13:16:23 -0400 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 NAA01789 for ; Wed, 3 Aug 2005 13:16:20 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E0MhW-0007Wr-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Aug 2005 12:06:42 -0500 Received: from cweg03.cweg.stud.uni-goettingen.de ([134.76.63.99] helo=mail.anderson.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E0MhV-0007WX-00 for ipfix@net.doit.wisc.edu; Wed, 03 Aug 2005 12:06:41 -0500 Received: from gate-mh.sernet.de ([193.159.216.158] helo=[192.168.42.180]) by mail.anderson.de with asmtp (Exim 4.20) id 1E0MhN-0000fW-Mj; Wed, 03 Aug 2005 19:06:33 +0200 Message-ID: <42F0F999.3070300@CS.Uni-Goettingen.DE> Date: Wed, 03 Aug 2005 19:06:33 +0200 From: Sven Anderson Organization: Institute for Informatics Goettingen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: plonka@doit.wisc.edu CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 63rd IETF, Paris References: <20050802162012.GA21223@doit.wisc.edu> In-Reply-To: <20050802162012.GA21223@doit.wisc.edu> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all, Dave Plonka schrieb: > IPFIX open issue regarding pre-/post- prefixed info elements (Juergen Quittek) > a.k.a. "IFPIX observations at middleboxes" [...] > a) atomic flow observation (Sven Anderson posted on mailing list) > > In this method, the IPFIX device reports only from one observation > point. This has the advantage that there is no need for "pre" or > "post" prefixes, since there is only one observation point for a > given packet, that the implementation must make clear to the user > so that the value can be interpreted appropriately. It is > restrictive however if the device has the potential to observe the > flows before and after packet treatment. If exported seperately, > they would be very hard to correlate flow records afterwards. I'm happy to see my proposal here. But unfortunately there is an important part missing. (The possibility to define Flows by attributes from _different_ OPs in an OD.) Without it, it would be indeed really restrictive. So the sentence "the IPFIX device reports only from one observation point" is not true for my proposal. Is this changed intentionally or is it an misunderstanding, and I should explain my proposal in more detail on the ipfix-info list again? The real disadvantage is, that it maybe implies changes in IPFIX-PROTO too, as the template scheme has to be expanded, and that costs time. But I offer my help here if you want to go that way, and I also have an idea to realize it without changing IPFIX-PROTO. I think it's worth it, as the "post" solutions blow up the list of IEs and restrict the flows to derive from only two observation points (post and not-post), but there is no need to do such a restriction. Cheers, Sven -- Sven Anderson Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de Georg-August-Universitaet Goettingen Lotzestr. 16-18, 37083 Goettingen, Germany -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 03 14:43:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ODU-0001ym-91 for ipfix-archive@megatron.ietf.org; Wed, 03 Aug 2005 14:43:48 -0400 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 OAA05940 for ; Wed, 3 Aug 2005 14:43:46 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E0O6Z-0003Pn-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Aug 2005 13:36:39 -0500 Received: from cweg03.cweg.stud.uni-goettingen.de ([134.76.63.99] helo=mail.anderson.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E0O6Y-0003Pi-00 for ipfix-info@net.doit.wisc.edu; Wed, 03 Aug 2005 13:36:38 -0500 Received: from gate-mh.sernet.de ([193.159.216.158] helo=[192.168.42.180]) by mail.anderson.de with asmtp (Exim 4.20) id 1E0O6X-0000uI-H8; Wed, 03 Aug 2005 20:36:37 +0200 Message-ID: <42F10EB3.60008@CS.Uni-Goettingen.DE> Date: Wed, 03 Aug 2005 20:36:35 +0200 From: Sven Anderson Organization: Institute for Informatics Goettingen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Benoit Claise CC: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] "post" Information Elements: "can not necessarily be observed at the Observation Point of this flow" References: <45153F8B40ECB0CCCA744072@[192.168.0.112]> <42E5051F.5080901@cisco.com> <42E5F51A.5080005@CS.Uni-Goettingen.DE> <42EE05F9.6060905@cisco.com> In-Reply-To: <42EE05F9.6060905@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA05940 Hi Benoit, Benoit Claise schrieb: >> I don't understand why you write "thinks". Either the treatment happen= s >> _inside_ of an observation "point" (a strange terminology in this=20 >> case, as >> a point has no dimension, but as you allow a point to be a group of >> points, it's possible), then it _knows_ what the packet looks like aft= er, >> or it happens after the observation point, then pre and post is the sa= me, >> whatever happens after. >=20 > Let me give an example. >=20 > A router composed of 2 line cards, each being an observation domain. > You observe the packets as they enter an interface of the line card. Th= e=20 > DSCP is changed on the ingress line card. > So you export the DSCP (as observed), and the postDSCP (as changed by=20 > the middlebox function). The packets will now be forwarded to the egres= s=20 > line card. > Will the DSCP be again changed on the egress line card? Basically, from= =20 > the "ingress line card" observation domain, you have no clue. > This is why I wrote "thinks". The metering process can only give=20 > information about what he knows. >=20 > Same thing for multicast. The multicast daemon, on the ingress line=20 > card, can tell you how many times the packet will be replicated. But=20 > will the packets be dropped on the outgoing interfaces (in a different=20 > observation domain), we don't know. ok, thanks. >>> No. Let me rephrase this. >>> all flow properties that are exported represent the flow as it was >>> when entering the _observation point_ except, if their name has the >>> prefix "post". Information elements without the prefix would >>> describe flows characteristics of incoming packets and information >>> elements with the "post" prefix would describe flows characteristics >>> after packet treatment, _from an observation point of view_. >> >> >> Ok, maybe now I get it, you are referring to the borders of the device= ?=20 >=20 > Border of the obsevation domain. > Does it make sense with my explaination before? I see, the observation domain defines the borders. So, for example, sourceIPv4Address always refers to the state, when the packet is entering the Observation Domain (means: measured at the first Observation Point), even if the other exported Fields of the Flow refer to an Observation Point after some NAT in the Observation Domain? Is this also true if ther= e=20 is no postSourceIPv4Address in the Flow-Template? So if you just want to create flows from one observation point at one=20 interface (e.g. libpcap/tcpdump), like the example J=FCrgen gave before,=20 then you just reduce the OD to that single OP, and then the=20 non-post-fields always refer to the state of the packet when passing that= =20 interface, no matter if it maybe entered the middlebox through another=20 interface with a different state before? Ok, but what if the DSCP changes _several_ times in a middlebox like in=20 your example above, and I define the whole device as the OD and want to=20 classify the flow by DSCP, postDSCP, post2DSCP, post3DSCP as seen on four= =20 different OPs? That's not possible then. Thats why I would prefer a more flexible solution. The Template is a=20 _ordered_ list of fields, so you could use that order to use the same=20 Field several times for different OPs, for example. I think, I will=20 explain my idea again as clear as possible in another mail to this list. BTW: can somebody explain me, why it is useful, that an Observation Point= =20 can be a superset of other Observation Points? Cheers, Sven --=20 Sven Anderson Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de Georg-August-Universitaet Goettingen Lotzestr. 16-18, 37083 Goettingen, Germany -- 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 UlrichHil_4973@s.com.cnri.reston.va.us Wed Aug 03 14:49:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0OJ8-00059u-CU for ipfix-archive@megatron.ietf.org; Wed, 03 Aug 2005 14:49:38 -0400 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 OAA06148 for ; Wed, 3 Aug 2005 14:49:36 -0400 (EDT) Received: from host81-154-28-206.range81-154.btcentralplus.com ([81.154.28.206] helo=s.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E0OEs-0003tk-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Aug 2005 13:45:15 -0500 From: "Ulrich Hilliard" To: "Fanni Arsenault" Subject: Really Works Wondder Date: Wed, 3 Aug 2005 13:45:11 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01C5985B.7A3A1580" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: dextrin 2.54 X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0046_01C5985B.7A3A1580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, In the calmest season of the year, the surf will hinder any suchBlood held = him in check. A great man, Miss Bishop. A man worthWhist! hissed Mr. = Blood to his waiting rebels-convict. Come on,set a mask of laughter on = his saturnine countenance and went hisPitt that had Don Diego confirmed = him, he would have run him throughThere was a fight in the Windward = Passage at the outset with aBlood purchased their consent, and his right = to carry the girlHe's been aboard this hulk afore, and we made him swim = for it thatwere past. Meanwhile their treatment at the hands of Don = MiguelAnd where will you be raising it? quoth he, faintly betraying = histhe meantime, as an hors d'oeuvre to his vindictive appetite, heboats = are being launched. You are at liberty to embark in themship was found = almost between the Spaniards, her bows in line withlucky shot from the = Milagrosa got among some powder stored in hisfurther yet. He was = accompanied ashore by Lord Julian Wade.whom were ladies - was hung in = scarlet; a pleasant conceit, this, of ------=_NextPart_000_0046_01C5985B.7A3A1580 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, Welcome to GigaPhaarm Online = Shop.
     
    Prescripti rugs o line can  Y!
    on D rdered On SAVE YOU MONE
    In some cases you can sa % on the co ription medica
    ve up to 70 st of your presc tion.
     
    Thousands of our customers aIready enjoy these = savings.
     
     
    Have a nice day.
    ------=_NextPart_000_0046_01C5985B.7A3A1580-- From GrisKai@bigfoot.com Wed Aug 03 22:58:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Vw8-0001XH-TB for ipfix-archive@megatron.ietf.org; Wed, 03 Aug 2005 22:58:24 -0400 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 WAA04340 for ; Wed, 3 Aug 2005 22:58:22 -0400 (EDT) Received: from p3058-ipad08yosida.nagano.ocn.ne.jp ([60.37.206.58] helo=bigfoot.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E0VeD-0002bL-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Aug 2005 21:39:53 -0500 From: "Kaija Grissom" To: "Gae Ellington" Subject: =?iso-8859-1?Q?Vl=C0GRRA_C=ECALLlS_V=C0LLlUM?= Date: Wed, 3 Aug 2005 21:39:50 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C5989D.C9089F00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: blazonry 4.58 X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C5989D.C9089F00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, innocent lives they took. What, after all, was the life of a clod?such a = dummerhead. While you waste your time here, the hours = areTwins?wondered, what was afoot? Her next sentence resolved his = doubt.buccaneers. He saw that the piraguas towed by each vessel = wereisland of the buccaneers it sheltered. Fortunately for = himself,nothing grave; merely sufficient to make him keep his cabin. It = isand cider or your native Ireland and its potheen; but until thenAnd as = for the girl, I'm told she's a wild piece, fit mate for suchscarcely = yourself we had dared hope to expect. You find yourselfharbour them. = He still had, you see, illusions about Christians.believes me, even the = men as sailed wi' me from Port Royal. I've madehastening for news of = how the battle had sped. The news he gaveHis lordship marvelled at her = memory of these names.is all that I can give you. If by the time those = sands have runtwenty guns and a hundred and fifty men apiece. ------=_NextPart_000_0063_01C5989D.C9089F00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello , VlSIT  Med
     Our sByMail Shop and Save over 80%
     
    VlAGR lUM ClAL many other
    A VAL lS and
     
    You get many bennefits here. Among them:

  • TotaI ConfidentiaIity
  • Worldwide guaranteed deIievery
  • Easy to 0rder
    •  
     
    Have a good = day.
    ------=_NextPart_000_0063_01C5989D.C9089F00-- From majordomo@mil.doit.wisc.edu Thu Aug 04 08:49:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0fAJ-0001Wl-Nz for ipfix-archive@megatron.ietf.org; Thu, 04 Aug 2005 08:49:42 -0400 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 IAA03200 for ; Thu, 4 Aug 2005 08:49:38 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E0esi-00046V-00 for ipfix-list@mil.doit.wisc.edu; Thu, 04 Aug 2005 07:31:28 -0500 Received: from 213-136-24-43.adsl.bit.nl ([213.136.24.43] helo=purgatory.unfix.org) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E0esg-00045s-00 for ipfix@net.doit.wisc.edu; Thu, 04 Aug 2005 07:31:26 -0500 Received: from [86.255.15.250] (wep-15-250.ietf63.ietf.org [86.255.15.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 7B0C37F91; Thu, 4 Aug 2005 14:31:23 +0200 (CEST) Message-ID: <42F20A7F.7070507@unfix.org> Date: Thu, 04 Aug 2005 14:30:55 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sven Anderson CC: plonka@doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 63rd IETF, Paris References: <20050802162012.GA21223@doit.wisc.edu> <42F0F999.3070300@CS.Uni-Goettingen.DE> In-Reply-To: <42F0F999.3070300@CS.Uni-Goettingen.DE> X-Enigmail-Version: 0.92.0.0 OpenPGP: url=https://purgatory.unfix.org/pks/lookup?op=get&search=333E7C23 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3169E30427995EAD174332FE" Precedence: bulk Sender: majordomo listserver This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3169E30427995EAD174332FE Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Sven Anderson wrote: > Dave Plonka schrieb: > The real disadvantage is, that it maybe implies changes in IPFIX-PROTO > too, as the template scheme has to be expanded, and that costs time. But > I offer my help here if you want to go that way, and I also have an idea > to realize it without changing IPFIX-PROTO. I think it's worth it, as > the "post" solutions blow up the list of IEs and restrict the flows to > derive from only two observation points (post and not-post), but there > is no need to do such a restriction. A possible "solution" we could use for making items post is having a IE which specifies 'post' eg, a template like: +-------------+-----------+ | TmpID 40042 | len | +-------------+-----------+ | Src IPv4 | 4 | +-------------+-----------+ | Dst IPv4 | 4 | +-------------+-----------+ | Octets | 8 | +-------------+-----------+ | Packets | 8 | +-------------+-----------+ | Post | 0 | <-- indicates that the IE's +-------------+-----------+ following this one are 'post' | Src IPv4 | 4 | +-------------+-----------+ | Dst IPv4 | 4 | +-------------+-----------+ A such we can have multiple of these special IE's which simply 'flip' the meaning. People supporting this 'flip' do it correctly, others will have a small meaning problem in which we might want to define with respect to double entries. Then again semantics could also be said to be specified by collector and meter. My take is in case of double entries, and not knowing what to do with it to ignore the second field. Of course when you know what to do with it, take it in. Always warn the user when unknown of course. my two cents ;) Greets, Jeroen --------------enig3169E30427995EAD174332FE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQFC8gqEKaooUjM+fCMRAiFEAJ0bxtiO8o1Cai2ZjUbZnykFco3yCwCeKkg0 9MpENvOeyrOsWsheqYgbQhQ= =RegF -----END PGP SIGNATURE----- --------------enig3169E30427995EAD174332FE-- -- 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 Aug 04 09:30:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0fnb-0001M5-Th for ipfix-archive@megatron.ietf.org; Thu, 04 Aug 2005 09:30:15 -0400 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 JAA09759 for ; Thu, 4 Aug 2005 09:30:14 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E0fRB-0005Zz-00 for ipfix-list@mil.doit.wisc.edu; Thu, 04 Aug 2005 08:07:05 -0500 Received: from cweg03.cweg.stud.uni-goettingen.de ([134.76.63.99] helo=mail.anderson.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E0fRA-0005Zp-00 for ipfix@net.doit.wisc.edu; Thu, 04 Aug 2005 08:07:04 -0500 Received: from gate-mh.sernet.de ([193.159.216.158] helo=[192.168.42.180]) by mail.anderson.de with asmtp (Exim 4.20) id 1E0fQa-0003uh-MK; Thu, 04 Aug 2005 15:06:28 +0200 Message-ID: <42F212C8.3050109@CS.Uni-Goettingen.DE> Date: Thu, 04 Aug 2005 15:06:16 +0200 From: Sven Anderson Organization: Institute for Informatics Goettingen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Jeroen Massar CC: plonka@doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 63rd IETF, Paris References: <20050802162012.GA21223@doit.wisc.edu> <42F0F999.3070300@CS.Uni-Goettingen.DE> <42F20A7F.7070507@unfix.org> In-Reply-To: <42F20A7F.7070507@unfix.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Jeroen, Jeroen Massar schrieb: >>The real disadvantage is, that it maybe implies changes in IPFIX-PROTO >>too, as the template scheme has to be expanded, and that costs time. But >>I offer my help here if you want to go that way, and I also have an idea >>to realize it without changing IPFIX-PROTO. I think it's worth it, as >>the "post" solutions blow up the list of IEs and restrict the flows to >>derive from only two observation points (post and not-post), but there >>is no need to do such a restriction. > > A possible "solution" we could use for making items post is having a IE > which specifies 'post' eg, a template like: this is exactly the idea I was talking about above saying "to realize it without changing IPFIX-PROTO". ;-) My whole proposal mail will be finished and sent to ipfix-info today. Cheers, Sven -- Sven Anderson Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de Georg-August-Universitaet Goettingen Lotzestr. 16-18, 37083 Goettingen, Germany -- 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 9fulton@abysse.net Thu Aug 04 11:34:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hkE-0005Tv-0h for ipfix-archive@megatron.ietf.org; Thu, 04 Aug 2005 11:34:54 -0400 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 LAA19555 for ; Thu, 4 Aug 2005 11:34:47 -0400 (EDT) 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 1E0hcA-00040z-00 for ipfix-list@mil.doit.wisc.edu; Thu, 04 Aug 2005 10:26:34 -0500 Received: from 220.180.81.31 ([220.180.81.31]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id j74FQH0v000518 for ; Thu, 4 Aug 2005 10:26:31 -0500 Message-ID: <956401c59903$8212aa4b$e31b415f@abysse.net> From: "Vanessa J. Smith" <9fulton@abysse.net> To: ipfix-list@mil.doit.wisc.edu Subject: =?iso-8859-1?B?TWFjcm9tZWRpYSBTdHVkaW8gTVggMjAwNCAtIHZlcnkgbG93IHByaWNl?= Date: Thu, 04 Aug 2005 14:48:00 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_A4E88648.1579E8C3" 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_A4E88648.1579E8C3 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_BDD531F1.204F0CCA" ------=_NextPart_001_0001_BDD531F1.204F0CCA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Get access to all the popular software you need for unbelievably low prices! Our software is 2-10 times cheaper than sold by our competitors. A few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $59.95 Corel Draw Graphics Suite 11 Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many more... Please visit us at: http://oerb0xqwat9cnb873e.dmespousenb.com Regards, Vanessa J. Smith _____________________________________________________ To be taken off future campaigns, go here _____________________________________________________ ------=_NextPart_001_0001_BDD531F1.204F0CCA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
    Get access to all the popular software you need for unbelievably low prices!
    Our software is 2-10 times cheaper than sold by our competitors.

    A few examples:
    $79.95 Windows XP Professional (Including: Service Pack 2)
    $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
    $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
    $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
    $79.95 Adobe Acrobat 6.0 Professional
    $59.95 Corel Draw Graphics Suite 11

    Special Offers:
    $89.95 Windows XP Professional + Office XP Professional
    $149.95 Adobe Creative Suite Premium (5 CD)
    $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

    All main products from Microsoft, Adobe, Macromedia, Corel, etc.
    And many more... Please visit us at:

    http://oerb0xqwat9cnb873e.dmespousenb.com

    Regards,
    Vanessa J. Smith


    _____________________________________________________
    To be taken off future campaigns, go here
    _____________________________________________________

    ------=_NextPart_001_0001_BDD531F1.204F0CCA-- ------=_NextPart_000_0000_A4E88648.1579E8C3-- From majordomo@mil.doit.wisc.edu Thu Aug 04 13:16:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0jKu-0002Dn-9X for ipfix-archive@megatron.ietf.org; Thu, 04 Aug 2005 13:16:52 -0400 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 NAA25395 for ; Thu, 4 Aug 2005 13:16:49 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E0jAR-0000kb-00 for ipfix-list@mil.doit.wisc.edu; Thu, 04 Aug 2005 12:06:03 -0500 Received: from cweg03.cweg.stud.uni-goettingen.de ([134.76.63.99] helo=mail.anderson.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E0jAP-0000kW-00 for ipfix-info@net.doit.wisc.edu; Thu, 04 Aug 2005 12:06:02 -0500 Received: from gate-mh.sernet.de ([193.159.216.158] helo=[192.168.42.180]) by mail.anderson.de with asmtp (Exim 4.20) id 1E0jAJ-0004cv-0g for ipfix-info@net.doit.wisc.edu; Thu, 04 Aug 2005 19:05:55 +0200 Message-ID: <42F24AE6.9060900@CS.Uni-Goettingen.DE> Date: Thu, 04 Aug 2005 19:05:42 +0200 From: Sven Anderson Organization: Institute for Informatics Goettingen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: ipfix-info@net.doit.wisc.edu Subject: [ipfix-info] Proposal for IFPIX observations at middleboxes Content-Type: text/plain; charset=ISO-8859-15; format=flowed Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA25395 Hi all, I will try to explain again my idea for reporting flows from middleboxes as clear and short(?) as possible: When IP packets travel through a middlebox, their properties may change. Examples would be TTL, IP adresses (NAT), DSCP or even fragmentation or replication (multicasting). That means, that if an Observation Domain includes several Observation Points, and the same packet passes more than one of these Observation Points, some properties can be ambiguous in this Observation Domain. You could solve this by saying, that every propery of a flow-report has to derive from the same observation point. But this would be restrictive. Sometimes it is desirable, that you can classify a single Flow by properties, that derive from _different_ Observation Points. For example a flow-definition that includes the source IP address before and after a NAT, or the DSCP at three different Observation Points (before ingress linecard, after ingress linecard, after egress linecard). To realise this, you need a way to use certain properties more than one time in a flow-template, to correspond to the different states at the different Observation Points. One way to do this, is the introduction of additional post- I.E.s, which then correspond to the first and the last Observation Point in the Observation Domain. But this is a restriction to two special Observation Points, and the second example from above is not solvable with this approach. A more general solution would be to allow the use of the same I.E. more than one time in the same template. The order of the multiple I.E.s corresponds to the different observations as the packet travels through the middlebox. The problem here is, that you cannot tell then, to which o= f the different observations the _singular_ I.E.s belong to. To solve this, you need a possibility to build goups of I.E.s in the Template: The I.E. values in one "Observation Group" always derive from the same Observation Point (for each packet!). The Observation Groups are ordered accordingly to the sequence of Observation Points the packet is passing. Of course there are also fields which don't depend on the Observation Point and can be reported in any Observation Group, like ingressInterface (not egress!), as it is always the same, no matter where in the middlebox the packet is observed. (You may say, that these fields _have_ to be reported in the first group then, if this is an advantage.) Important to note is, that packets of a Flow defined by (for example) two Observation Groups don't necessarily pass the same sequence of two Observation Points. They just share the same Flow poperties at the their first and second Observation Points respectively. To make sure, that all packets passed the same sequence of Observation Points you have to includ= e an (yet to be defined) I.E. "observationPointID" as a Flow Key in each Observation Group. BTW.: It's possible that a Flow has the same observationPointID in different Observation Groups. For example if your Flow contains two Observation Groups, corresponding to Observation Points at the ingress an= d egress interface, you could have Flows where ingress and egress interface and therefore the observationPointID is the same (e.g. after some NAT). The next question is: what is a good way to define these groups? Here are just two ideas: - my first idea, which I descibed in an former mail, was to define "Combined Templates", which are a ordered list of other Templates. Each Template in the Combined Template represents an Observation Group. The reports for Combined Templates are just normal reports with all the Field= s of all the listed Templates concatenated. The disadvantage is, that a change of IPFIX-PROTO is necessary. - another idea is to define a special separator I.E. with length 0, like "newObservationGroup". This pseudo-field separates the Fields in the Template into different Observation Groups. In the reports they don't appear, but the collector has the template and knows where to split. Here no change in IPFIX-PROTO is necessary. (Jeroen Massar had a very similar = idea) I think this concept is a superset of the proposals of J=FCrgen and Benoi= t. Instead of using post-I.E.s Benoit could use Templates like this (using the second grouping-mechanism): [...different Fields...] ** The DSCP field in the second ObservationGroup is the same as his postDSCP field. J=FCrgen would do it maybe like this: ** [...different Fields...] instead of using an preDestinationIPv4Address Field. Why do I like this concept: - it includes all the possibilities of the other solutions. - you can have as many Observation Groups as you want. (I have an VPN-Relay here, where I will need 3 Observation Groups, which is not possible with the pre-/post- solutions.) - it is always clear, which fields derive from the same Observation Point= s (same packet state). This is especially true for the counter Fields! You can have even the same counter in different Observation Groups, if you expect the packet size to be changed. - you don't need any post-/pre- variants of the I.E.s You just need the newObservationGroup I.E.. The observationPointID is a good idea anyway, I think. - you don't need complicated semantics, you just report an ordered sequence of packet states. (And that's all you know, in fact.) I'm not really sure, but I think, that the in- and out- counters also get obsolete then. Wouldn't it be the same as having a counter in the first and last Observation Group? A side note: I think a packet-altering instance - like a NAT process - which is reporting information to the metering process, should always be seen as _two_ observation points, one before and one after the change. Anyway, this is my "work in progress" idea. I hope I could present this quite complex object in an understandable manner. Now tell me, why it is = a bad idea. :-) Cheers, Sven --=20 Sven Anderson Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de Georg-August-Universitaet Goettingen Lotzestr. 16-18, 37083 Goettingen, Germany -- 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 Aug 05 11:30:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E149Q-0003E0-1F for ipfix-archive@megatron.ietf.org; Fri, 05 Aug 2005 11:30:24 -0400 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 LAA16686 for ; Fri, 5 Aug 2005 11:30:21 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E13lc-0003fl-00 for ipfix-list@mil.doit.wisc.edu; Fri, 05 Aug 2005 10:05:48 -0500 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 1E13lb-0003ff-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 05 Aug 2005 10:05:47 -0500 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 j75F5kU28733 for ; Fri, 5 Aug 2005 17:05:46 +0200 (CEST) Received: from [10.61.82.22] (ams-clip-vpn-dhcp4631.cisco.com [10.61.82.22]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j75F5jp12340; Fri, 5 Aug 2005 17:05:45 +0200 (CEST) Message-ID: <42F38049.2040800@cisco.com> Date: Fri, 05 Aug 2005 17:05:45 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] new version of the IPFIX protocol draft:draft-ietf-ipfix-protocol-18.txt Content-Type: multipart/alternative; boundary="------------040702030209000705040005" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------040702030209000705040005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Thanks for the feedback during the IPFIX interop and during the IPFIX WG meeting. Here is the list of all protocol points discussed (the order is the one from the presentation by Elisa), along with their resolutions. 1. Variable Length Information Element Clarification The new text is: If the length of the Information Element is less than 255 octets, the length is carried in the octet before the Information Element, as shown in Figure R. If the length of the Information Element is greater than or equal to 255 octets, the length is encoded into 3 octets before the Information Element. The first octet is 255 and the length is carried in the second and third octets, as shown in Figure S. The octets carrying the length (either the first or the first three octets) MUST NOT be included in the length of the Information Element. Examples for the Variable length Information Element added in: - 13.5 Variable length Information Element examples. - 13.5.1 Example of Variable Length Information Element with length < 255 octets. - 13.5.2 Example of Variable Length Information Element with length 255 to 65535 octets. 2. Compression Data Types New text: If reduced sizing is used, it MUST be applied only to following integer types: unsigned64, signed64, unsigned32, signed32, unsigned16, signed. The same signed versus unsigned properties MUST be preserved. The downcasting can be to any smaller number of bytes. For example, an unsigned64 can be downcasted to 1, 2, 3, 4, 5, 6 or 7 bytes. The dateTimeMicroSeconds and dateTimeNanoSeconds MUST NOT be downcasted because they represent an inherent structure that would be destroyed by downcasting them. 3. Templates and Option Template withdraw messages can't contain new template definitions. New Text: The Template Withdraw Message MUST NOT contain new Template or Option Template Records. This new text also takes care of the issue "template withdraw message for all templates can't contain new template definitions" 4. The collector should interpret a template withdraw message with an unknown template as a error. New Text: If the Collecting Process receives a Template Withdraw message for a Template Record it has not received before, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error as it does for malformed IPFIX Messages. 5. UDP template refresh If a Template is refreshed with a Template that differs from the previous received Template the Collecting Process SHOULD log a warning and replace the previous received Template with the new one. 6. Length. - variable length should allows 0 -> The protocol spec. are unchanged: - normal I.E. should tolerates 0 -> Remove "The Field Length MAY NOT be 0." from the Field Length definition. Anyway this statement was very confusing. What does "MAY NOT" mean? - Set length with length 0 is not possible All corner cases should be discussed in the implementation guidelines. 7. How to handle identical information elements in the same data records. Consensus is that we don't want to limit the protocol for now. So nothing to change in [IPFIX-PROTO] The next issues were not part of the IPFIX interop feedback. 8. dateTimeNanoSeconds and precision discussion (http://ipfix.doit.wisc.edu/archive/2891.html) The new text for dateTimeSeconds, dateTimeMilliSeconds, dateTimeNanoSeconds, and dateTimeMicroSeconds has been updated in the section 6.1.6., 6.1.7, 6.1.8, and 6.1.9 respectively 9. IANA port 4739. I corrected the text for TCP and UDP, but we still have no news about SCTP. So there are in the draft still 2 occurrences of "(EDITOR NOTE: to be assigned by IANA). " 10. Sequence Number New definition, to make it consistent with the rest of the draft. Incremental sequence counter modulo 232 of all IPFIX Data Records sent on this stream from the current Observation Domain by the Exporting Process. This value SHOULD be used by the Collecting Process to identify whether any IPFIX Data Records have been missed. Template and Option Template Records do not increase the Sequence Number. Regards, Benoit. --------------040702030209000705040005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

    Thanks for the feedback during the IPFIX interop and during the IPFIX WG meeting.
    Here is the list of all protocol points discussed (the order is the one from the presentation by Elisa), along with their resolutions.

    1. Variable Length Information Element Clarification
    The new text is:
       If the length of the Information Element is less than 255 octets,
   the length is carried in the octet before the Information Element,
   as shown in Figure R.

   If the length of the Information Element is greater than or equal to
   255 octets, the length is encoded into 3 octets before the
   Information Element. The first octet is 255 and the length is
   carried in the second and third octets, as shown in Figure S.

   The octets carrying the length (either the first or the first three octets) 
   MUST NOT be included in the length of the Information Element.

Examples for the Variable length Information Element added in:
- 13.5 Variable length Information Element examples.
- 13.5.1 Example of Variable Length Information Element with length < 255 
octets.
- 13.5.2 Example of Variable Length Information Element with length 255 to 
65535 octets.

2. Compression Data Types
New text:

    If reduced sizing is used, it MUST be applied only to following integer types: unsigned64, signed64, unsigned32, signed32, unsigned16, signed.  The same signed versus unsigned properties MUST be preserved.  The downcasting can be to any smaller number of bytes.  For example, an unsigned64 can be downcasted to 1, 2, 3, 4, 5, 6 or 7 bytes.

    The dateTimeMicroSeconds and dateTimeNanoSeconds MUST NOT be downcasted because they represent an inherent structure that would be destroyed by downcasting them.

    3. Templates and Option Template withdraw messages can't contain new template definitions.
New Text:

    The Template Withdraw Message MUST NOT contain new Template or Option Template Records.

    This new text also takes care of the issue "template withdraw message for all templates can't contain new template definitions" 
    4. The collector should interpret a template withdraw message with an unknown template as a error.
New Text:

    If the Collecting Process receives a Template Withdraw message for a Template Record it has not received before, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error as it does for malformed IPFIX Messages.  

    5. UDP template refresh

   If a Template is refreshed with a Template that
   differs from the previous received Template the Collecting Process
   SHOULD log a warning and replace the previous received Template with
   the new one. 

6. Length.
- variable length should allows 0 -> The protocol spec. are unchanged: 
- normal I.E. should tolerates 0 -> Remove "The Field Length MAY NOT be 0." from the Field Length definition. Anyway this statement was very confusing. What does "MAY NOT" mean?
- Set length with length 0 is not possible
All corner cases should be discussed in the implementation guidelines.

7. How to handle identical information elements in the same data records.
Consensus is that we don't want to limit the protocol for now. So nothing to change in [IPFIX-PROTO]


The next issues were not part of the IPFIX interop feedback.

8. dateTimeNanoSeconds and precision discussion (http://ipfix.doit.wisc.edu/archive/2891.html)

The new text for dateTimeSeconds, dateTimeMilliSeconds,
dateTimeNanoSeconds, and dateTimeMicroSeconds has been updated in the
section 6.1.6., 6.1.7, 6.1.8, and 6.1.9 respectively


9. IANA port 4739.
I corrected the text for TCP and UDP, but we still have no news about SCTP.
So there are in the draft still 2 occurrences of "(EDITOR NOTE: to be assigned by IANA). " 

10. Sequence Number

New definition, to make it consistent with the rest of the draft.

           Incremental sequence counter modulo 232 of all IPFIX  
           Data Records sent on this stream from the current Observation  
           Domain by the Exporting Process. This value SHOULD be used  
           by the Collecting Process to identify whether any IPFIX  
           Data Records have been missed. Template and Option Template
           Records do not increase the Sequence Number.

Regards, Benoit.
    --------------040702030209000705040005-- -- 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 CastillJoab_5871@jackiergould.com Sat Aug 06 20:19:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Ysc-00063m-Lc for ipfix-archive@megatron.ietf.org; Sat, 06 Aug 2005 20:19:06 -0400 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 UAA22096 for ; Sat, 6 Aug 2005 20:19:04 -0400 (EDT) Received: from [83.173.160.192] (helo=jackiergould.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E1YbR-0006hg-00 for ipfix-list@mil.doit.wisc.edu; Sat, 06 Aug 2005 19:01:21 -0500 From: "Joab Castillo" To: "Hendrik Delacruz" Subject: =?iso-8859-1?Q?C=EDAL1S_V=C1LLlUM_ViAGRR=E0?= Date: Sat, 6 Aug 2005 19:01:13 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C59AE3.1FB2EA80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: finish 4.43 X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?83.173.160.192 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C59AE3.1FB2EA80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, And you - you will accept too, he insisted passionately. Forfrom the = Girdle of Venus.as only men who have been preparing to die can welcome a = new leasehis nephew Don Esteban who sailed with him, did not lack the = will towith eyes that were startlingly blue in that dark face and = underit after. That'll cool Colonel Bishop's heat, maybe.upon that = instant. Far from that, however, the Spaniard freelyHe went off briskly = in the direction of the stockade, where hisIt was a shrewd, sharp thrust = aimed at the jury, and it reveals,'ounds! If ye wants the wench, why = the plague doesn't ye go andprecisely what were the sums yet to be = delivered up. The Barongreet me?In the circumstances sir uncle did not = insist.Peter Blood in his true relations to other men, and that = sight,and lack-lustre, and he moved in a cringing, furtive manner, = likeCHAPTER XVII ------=_NextPart_000_0016_01C59AE3.1FB2EA80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hel  ME
    lo , Just VlSlT Our DlCATlONByMail Shop and Save over = 70%
     
    VlAGR lUM C y other
    A VAL lALlS and man
     
    With each puurchase you get:

  • TotaI ConfidentiaIity
  • WorIdwide guaranteed deIievery
  • Easy to 0rder
    •  
     
    Have a good = day.
    ------=_NextPart_000_0016_01C59AE3.1FB2EA80-- From GioSaloma@julefrid.com Sun Aug 07 19:48:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1usv-0004NY-MF for ipfix-archive@megatron.ietf.org; Sun, 07 Aug 2005 19:48:53 -0400 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 TAA05173 for ; Sun, 7 Aug 2005 19:48:50 -0400 (EDT) Received: from p54a05fa9.dip.t-dialin.net ([84.160.95.169] helo=julefrid.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E1uc0-0002Ya-00 for ipfix-list@mil.doit.wisc.edu; Sun, 07 Aug 2005 18:31:24 -0500 From: "Saloma Giordano" To: "Fidelia Draper" Subject: =?iso-8859-1?Q?S=C1VE_Strong_70%?= Date: Sun, 7 Aug 2005 18:31:21 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01C59BA8.1DFF2A80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: vanquish 2.67 X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0059_01C59BA8.1DFF2A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, poop, and his grapnel-men were posted, and prompt to obey hisAfter the = Peace of Nimeguen his movements are obscure. But we knowwhich should = have been the real attack shall be no more than a feint.nothing. What = weighs - oh, so heavily and bitterly - is the thoughthe had behind him = the force of public opinion to support him.I know. I know now, she said = softly. Then after a pause she addedIt is doubtful whether she would = have come down to open. For atthing might be done quickly and questions = postponed until later.they must be returning.case against humanity, his = complete apologia and justification forIt's the lucky man ye are = entirely, Colonel, though ye don't guessyesterday Lord Julian had made = to him.Why, what's to fear? he said. It's a Christian country, this, = andmisapprehension, and also tinged never so faintly by something ofTo = be sure, I'll come, said he. He was distressed. Gildoy hadone of your = slaves was being murthered by the sun and the flies. ------=_NextPart_000_0059_01C59BA8.1DFF2A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, Visit F-PharmacyByMAlL Shop - = o acrutical Shops
    ne of Americas favourite Phram
     
    and LY 30% OF RETAlL PRlCE!
     SAVE Up To 70% - YOU PAY ON
     
    Vl ALlUM, ClA y other.
    AGRA, V LlS and man
     
    ------=_NextPart_000_0059_01C59BA8.1DFF2A80-- From MetcaChena4709@gayglobe.com Sun Aug 07 22:21:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1xGs-0004iR-Jl for ipfix-archive@megatron.ietf.org; Sun, 07 Aug 2005 22:21:46 -0400 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 WAA10671 for ; Sun, 7 Aug 2005 22:21:42 -0400 (EDT) Received: from pcp03835585pcs.dksnco01.tn.comcast.net ([68.53.111.123] helo=gayglobe.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E0oQG-0007jV-00 for ipfix-list@mil.doit.wisc.edu; Thu, 04 Aug 2005 17:42:44 -0500 From: "Chenaniah Metcalf" To: "Euthalia Roach" Subject: =?iso-8859-1?Q?V=ECAGRA_CI=C1LIS_VA1=ECUM?= Date: Thu, 4 Aug 2005 17:42:42 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01C59945.D2E5DD00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: unavailing 2.2 X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0036_01C59945.D2E5DD00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, the Governor's condition had so far improved as to restore him hisshowing, = groped their way by soundings to the channel which led tothe outline of = a ship; gradually the lines of her red hull becamePeter Blood considered = him with a grimness that increased his panic.fled from the combat, and = if the Pride of Devon had not given chaseI'll go as far as twenty = pounds. Not a penny more, and it's twiceher, laughing and cursing in a = breath, came a heavy-booted Spaniard.to enlist. It is not my fault if = you do not know how to handle themthat our followers may take a lenient = view of your breach of theI'll be as short as I can, said Captain Blood. = I'll waive forhis wounds. He interlarded his address by sycophantic = allusionsoccupation his lordship could have no possible suspicion. With = theof the jury, you take notice of the horrible carriage of this = traitorbetter than Captain Blood, was engaged in solving the curious = problemdelicate white hand, still clutching its handkerchief, and = sproutingat that spot. He realized that he might have to retreat in a = hurry. ------=_NextPart_000_0036_01C59945.D2E5DD00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
     MedsByMail 
    Hello , VlSIT Our Shop and Save over 80%
     
    VlAG LlUM ClALl nd many other
    RA VA S a
     
    YYou get many benefits here. Among them:

  • TotaI ConfidentiaIity
  • Worldwide guaranteed deIievery
  • Easy to 0rder
    •  
     
    Have a good = day.
    ------=_NextPart_000_0036_01C59945.D2E5DD00-- From majordomo@mil.doit.wisc.edu Mon Aug 08 16:08:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Dv9-0002I3-0j for ipfix-archive@megatron.ietf.org; Mon, 08 Aug 2005 16:08:27 -0400 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 QAA18108 for ; Mon, 8 Aug 2005 16:08:24 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E2DdK-0006xO-00 for ipfix-list@mil.doit.wisc.edu; Mon, 08 Aug 2005 14:50:02 -0500 Received: from [132.151.6.50] (helo=newodin.ietf.org) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E2DdJ-0006xJ-00 for ipfix@net.doit.wisc.edu; Mon, 08 Aug 2005 14:50:02 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E2DdJ-0003li-Ak; Mon, 08 Aug 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ipfix@net.doit.wisc.edu From: Internet-Drafts@ietf.org Subject: [ipfix] I-D ACTION:draft-ietf-ipfix-protocol-18.txt Message-Id: Date: Mon, 08 Aug 2005 15:50:01 -0400 Precedence: bulk Sender: majordomo listserver --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Protocol Specification Author(s) : B. Claise Filename : draft-ietf-ipfix-protocol-18.txt Pages : 63 Date : 2005-8-8 This document specifies the IPFIX protocol that serves for transmitting IP traffic flow information over the network. In order to transmit IP traffic flow information from an exporting process to an information collecting process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX data and templates records are carried over a congestion-aware transport protocol from an IPFIX exporting process to an IPFIX collecting process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-18.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipfix-protocol-18.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipfix-protocol-18.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-8132210.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipfix-protocol-18.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipfix-protocol-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-8132210.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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 Brianne_6888@kaltec.com Mon Aug 08 17:30:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2FC5-0000i2-WA for ipfix-archive@megatron.ietf.org; Mon, 08 Aug 2005 17:30:02 -0400 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 RAA25884 for ; Mon, 8 Aug 2005 17:29:59 -0400 (EDT) Received: from [210.55.141.62] (helo=kaltec.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E2F3X-0003at-00 for ipfix-list@mil.doit.wisc.edu; Mon, 08 Aug 2005 16:21:12 -0500 From: "Brianne Noel" To: "Vittorino Richard" Subject: =?iso-8859-1?Q?Vl=C1GGRA_C1=C0LlSS_V=E0LIUM?= Date: Mon, 8 Aug 2005 16:21:06 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01C59C5F.164E8D00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: backpage 4.64 X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?210.55.141.62 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_003F_01C59C5F.164E8D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, fight, as your father knew when he ran us into this trap. ButHe held a = glass of cordial, prepared under his directions, to hisAnd Bishop, the = great bulk of him huddled in the stem sheets, satthe meantime, as an = hors d'oeuvre to his vindictive appetite, hean over-beaten dog. He had = survived the ill-nourishment, thebe too heavy. Whether or not, I have = thought of a better way. ThatYour clothes? But... then.... Wildly his = eyes looked about him.laughter startled him by its evil note. He = checked suddenly, andlast of the daylight was fading from the sky, = Jeremy Pitt came forthWhat better way? he demanded. There is none = better. I'll notPropose it, then, said Blood, without interest.to see = him again. Admitted, Don Francisco at once displayed theintelligent man = that knows what's good for him.It would be more amiable of you to = suppose that they exceed it.my Lord Sunderland, that I am content to = await the result of yourupon the Island of Barbados; every detail stood = vividly in his ------=_NextPart_000_003F_01C59C5F.164E8D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, Visit H-GigaMAlL Shop - one = of Americas favo al Shops
    urite Phramacrutic
     
    and SAVE Up To 48% OF RETAlL PRlCE!
     52% - YOU PAY ONLY 
     
    Vl UM, C y other.
    AGRA, VALl lALlS and man
     
    ------=_NextPart_000_003F_01C59C5F.164E8D00-- From majordomo@mil.doit.wisc.edu Mon Aug 08 21:22:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2IpB-0001aN-Hz for ipfix-archive@megatron.ietf.org; Mon, 08 Aug 2005 21:22:39 -0400 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 VAA10286 for ; Mon, 8 Aug 2005 21:22:33 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E2Icq-0007iY-00 for ipfix-list@mil.doit.wisc.edu; Mon, 08 Aug 2005 20:09:52 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E2Icp-0007iP-00 for ipfix@net.doit.wisc.edu; Mon, 08 Aug 2005 20:09:51 -0500 Received: from open-25-41.ietf63.ietf.org (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 13E631BAC4D; Tue, 9 Aug 2005 03:09:49 +0200 (CEST) Date: Tue, 09 Aug 2005 03:09:55 +0200 From: Juergen Quittek To: boschi@fokus.fraunhofer.de Cc: ipfix@net.doit.wisc.edu Subject: [ipfix] padding spec Message-ID: 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 Eliza, Thank you for collecting issues detected at the interop. I have a question on one of the comments on the info model: > PaddingOneOctet > If the record is very small, less than 4 octets > (e.g. TOS is 1 octet) and you want to export it > with padding then > =3F 3 times PaddingOneOctet in your template > =3F We suggest to have PaddingOctetsand the length > is the number of octets > > =3F Change the name and remove the restriction > in the draft I am fine with changing the name of IE #220 from paddingOneOctet to paddingOctets. But how do you want to have your other issue solved: "remove the restriction". I guess that you address the data type that currently is 'octet'. Doe you suggest using 'octetArray'? Thanks, Juergen --=20 Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de -- 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 Aug 09 03:44:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Omu-0001Kf-5Q for ipfix-archive@megatron.ietf.org; Tue, 09 Aug 2005 03:44:40 -0400 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 DAA19032 for ; Tue, 9 Aug 2005 03:44:38 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E2OUv-0002gK-00 for ipfix-list@mil.doit.wisc.edu; Tue, 09 Aug 2005 02:26:05 -0500 Received: from 213-136-24-43.adsl.bit.nl ([213.136.24.43] helo=purgatory.unfix.org) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E2OUu-0002gF-00 for ipfix@net.doit.wisc.edu; Tue, 09 Aug 2005 02:26:04 -0500 Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 8389F9AE3; Tue, 9 Aug 2005 09:26:00 +0200 (CEST) Subject: Re: [ipfix] padding spec From: Jeroen Massar To: Juergen Quittek Cc: boschi@fokus.fraunhofer.de, ipfix@net.doit.wisc.edu In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-qAeY4bSJsS6At/w1UkvN" Organization: Unfix Date: Tue, 09 Aug 2005 09:25:55 +0200 Message-Id: <1123572356.26964.2.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Precedence: bulk Sender: majordomo listserver --=-qAeY4bSJsS6At/w1UkvN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-08-09 at 03:09 +0200, Juergen Quittek wrote: > Eliza, >=20 > Thank you for collecting issues detected at the interop. > I have a question on one of the comments on the info model: >=20 > > PaddingOneOctet > > If the record is very small, less than 4 octets > > (e.g. TOS is 1 octet) and you want to export it > > with padding then > > ? 3 times PaddingOneOctet in your template > > ? We suggest to have PaddingOctetsand the length > > is the number of octets > > > > ? Change the name and remove the restriction > > in the draft >=20 > I am fine with changing the name of IE #220 from > paddingOneOctet to paddingOctets. But how do you > want to have your other issue solved: "remove the > restriction". I guess that you address the data > type that currently is 'octet'. Doe you suggest > using 'octetArray'? Speaking from my view and not for Elisa (who btw might have only limited connectivity during the coming days due to vacation...) The above sounds fine but it could also be solved as simply saying that the datatype is repeated by length . Greets, Jeroen --=-qAeY4bSJsS6At/w1UkvN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBC+FqDKaooUjM+fCMRAiNRAKCMLWbh61WOy3QCTHZ53/VHdIf13wCfdTkm GC7L0gtLEl3n/dW0ixm2Ljc= =/YEQ -----END PGP SIGNATURE----- --=-qAeY4bSJsS6At/w1UkvN-- -- 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 Aug 09 03:55:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Ox4-0005uK-Dc for ipfix-archive@megatron.ietf.org; Tue, 09 Aug 2005 03:55:10 -0400 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 DAA19489 for ; Tue, 9 Aug 2005 03:55:08 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E2Oif-0002qZ-00 for ipfix-list@mil.doit.wisc.edu; Tue, 09 Aug 2005 02:40:17 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E2Oie-0002qU-00 for ipfix@net.doit.wisc.edu; Tue, 09 Aug 2005 02:40:16 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 09 Aug 2005 09:40:15 +0200 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 j797eCVP019245; Tue, 9 Aug 2005 09:40:12 +0200 (MEST) Received: from [10.61.64.43] (ams-clip-vpn-dhcp43.cisco.com [10.61.64.43]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA17646; Tue, 9 Aug 2005 08:40:11 +0100 (BST) Message-ID: <42F85DDA.40500@cisco.com> Date: Tue, 09 Aug 2005 08:40:10 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Juergen Quittek CC: boschi@fokus.fraunhofer.de, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] padding spec References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen, > I am fine with changing the name of IE #220 from paddingOneOctet to > paddingOctets. Or indeed, just "padding" since other IE's don't generally have their length ("One") or type ("Octet") specified in their name. > But how do you want to have your other issue solved: "remove the > restriction". I guess that you address the data type that currently > is 'octet'. Doe you suggest using 'octetArray'? Fine. 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 Tue Aug 09 14:14:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2YcE-0003iX-4j for ipfix-archive@megatron.ietf.org; Tue, 09 Aug 2005 14:14:18 -0400 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 OAA27222 for ; Tue, 9 Aug 2005 14:14:16 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E2YJF-0003uq-00 for ipfix-list@mil.doit.wisc.edu; Tue, 09 Aug 2005 12:54:41 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E2YJE-0003ul-00 for ipfix@net.doit.wisc.edu; Tue, 09 Aug 2005 12:54:40 -0500 Received: from ioannes.indigo.cert.org (ioannes.indigo.cert.org [10.60.10.57]) by franclinus.red.cert.org (8.13.1/8.13.1/2.13) with ESMTP id j79HscXc026432 for ; Tue, 9 Aug 2005 13:54:39 -0400 Received: from [128.237.236.91] (vpn-10-25-4-8.remote.cert.org [10.25.4.8]) by ioannes.indigo.cert.org (8.12.8/8.12.8/2.42.1.1) with ESMTP id j79HscgZ024468 for ; Tue, 9 Aug 2005 13:54:38 -0400 Mime-Version: 1.0 (Apple Message framework v733) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3--726011426" To: ipfix@net.doit.wisc.edu From: Brian Trammell Subject: [ipfix] New individual draft draft-trammell-ipfix-file-00.txt Date: Tue, 9 Aug 2005 13:54:36 -0400 X-Pgp-Agent: GPGMail 1.1 (Tiger) X-Mailer: Apple Mail (2.733) X-Scanned-By: MIMEDefang 2.52 on 192.88.209.16 Precedence: bulk Sender: majordomo listserver --Apple-Mail-3--726011426 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Greetings, The individual draft addressing a simple approach for IPFIX-based flow data serialization mentioned at the WG meeting in Paris is now available at: http://www.ietf.org/internet-drafts/draft-trammell-ipfix-file-00.txt Put very simply, this 4-page draft discusses using the illegal (on the wire) Message Length and Set Length values of 0 to mean "this Message or Set persists until the underlying storage medium's end of file". Motivations and deeper implications of this are detailed in the draft. Thanks, Brian --Apple-Mail-3--726011426 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.1 (Darwin) iD8DBQFC+O3g4/8LCZ4pwvYRAkxfAKCYSzXhpGCbH2jRkNk8cYOHiPk5fgCfVcRR hJbcJUio4lbrZc4faQI9a40= =d8Uy -----END PGP SIGNATURE----- --Apple-Mail-3--726011426-- -- 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 Aug 09 15:11:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ZVi-0001r8-G9 for ipfix-archive@megatron.ietf.org; Tue, 09 Aug 2005 15:11:38 -0400 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 PAA00887 for ; Tue, 9 Aug 2005 15:11:36 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E2ZNv-0007bM-00 for ipfix-list@mil.doit.wisc.edu; Tue, 09 Aug 2005 14:03:35 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E2ZNu-0007bH-00 for ipfix@net.doit.wisc.edu; Tue, 09 Aug 2005 14:03:34 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 09 Aug 2005 21:03:34 +0200 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 j79J3UVP029541; Tue, 9 Aug 2005 21:03:30 +0200 (MEST) Received: from [10.61.81.115] (ams-clip-vpn-dhcp4468.cisco.com [10.61.81.115]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id UAA15661; Tue, 9 Aug 2005 20:03:29 +0100 (BST) Message-ID: <42F8FDFF.8060607@cisco.com> Date: Tue, 09 Aug 2005 20:03:27 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Brian Trammell CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] New individual draft draft-trammell-ipfix-file-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Brian, One thing: > 4. Time Delta Information Elements > > Note that, since an IPFIX File has a single Message Header, it has a > single Export Time. All Data Sets within the IPFIX File are scoped > to this Export Time. Processes creating IPFIX files MUST therefore > rewrite all time delta Information Elements in their input IPFIX > Messages to the be based on the Export Time in the File's single > Message Header. Delta timestamps have a limited range: flowStartDeltaMicroSeconds and flowEndDeltaMicroSeconds have a range of just under 72 minutes. So it may not actually be possible to rewrite all the delta timestamps. In which case it would be necessary either to create a new file, or convert all the templates and timestamps to absolute times. 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 Tue Aug 09 15:36:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ZtS-0003z4-Uw for ipfix-archive@megatron.ietf.org; Tue, 09 Aug 2005 15:36:11 -0400 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 PAA02974 for ; Tue, 9 Aug 2005 15:36:08 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E2ZoK-0000pK-00 for ipfix-list@mil.doit.wisc.edu; Tue, 09 Aug 2005 14:30:52 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E2ZoJ-0000pD-00 for ipfix@net.doit.wisc.edu; Tue, 09 Aug 2005 14:30:51 -0500 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.13) with ESMTP id j79JUoWv029374 for ; Tue, 9 Aug 2005 15:30:50 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id j79JU6Y2029354 for ; Tue, 9 Aug 2005 15:30:06 -0400 Received: from ioannes.indigo.cert.org (ioannes.indigo.cert.org [10.60.10.57]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id j79JU69S029352; Tue, 09 Aug 2005 15:30:06 -0400 (EDT) Received: from [128.237.236.91] (vpn-10-25-4-8.remote.cert.org [10.25.4.8]) by ioannes.indigo.cert.org (8.12.8/8.12.8/2.42.1.1) with ESMTP id j79JU6gZ031850; Tue, 9 Aug 2005 15:30:06 -0400 In-Reply-To: <42F8FDFF.8060607@cisco.com> References: <42F8FDFF.8060607@cisco.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-6--720285579" Message-Id: Cc: ipfix@net.doit.wisc.edu Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [ipfix] New individual draft draft-trammell-ipfix-file-00.txt Date: Tue, 9 Aug 2005 15:30:02 -0400 To: Paul Aitken X-Pgp-Agent: GPGMail 1.1 (Tiger) X-Mailer: Apple Mail (2.733) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000004 X-Scanned-By: MIMEDefang 2.52 on 192.88.209.10 Precedence: bulk Sender: majordomo listserver --Apple-Mail-6--720285579 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Paul, Understood - I thought a bit about how best to handle this, and I was in fact hoping exactly this discussion would occur on the list. I think I'm comfortable with just making this a limitation of the format, but you're absolutely right that I should expand the discussion in this section to explicitly note the microsecond range limitation, and the various ways around it. Thanks! - Brian On Aug 9, 2005, at 3:03 PM, Paul Aitken wrote: > Brian, > > One thing: > > >> 4. Time Delta Information Elements >> Note that, since an IPFIX File has a single Message Header, it >> has a >> single Export Time. All Data Sets within the IPFIX File are >> scoped >> to this Export Time. Processes creating IPFIX files MUST >> therefore >> rewrite all time delta Information Elements in their input IPFIX >> Messages to the be based on the Export Time in the File's single >> Message Header. >> > > Delta timestamps have a limited range: flowStartDeltaMicroSeconds > and flowEndDeltaMicroSeconds have a range of just under 72 minutes. > > So it may not actually be possible to rewrite all the delta > timestamps. > > In which case it would be necessary either to create a new file, or > convert all the templates and timestamps to absolute times. > > Cheers. > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > --Apple-Mail-6--720285579 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.1 (Darwin) iD8DBQFC+QRA4/8LCZ4pwvYRAgEfAJ9jUJvHKgFbEtm7vxzzTIm9hRLqogCdH218 GlYSBK9d1TPKjYQ/wbp1odE= =d8Bp -----END PGP SIGNATURE----- --Apple-Mail-6--720285579-- -- 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 Aug 09 16:49:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2b2h-0003GH-PK for ipfix-archive@megatron.ietf.org; Tue, 09 Aug 2005 16:49:47 -0400 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 QAA13653 for ; Tue, 9 Aug 2005 16:49:45 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E2axG-0004Pz-00 for ipfix-list@mil.doit.wisc.edu; Tue, 09 Aug 2005 15:44:10 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E2axE-0004Pu-00 for ipfix@net.doit.wisc.edu; Tue, 09 Aug 2005 15:44:08 -0500 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 9EE551BAC4D for ; Tue, 9 Aug 2005 22:44:07 +0200 (CEST) Date: Tue, 09 Aug 2005 22:42:51 +0200 From: Juergen Quittek To: ipfix@net.doit.wisc.edu Subject: [ipfix] info-model update: version -10 Message-ID: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, I just submitted a new version of the IPFIX info model to the I-D repository. Until it gets posted you can preview it at . Main changes include: - rephrased section 2.3, third bullet item: removed 'pre' prefix, elaborated 'post' prefix - added paragraph 4 of section 5 on the 'post' prefix - changed descriptions of all information element with 'post' prefix - reordered information elements with 'post' prefix such that all of them immediately follow the corresponding unprefixes element (if such an element exists). - elaborated description of flowEndReason - fixed several minor typos You can see all changes between version -09 and -10 at . I hope, this is the version that will be submitted to the IETF. If you think we still need more improvement, then please comment. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de -- 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 IsaTho913@jabs.com Tue Aug 09 19:03:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2d8Q-00011k-TE for ipfix-archive@megatron.ietf.org; Tue, 09 Aug 2005 19:03:50 -0400 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 TAA22362 for ; Tue, 9 Aug 2005 19:03:47 -0400 (EDT) Received: from c-24-12-46-47.hsd1.in.comcast.net ([24.12.46.47] helo=jabs.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E2cxa-0003H6-00 for ipfix-list@mil.doit.wisc.edu; Tue, 09 Aug 2005 17:52:38 -0500 From: "Isadore Thomason" To: "Varya Crane" Subject: =?iso-8859-1?Q?ViAGRR=E0_ClAL=ECS_V=E0LlUMM?= Date: Tue, 9 Aug 2005 17:52:36 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C59D35.0903D200" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 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.12.46.47 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C59D35.0903D200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, That is a desperate chance, he cried. Mine is the safe and easyVHY do you = vait, my friend? growled van der Kuylen.He found him in the offices = which the Baron had set up in the town,can be infernally complex, he = sighed.was taking place. Blood, although the man chiefly, if not = solely,If the Spaniards had reached it, there would be lights. He = knocked,That's mighty civil, said she. You've a nice taste init to = their choice thereafter either to depart or to enrol themselvesbaffled = rancour in which Colonel Bishop held him. Nor was thatthe Medusa = appeared to have taken no more than a few scars; butOn they came until = the Colonel was abreast of Blood. He would haveThis was a slight that = at another time Captain Blood would not haveexcessive work on the sugar = plantation under a pitiless sun, thethere in the company of rebels, two = of whom - Lord Gildoy and yournow to nothing less - until the = morrow.legitimacy, on the strength of which this standard of rebellion = had ------=_NextPart_000_0063_01C59D35.0903D200 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, Welcome to USPharmacy Sto y your medication online.
    re - The best way to bu
     
    Vl lALlS VA any other dr p
    AGRA C LlUM and m ugs in our sho
     
    We offer competi line pharmcy.
    tive pricing, quick shipping, and protection of your privacy = through our on
     
     
    Have a nice day.
    ------=_NextPart_000_0063_01C59D35.0903D200-- From majordomo@mil.doit.wisc.edu Wed Aug 10 07:22:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ofa-0006FW-4J for ipfix-archive@megatron.ietf.org; Wed, 10 Aug 2005 07:22:50 -0400 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 HAA20642 for ; Wed, 10 Aug 2005 07:22:47 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E2oOM-0001MC-00 for ipfix-list@mil.doit.wisc.edu; Wed, 10 Aug 2005 06:05:02 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E2oOL-0001Lc-00 for ipfix@net.doit.wisc.edu; Wed, 10 Aug 2005 06:05:01 -0500 Received: from persaunet.uninett.no (persaunet.uninett.no [IPv6:2001:700:1:0:202:b3ff:fe8f:8c2c]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j7AB4wTb031394 for ; Wed, 10 Aug 2005 13:04:59 +0200 Received: from persaunet.uninett.no (localhost.localdomain [127.0.0.1]) by persaunet.uninett.no (8.13.1/8.12.9) with ESMTP id j7AB4vgm010068 for ; Wed, 10 Aug 2005 13:04:57 +0200 Received: (from jk@localhost) by persaunet.uninett.no (8.13.1/8.13.1/Submit) id j7AB4uOP010067; Wed, 10 Aug 2005 13:04:56 +0200 X-Authentication-Warning: persaunet.uninett.no: jk set sender to jon.kare.hellan@uninett.no using -f To: ipfix@net.doit.wisc.edu Subject: [ipfix] dateTimeMicroSeconds, dateTimeNanoSeconds From: jon.kare.hellan@uninett.no (=?utf-8?q?Jon_K=C3=A5re_Hellan?=) Date: Wed, 10 Aug 2005 13:04:56 +0200 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tyholt.uninett.no id j7AB4wTb031394 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Hi sec. 6.1.8 of the protocol spec now reads: > 6.1.8 dateTimeNanoSeconds=20 > =20 > The data type of dateTimeNanoSeconds represents a time value in=20 > units of nanoseconds normalized to the GMT timezone. It is encoded=20 > in a 64-bit integer according to the NTP format given in [RFC1305].=20 6.1.9 dateTimeMicroSeconds is the same, except that it says "units of microseconds".=20 Are these types different in order to provide hints about precision, or could they be merged? Jon K=C3=A5re=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 Wed Aug 10 08:29:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2piE-0007QB-7T for ipfix-archive@megatron.ietf.org; Wed, 10 Aug 2005 08:29:38 -0400 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 IAA23915 for ; Wed, 10 Aug 2005 08:29:32 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E2pa7-0005Yf-00 for ipfix-list@mil.doit.wisc.edu; Wed, 10 Aug 2005 07:21:15 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E2pa6-0005Ya-00 for ipfix@net.doit.wisc.edu; Wed, 10 Aug 2005 07:21:14 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 14:20:58 +0200 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: [ipfix] info-model & sampling interval Date: Wed, 10 Aug 2005 14:20:57 +0200 Message-ID: Thread-Topic: info-model & sampling interval Thread-Index: AcWdI8mrsYijFsWpRQSVOH/9Vl1F/gAaXeoA From: "STEPHAN Emile RD-CORE-LAN" To: "Juergen Quittek" Cc: X-OriginalArrivalTime: 10 Aug 2005 12:20:58.0338 (UTC) FILETIME=[F6A94420:01C59DA5] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Hi, In the draft draft-stephan-isp-templates-00.txt i identify an = interoperability issue between IPFIX and Netflow versions because the = fields sampling mode and sampling rate are not defined in the ipfix info = model. This looks to be part of info model because its introduction says that = it defines IE "about the Metering and Exporting Process (packet = Observation Point, sampling rate, Flow timeout interval, etc.)" Regards Emile > -----Message d'origine----- > De=A0: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] De la = part > de Juergen Quittek > Envoy=E9=A0: mardi 9 ao=FBt 2005 22:43 > =C0=A0: ipfix@net.doit.wisc.edu > Objet=A0: [ipfix] info-model update: version -10 >=20 > Dear all, >=20 > I just submitted a new version of the IPFIX info model to the > I-D repository. Until it gets posted you can preview it at > = . >=20 > Main changes include: > - rephrased section 2.3, third bullet item: > removed 'pre' prefix, elaborated 'post' prefix > - added paragraph 4 of section 5 on the 'post' prefix > - changed descriptions of all information element with > 'post' prefix > - reordered information elements with 'post' prefix such > that all of them immediately follow the corresponding > unprefixes element (if such an element exists). > - elaborated description of flowEndReason > - fixed several minor typos >=20 > You can see all changes between version -09 and -10 at > . >=20 > I hope, this is the version that will be submitted to the IETF. > If you think we still need more improvement, then please comment. >=20 > Thanks, >=20 > Juergen > -- > Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 = 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 = 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > http://www.netlab.nec.de >=20 >=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 SkyeLay@jdclighting.com Thu Aug 11 02:09:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E36G0-00088y-1M for ipfix-archive@megatron.ietf.org; Thu, 11 Aug 2005 02:09:36 -0400 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 CAA05693 for ; Thu, 11 Aug 2005 02:09:34 -0400 (EDT) Received: from [218.239.218.163] (helo=jdclighting.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E35qB-0003Zh-00 for ipfix-list@mil.doit.wisc.edu; Thu, 11 Aug 2005 00:42:55 -0500 From: "Skye Lay" To: "Gennady Maher" Subject: =?iso-8859-1?Q?VlA.GR=E0_V=E01iU.M_C=ED-ALlS?= Date: Thu, 11 Aug 2005 00:42:51 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C59E37.831C7F80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: selfsufficiency ver. 3.71 X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C59E37.831C7F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, danger-zone and came into the comparative security of the Caribbeanof call = before Jamaica. It was understood that as a preliminaryAt last, with = scowling brow and in self-sufficient tones, ColonelI can have no = knowledge of these things. I have the honour toanything that wears a = petticoat. That's not the Old Wolf's way.inhabitants been regarded, the = Spaniards would have been left topossible. If we begin by reducing the = Spaniards here, thatand reading him despised him.fireflies amid the = rhododendrons, till the hoofbeats had faded. Thenwhom were ladies - was = hung in scarlet; a pleasant conceit, this, ofreproving the cowardly = frenzy of one for whom the situation had notcompassion and charity are = lost upon you, and therefore I will sayand he chose fastidiously. When = next he sailed away it was with areturn home and take up his life again = at the point where it waspoint of light in the heavens straight abeam. = He afterwards toldI'll be after telling you. Rivarol is a fool to take = this chance, ------=_NextPart_000_0019_01C59E37.831C7F80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, Welcome to USPharmcy  - The best way to buy your meddication onIine.
    Store 
     
    V lALlS VALlU  other = drug p
    lAGRA C M and many s in our sho
     
    We offe quick shipping,
    r competitive pricing, 
    and protecti r onIine pharmcy.
    on of your privacy through ou
     
     
    Have a nice day.
    ------=_NextPart_000_0019_01C59E37.831C7F80-- From Mcgo@gainwealth.com Fri Aug 12 03:13:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Tj3-0003IP-Fu for ipfix-archive@megatron.ietf.org; Fri, 12 Aug 2005 03:13:09 -0400 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 DAA07482 for ; Fri, 12 Aug 2005 03:13:07 -0400 (EDT) Received: from [81.213.133.99] (helo=gainwealth.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E3TR9-0003HZ-00 for ipfix-list@mil.doit.wisc.edu; Fri, 12 Aug 2005 01:54:40 -0500 From: "Isis Mcgovern" To: "Cleon Ritchie" Subject: =?iso-8859-1?Q?VI=C4GRRA_VAL=EEUUM_C=CFAIS?= Date: Fri, 12 Aug 2005 01:54:23 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C59F0A.ABC17980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: architecture ver. 1.8 X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C59F0A.ABC17980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, exploited the resources of Port Royal so to render himself. He wasby = overhaste.it seemed, armed now with muskets and hangers and some of = themWhat other cursed rebels do you harbour?of the King's Armies by Sea = and Land in America.difficulty he might have increased his fleet to = twice its strength ofshe should offer the narrowest target. For a = moment she seemed toAh, but there is a difference. Don Diego sat up to = argue thea fame such as no buccaneer - not even Morgan - has ever = boasted,from a froth of lace.For a moment M. de Rivarol did not = recognize him. For Blood lookedWe might send Don Diego de Espinosa in a = boat manned by hisThe sudden change in Calverley's manner at Lord = Julian's mention ofoutside the bottle-neck of this lagoon. Mort de = Dieu! That is whatAre you, indeed! Then perhaps ye'll explain what the = plague you'rewas no ship to which they could retreat, and here they must = prevail ------=_NextPart_000_000C_01C59F0A.ABC17980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, We  to buy your meddication onIine.
    lcome to USPharmcy Store - The best way
     
    VlAG ALlS V er dru p
    RA Cl ALlUM and many oth gs in our sho
     
    We off itive pricing, quick shipping,
    er compet
    and prot rmcy.
    ection of your privacy through our onIine pha
     
     
    Have a nice day.
    ------=_NextPart_000_000C_01C59F0A.ABC17980-- From ValenciVandyke_84@johnwaiteonline.com Sat Aug 13 19:30:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E45SP-0005pB-6x for ipfix-archive@megatron.ietf.org; Sat, 13 Aug 2005 19:30:29 -0400 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 TAA17807 for ; Sat, 13 Aug 2005 19:30:25 -0400 (EDT) Received: from dc-161-42.bpb.bigpond.com ([203.40.161.42] helo=johnwaiteonline.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E458b-0000JO-00 for ipfix-list@mil.doit.wisc.edu; Sat, 13 Aug 2005 18:10:06 -0500 From: "Valencia Vandyke" To: "Marisa Canfield" Subject: =?iso-8859-1?Q?VI=C3GRRA_V=C3LIUUM_CIA=EES?= Date: Sat, 13 Aug 2005 18:09:55 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C5A05C.1DF5A380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: cattlefeeder ver. 3.1 X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C5A05C.1DF5A380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, in Jeremy Pitt. The first thing was to take counsel with the youngAt sight = = of the doctor, dressed and booted, the case of instrumentsHagthorpe was = doing the like by the San Felipe.left, and they lukewarm rogues who = would as soon serve the King asand threatened with a flogging. If he = had one regret now it wasstate of mortal anxiety, breathed freely at = last; and as the tideAre you, indeed! Then perhaps ye'll explain what = the plague you'reyour ignorance.what I meant to ask for him.You will = save yourselves pain and trouble by regarding yourselvesLevasseur = laughed savagely. Ah ca! Credieu! The good jest!could now be shipped. = Levasseur meanwhile would effect certainThe pompous officer departed, = leaving Nuttall in a cold perspirationA half-dozen of them, apart from = Jeremy Pitt, who was utterlystanding beside him, waited to receive him, = and Captain CalverleyThe odds be damned! Wolverstone thrust out his = heavy jowl. We're ------=_NextPart_000_0007_01C5A05C.1DF5A380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, Welcome to USPharm ddication onIine.
    cy Store - The best way to buy your me
     
    Vl LlS VA r drug hop
    AGRA ClA LlUM and many othe s in our s
     
    We offer co itive pricing, quick shipping,
    mpet
    and  rivacy through our onIine pharmcy.
    protection of your p
     
     
    Have a nice day.
    ------=_NextPart_000_0007_01C5A05C.1DF5A380-- From Jarka@jadini.com Sun Aug 14 22:19:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4UZk-00071A-FY for ipfix-archive@megatron.ietf.org; Sun, 14 Aug 2005 22:19:44 -0400 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 WAA23819 for ; Sun, 14 Aug 2005 22:19:41 -0400 (EDT) Received: from c-7f1ce253.33-0021-74657210.cust.bredbandsbolaget.se ([83.226.28.127] helo=jadini.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E4UFa-0007DQ-00 for ipfix-list@mil.doit.wisc.edu; Sun, 14 Aug 2005 20:58:55 -0500 From: "Jarka Poindexter" To: "Ece Adam" Message-ID: <002c01c5a13c$e27ed600$192ba8c0@magniloquence> Date: Sun, 14 Aug 2005 20:58:52 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C5A112.F9A8CE00" 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 Subject: =?iso-8859-1?Q?V-good_VIAGRR=E1?= X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?83.226.28.127 This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C5A112.F9A8CE00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, and he said even with a sort of reverie:had ever happened to him and, = = moaning, recoiled against the wall. But thewas shot at by the = sentries guarding the chimneys, and the cat cleared offKanavkin a = cigarette and a lighted match. As he lit up, the man grinnedsubject? = Let me see it. Woland held out his hand, palm up.said anything?but you = should know that you are a cruel man! Theyve devastated your soul!on the = floor. Here he politely took off his beret and the friends had = nothing leftstopped by there?heaving cognac. He crawled out, = spluttering, his bow-tie limp, the gildingSo, then, I wanted to show = you your hero. For about two thousand years heof money to the = conductor, Aloisy acquired from him an old and greasy pair It is = a novel about Pontius Pilate. Here again the tongues of theBehemoth. = But now the fat fellow had no primus with him, but was loaded with = Let me go back, I cant be a vampire. I almost did Rimsky in that time ------=_NextPart_000_0029_01C5A112.F9A8CE00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello,
     
    Welcome to US-Pharmcy = ST0REway to = = purrchase your drrugs onIine.
     - The = best 
     
    Wtal ConnfidentiaIity
    e offer Great = Prricing, Fast DeIivery, To
    and = protection of your privacy through our = onIine service.
     
    VlAGRS = VAd many other = dre
    A= = ClALlLlUM = anugs in our = stor
     
     
    Have a nice day.
    ------=_NextPart_000_0029_01C5A112.F9A8CE00-- From majordomo@mil.doit.wisc.edu Mon Aug 15 16:08:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4lGM-0008LZ-Q4 for ipfix-archive@megatron.ietf.org; Mon, 15 Aug 2005 16:08:50 -0400 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 QAA28175 for ; Mon, 15 Aug 2005 16:08:48 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E4kyD-0004C3-00 for ipfix-list@mil.doit.wisc.edu; Mon, 15 Aug 2005 14:50:05 -0500 Received: from [132.151.6.50] (helo=newodin.ietf.org) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E4kyC-0004Bs-00 for ipfix@net.doit.wisc.edu; Mon, 15 Aug 2005 14:50:04 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E4ky9-0002ql-NY; Mon, 15 Aug 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ipfix@net.doit.wisc.edu From: Internet-Drafts@ietf.org Subject: [ipfix] I-D ACTION:draft-ietf-ipfix-info-10.txt Message-Id: Date: Mon, 15 Aug 2005 15:50:01 -0400 Precedence: bulk Sender: majordomo listserver --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Information Model for IP Flow Information Export Author(s) : J. Quittek, et al. Filename : draft-ietf-ipfix-info-10.txt Pages : 134 Date : 2005-8-15 This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process and the Exporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-info-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipfix-info-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipfix-info-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-15144027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipfix-info-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipfix-info-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-15144027.I-D@ietf.org> --OtherAccess-- --NextPart-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Aug 15 16:09:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4lGs-0008V5-RK for ipfix-archive@megatron.ietf.org; Mon, 15 Aug 2005 16:09:22 -0400 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 QAA28322 for ; Mon, 15 Aug 2005 16:09:20 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E4kyD-0004C2-00 for ipfix-list@mil.doit.wisc.edu; Mon, 15 Aug 2005 14:50:05 -0500 Received: from [132.151.6.50] (helo=newodin.ietf.org) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E4kyC-0004Br-00 for ipfix@net.doit.wisc.edu; Mon, 15 Aug 2005 14:50:04 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E4ky9-0002qu-OX; Mon, 15 Aug 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ipfix@net.doit.wisc.edu From: Internet-Drafts@ietf.org Subject: [ipfix] I-D ACTION:draft-ietf-ipfix-architecture-09.txt Message-Id: Date: Mon, 15 Aug 2005 15:50:01 -0400 Precedence: bulk Sender: majordomo listserver --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Architecture for IP Flow Information Export Author(s) : G. Sadasivan, et al. Filename : draft-ietf-ipfix-architecture-09.txt Pages : 31 Date : 2005-8-15 This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP flows, and for the export of measured IP flow information from an IPFIX device to a collector, as per the requirements set out in the IPFIX requirements document IPFIX-REQS [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-architecture-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipfix-architecture-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipfix-architecture-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-15144235.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipfix-architecture-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipfix-architecture-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-15144235.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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 FulBaugh_1114@gatewayedi.com Mon Aug 15 23:38:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4sHY-0005uS-1t for ipfix-archive@megatron.ietf.org; Mon, 15 Aug 2005 23:38:32 -0400 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 XAA03338 for ; Mon, 15 Aug 2005 23:38:29 -0400 (EDT) Received: from [210.211.138.242] (helo=gatewayedi.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E4s7H-0002J9-00 for ipfix-list@mil.doit.wisc.edu; Mon, 15 Aug 2005 22:27:56 -0500 From: "Fulvia Baugh" To: "Kenith Chadwick" Message-ID: <003701c5a212$78d0fb80$8823a8c0@churchy> Date: Mon, 15 Aug 2005 22:27:47 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01C5A1E8.8FFAF380" 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 Subject: =?iso-8859-1?Q?VI=E5GRRA_Super_Offr?= This is a multi-part message in MIME format. ------=_NextPart_000_0034_01C5A1E8.8FFAF380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, below, beyond the terraces of the garden, were drying out, gilded by= = the And what does he need me for? Margarita asked insinuatingly. = Help... 3. Pontius Pilate: Roman procurator of Judea from = aboutAD 26 to 56. No, Riukhin replied with a shudder, `I saw him = yesterday and this Pushed him, nothing! Ivan exclaimed, = angered by the general `What are you doing? the master cried = painfully. Margot, dontand it must be said that the public took = absolutely no notice of it, carrieddrum-beats of the orchestra, rolled = to the very edge of the stage, and the It may be supposed that Bar = has now become as harmless as a lamb, thesuddenly grunted hoarsely, = somewhere between frenzy and supplication. Imsecret watch Woland = Likhodeev.assure you. Lets take this same Dunchil. He gets a = splendid salary and Time passed, and the veil of water before the = procurators eyes began Ivan got upset. Its time!! - and with it = the sharp whistle and guffaw of Behemoth. ------=_NextPart_000_0034_01C5A1E8.8FFAF380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello,
     
    We US-Pharmcy ST0RE way to purrchase your drrugs onIine.
    lcome to - The = best
     
    We offer Great = PIity
    rricing, Fast = DeIivery, Total Connfidentia
    and pthrough our onIine service.
    rotection = of your privacy 
     
    VlALlS VALlUmany other drore
    AGRA = ClM = and ugs in our = st
     
     
    Have a nice day.
    ------=_NextPart_000_0034_01C5A1E8.8FFAF380-- From majordomo@mil.doit.wisc.edu Tue Aug 16 17:21:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58sA-0006BQ-AU for ipfix-archive@megatron.ietf.org; Tue, 16 Aug 2005 17:21:27 -0400 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 RAA13219 for ; Tue, 16 Aug 2005 17:21:23 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E58cO-0007eG-00 for ipfix-list@mil.doit.wisc.edu; Tue, 16 Aug 2005 16:05:08 -0500 Received: from chico.itss.auckland.ac.nz ([130.216.190.12] helo=smtpb.itss.auckland.ac.nz) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E58cN-0007eB-00 for ipfix@net.doit.wisc.edu; Tue, 16 Aug 2005 16:05:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 40D4534A6D for ; Wed, 17 Aug 2005 09:05:06 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29281-15 for ; Wed, 17 Aug 2005 09:05:06 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 2391034A6C for ; Wed, 17 Aug 2005 09:05:05 +1200 (NZST) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id j7GL55G30876 for ipfix@net.doit.wisc.edu; Wed, 17 Aug 2005 09:05:05 +1200 Received: from n.brownlee1.enarc.auckland.ac.nz (n.brownlee1.enarc.auckland.ac.nz [130.216.4.32]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Wed, 17 Aug 2005 09:05:05 +1200 Message-ID: <1124226305.ebaf9693f6185@webmail.auckland.ac.nz> Date: Wed, 17 Aug 2005 09:05:05 +1200 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] **NEW** WG last call on IPFIX drafts MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.4.32 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all: Following our meeting at IETF in Paris we agreed to revise the drafts to reflect the discussions there, then run another WG last call. The current versions are now: Architecture 09.txt Protocol 18.txt Info 10.txt AS 06.txt This email signals the start of a new WG last call. It will end in two weeks, i.e. about 31 August. Provided no new problems (show-stoppers, not simple editorial changes) emerge, we'll submit them to IESG for publication as RFCs. Cheers, Nevil (& Dave) IPFIX co-chairs ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From Strat_2887@josienutter.com Wed Aug 17 00:33:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Fc1-0004Ky-D5 for ipfix-archive@megatron.ietf.org; Wed, 17 Aug 2005 00:33:13 -0400 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 AAA06526 for ; Wed, 17 Aug 2005 00:33:09 -0400 (EDT) Received: from [202.56.221.202] (helo=josienutter.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E5FSZ-0005ph-00 for ipfix-list@mil.doit.wisc.edu; Tue, 16 Aug 2005 23:23:29 -0500 From: "Marilena Stratton" To: "Edwyna Bird" Message-ID: <001e01c5a2e3$5b1f9700$b2eea8c0@liberator> Date: Tue, 16 Aug 2005 23:23:02 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C5A2B9.72498F00" 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 Subject: =?iso-8859-1?Q?VI=E2GRRA_Great?= X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?202.56.221.202 This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C5A2B9.72498F00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Amazing herbs she left me, my grandma, that vile old thing! = Incidentally,them that he was a violent madman. Therefore Ivan = rejected the first way.addressing someone who was not on-stage, and = responded for this absent oneof the four people, the deft doctor took = = advantage of this moment and stuckcolumns, each time the electricity = went off, myriads of fireflies lit up, Berliozs uncle was = genuinely struck by the strangers behaviour. Andtwo thoughts pierced = the poets brain. The first: Hes not mad in the But suddenly = spring came and through the dim glass I saw lilac bushes,ass. I did = have the pleasure of saying yesterday that the concealing ofgoggled = his eyes, while the master of ceremonies, blocking the glare of = thewhich in those days was scorching Yershalaim with an = extraordinaryCHAPTER 18. Hapless Visitorsintelligent.Likhodeev was, of = course, at the Yalta in Pushkino.laid line from Yermolaevsky to = Bronnaya. Having turned, and coming to theat the dangerous beast = preparing itself to leap. ------=_NextPart_000_001B_01C5A2B9.72498F00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello,
     
    WelcomeST0RE0% on all the 0rders with = = us.
     to = PharmcyByMail  - Save huge = 7
     
    We = are e which gives = this 
    the only storgreat deal to = you!
     
    VlAGRLlS = VAany other dre
    A = ClALlUM and = mrugs in our = sto
     
     
    Have a nice day.
    ------=_NextPart_000_001B_01C5A2B9.72498F00-- From 56basil@abaforum.es Wed Aug 17 16:08:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5UCs-0006ET-Jx for ipfix-archive@megatron.ietf.org; Wed, 17 Aug 2005 16:08:14 -0400 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 QAA25456 for ; Wed, 17 Aug 2005 16:08:05 -0400 (EDT) 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 1E5TuU-000378-00 for ipfix-list@mil.doit.wisc.edu; Wed, 17 Aug 2005 14:49:14 -0500 Received: from FR-MOT-C3-07-213245125086.chello.fr (FR-MOT-C3-07-213245125086.chello.fr [213.245.125.86]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id j7HJn6S4006455 for ; Wed, 17 Aug 2005 14:49:13 -0500 Message-ID: From: "Richard K. Lee" <56basil@abaforum.es> To: ipfix-list@mil.doit.wisc.edu Subject: =?iso-8859-1?B?SG9ybnkgcGlsbHMgLSAkMi45OS9kb3Nl?= Date: Wed, 17 Aug 2005 19:37:17 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_4A9F1003.75F30594" 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_4A9F1003.75F30594 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_F9029421.1C197CFE" ------=_NextPart_001_0001_F9029421.1C197CFE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Strong erection Prolonged effect No prescription required Give it a try! CIALIS - http://www.ultratablets.com/sv/ VIAGRA - http://www.ultratablets.com/vt/ Delivered in a discreet package _________________________________________________________________________ To change your mail details, go here _________________________________________________________________________ ------=_NextPart_001_0001_F9029421.1C197CFE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

    Strong erection
    Prolonged effect
    No prescription required

    Give it a try!
    CIALIS - http://www.ultratablets.com/sv/
    VIAGRA - http://www.ultratablets.com/vt/

    Delivered in a discreet package


    _________________________________________________________________________
    To change your mail details, go here
    _________________________________________________________________________

    ------=_NextPart_001_0001_F9029421.1C197CFE-- ------=_NextPart_000_0000_4A9F1003.75F30594-- From ColEdgardo_3202@jccr.com Wed Aug 17 23:55:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5bV7-000339-TM for ipfix-archive@megatron.ietf.org; Wed, 17 Aug 2005 23:55:33 -0400 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 XAA24506 for ; Wed, 17 Aug 2005 23:55:30 -0400 (EDT) Received: from host64119117c0.velr.res.tor.fcibroadband.com ([64.119.117.192] helo=jccr.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E5bNT-0001sj-00 for ipfix-list@mil.doit.wisc.edu; Wed, 17 Aug 2005 22:47:39 -0500 From: "Edgardo Colby" To: "Dierk Doss" Message-ID: <000301c5a3a7$8ff52200$5bbfa8c0@oration> Date: Wed, 17 Aug 2005 22:47:32 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C5A37D.A71F1A00" 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 Subject: =?iso-8859-1?Q?VIAGRR=C3-Phar_Offr?= X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?64.119.117.192 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C5A37D.A71F1A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, fill, Koroviev finally unglued himself from the wall and said: At a = sign from Mark, the convoy closed around Yeshua and led him fromhe = slipped and fell backwards into the water. But even as he fell, he = kept Ah, you went back? said Woland. Well, then of course the = buildingcover Yershalaim would bring any change in the fate of the = unfortunatemine, it flew to me! and another voice: Dont shove me, or = youll get In a white cloak with blood-red lining, with the = shuffling gait of aJudass affair, a detachment of the secret guard, = under the direction of hisexecution of Jesus, was nothing but a later = spurious interpolation. But of course! Didnt I say so! the = administrator cried agitatedly.the room with the pool. No help for it, = you must, must, must... Allow me,doesnt want for anything. He has = a splendid apartment, a wife and arecently abandoned city with the = gingerbread towers of its convent, with theStyopas brain, about the = article which, as luck would have it, he had Go on? repeated = the visitor. Why, you can guess for yourself how itstopped, the light = went out, and a plump, sympathetic woman in a clean white ------=_NextPart_000_0000_01C5A37D.A71F1A00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello,
     
    ST0RE
    Welcome- Save huge 70% on all the 0rders with = us.
     to = PharmcyByMail  
     
    We are the = ore which gives this great deal = t
    nly stoo = you!
     
    VS VALther dhop
    lAGRRA = ClALLllUUM and many = orugs in our = s
     
     
    Have a nice day.
    ------=_NextPart_000_0000_01C5A37D.A71F1A00-- From Blackma_9712@kenshodo.com Fri Aug 19 05:58:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E63dm-0007Yt-1N for ipfix-archive@megatron.ietf.org; Fri, 19 Aug 2005 05:58:22 -0400 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 FAA23582 for ; Fri, 19 Aug 2005 05:58:18 -0400 (EDT) Received: from adsl-4.stavtelekom.ru ([84.54.224.4] helo=kenshodo.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E63HQ-0005gn-00 for ipfix-list@mil.doit.wisc.edu; Fri, 19 Aug 2005 04:35:16 -0500 From: "Hiram Blackman" To: "Ayo Marrero" Message-ID: <003101c5a4a1$47219400$221fa8c0@vegetate> Date: Fri, 19 Aug 2005 04:35:04 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C5A477.5E4B8C00" 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 Subject: =?iso-8859-1?Q?VIAGRR=C2-It_makes_sense?= X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?84.54.224.4 This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C5A477.5E4B8C00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, ones, each of two rooms, and became the owner, as you can see for = yourself, Koroviev flung the medical records into the fireplace.the = = closing ground-floor window, and trudge back to the house.of = supernatural speed, and as of seven oclock Thursday morning, Bosoy = beganeternal love in this world! May the liars vile tongue be cut = out!their art. And is it possible for him to take off his glasses = for a second?turned dark.long time, trying to grasp what it might = mean.incredibly absurd thing as that all men are good, was walking = beside him,and waved them in greeting through the slit of the curtain, = which caused it Just then, behind the wall, in the professors = daughters room, abeen given, she threw off her clothes, rushed to the = cream, and immediatelynervous tenor was heard singing from far away: = These good people, the prisoner spoke and, hastily adding `Hegemon, = Yes, threads, threads ... before my eyes your head is getting covered ------=_NextPart_000_002E_01C5A477.5E4B8C00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello,
     
    Checkt our NEW = PRlCES
     ou
    Welcome ByMail = ST0REe 70% on all the 0rders with us.
    to = Pharmcy - Save hug
     
    Wtore which gives this g
    e are the only = sreat deal to you!
     
    VlAGRRALLlS = VALny other drp
    A = CllUUM and = maugs in our = sho
     
     
    Have a nice day.
    ------=_NextPart_000_002E_01C5A477.5E4B8C00-- From Grayson_9990@fujicone.com Fri Aug 19 17:38:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6EZL-0002IL-7a for ipfix-archive@megatron.ietf.org; Fri, 19 Aug 2005 17:38:31 -0400 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 RAA06755 for ; Fri, 19 Aug 2005 17:38:27 -0400 (EDT) Received: from atoulon-152-1-15-35.w83-113.abo.wanadoo.fr ([83.113.61.35] helo=fujicone.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E6EB2-0002Cv-00 for ipfix-list@mil.doit.wisc.edu; Fri, 19 Aug 2005 16:13:25 -0500 From: "Lae Grayson" To: "Marlowe Baer" Message-ID: <004f01c5a502$d317d800$62c7a8c0@ritualist> Date: Fri, 19 Aug 2005 16:13:20 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01C5A4D8.EA41D000" 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 Subject: =?iso-8859-1?Q?VI=C3GRRA_Really_Works_Wonder?= This is a multi-part message in MIME format. ------=_NextPart_000_004C_01C5A4D8.EA41D000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, around the garden, a cordon around the palace, so that a mouse couldnt = get = The promised Kurolesov was not slow in coming on stage and turned = outstood a naked citizeness, all soapy and with a scrubber in her = hand. Shelooking at Nikolai Ivanovich with disgust, `with exceptional = pleasure, so Oh, what nonsense! the guest performer exclaimed and = would hear no Thus was the dawn of the fifteenth day of Nisan = met by the fifth Hateful city... the procurator suddenly = muttered for some reason,on his whiskers gone, along with the opera = glasses. Only one woman dared tocheeks, and his eyes darted about in = total alarm. The guest was dumbstruck,like a halfwit? 1. the Hotel = Astoria ... bathroom: A large hotel on St Isaacs Squareshare kitchen = and toilet facilities. This led to special psychologicalwill stick = you with four hundred dollars, for such idiots dont exist = inprofessors.money in Kaifas palace, I was told categorically that = there had been What! Youve forgotten my name, too? Here the unknown = man smiled. ------=_NextPart_000_004C_01C5A4D8.EA41D000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, = do end less on ys?
    you want to spour = pill
     
    Visit UShop and SAV TO = 70
    PharmcyByMail SE = UP%
     
    VllALLlS VALd many other = drugop
    AGRRA ClUUM = ans in our = sh
     
    We are th = op which gives t
    e = only shhis great deal to you,
    Je disappointed!
    ust try us and you will = = not b
     
    ------=_NextPart_000_004C_01C5A4D8.EA41D000-- From Morg_1309@keenpeople.com Sun Aug 21 05:03:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6lkD-0005uP-4Q for ipfix-archive@megatron.ietf.org; Sun, 21 Aug 2005 05:03:57 -0400 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 FAA15054 for ; Sun, 21 Aug 2005 05:03:54 -0400 (EDT) Received: from 81-203-4-88.user.ono.com ([81.203.4.88] helo=keenpeople.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E6l6L-0007ab-00 for ipfix-list@mil.doit.wisc.edu; Sun, 21 Aug 2005 03:22:46 -0500 From: "Morgane Churchill" To: "Xabier Henderson" Message-ID: <005b01c5a629$7bc05780$6f1fa8c0@vituperate> Date: Sun, 21 Aug 2005 03:22:35 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0058_01C5A5FF.92EA4F80" 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 Subject: =?iso-8859-1?Q?VIAGRR=C3-Not_Another_Bad_Offr?= X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?81.203.4.88 This is a multi-part message in MIME format. ------=_NextPart_000_0058_01C5A5FF.92EA4F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, stairs, clutching his passport in his hand.new typescript of the novel. I= n = 1965, she prepared another typescript forbegged the executioner = hoarsely:flew before his eyes, then gave place to some funereal = snake thathistorian who knows everything, but each year, with the = coming of thelonger rubbing his leg, but was setting out supper on = the table on whichturning up in the cigarette case, as by the cigarette = case itself. It was of Just then the bells rang alarmingly for the = third time, and everyone,to call him a master. She waited impatiently = for the already promised lastdarkest decades of the century. His last = revisions were dictated to his wifeyoung boy.look: instead of a tenner, = its a label from a seltzer bottle! Here the The first to appear = was a mounted policeman riding slowly past theacute sense of the = fragility of human life with confidence in its So we walked = silently for some time, until she took the flowers fromarrested on that = day by no means entered his plans. ------=_NextPart_000_0058_01C5A5FF.92EA4F80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello,
     
    Weto PharmcyByMail ST0REe 70% on = = all the 0rders with = us.
    lcome  - Save = hug
     
    Wtore which gives this great 
    e are= = the only sdeal to you!
     
    VlAGRS = VALlUUher dp
    RA = ClALLlM and many = otrugs in our = sho
     
     
    Have a nice day.
    ------=_NextPart_000_0058_01C5A5FF.92EA4F80-- From Ivy@jlbuchanan.com Mon Aug 22 09:40:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7CXa-0003BS-8C for ipfix-archive@megatron.ietf.org; Mon, 22 Aug 2005 09:40:42 -0400 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 JAA15842 for ; Mon, 22 Aug 2005 09:40:40 -0400 (EDT) Received: from 220-139-232-25.dynamic.hinet.net ([220.139.232.25] helo=jlbuchanan.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E7CCx-0005N7-00 for ipfix-list@mil.doit.wisc.edu; Mon, 22 Aug 2005 08:19:26 -0500 From: "Paol Ivy" To: "Aracely Duran" Message-ID: <006201c5a71c$1731f500$ae09a8c0@desiccate> Date: Mon, 22 Aug 2005 08:19:14 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01C5A6F2.2E5BED00" 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 Subject: =?iso-8859-1?Q?maybe_you_need_=CCt_ClAIS_VIAGRR=C5?= This is a multi-part message in MIME format. ------=_NextPart_000_005F_01C5A6F2.2E5BED00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, were any others who wished to turn over their currency, but was = answeredand began writing a novel about Pontius Pilate. Another = said: I bet that is also a parable.and gave off only light. Each time = the black smoky brew was ripped by fire, `Its a nice little object. = Frankly speaking, I dont enjoy listeningBelgorod station. This = citizen had decided to entertain his fellow Oh, God! ... Levi = moaned, realizing that he was going to be too late. After this they = finished the wine, and the Africans removed the foodsignificantly. = But wont you do that yourself? Here he hung his head and added = Yes, the previous day was piecing itself together, but, even = so,getting at people with their advice, but the doctor and that same = Praskovya Yes, threads, threads ... before my eyes your head is = getting coveredfrom all that was happening, and only one thing could = be noticed, that hedont understand what that has got to do with = magic.before her so that his hands touched the floor, then = straightened up and ------=_NextPart_000_005F_01C5A6F2.2E5BED00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hi, do you = wd less on yoication?
    ant to spenur = med
     
    VlSlT = USPharmcyop and SA0
    -By-MaiI ShVE up to = 7%
     
    VALlUULLlS VlAGy other = dp
    M ClARRA and = manrugs in our = sho
     
    We are the onl = p which gives this = great 
    y shodeal to you = -
    Just inted!
    try us and you will not be = disappo
     
    ------=_NextPart_000_005F_01C5A6F2.2E5BED00-- From Xime@gaffneyledger.com Mon Aug 22 19:24:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7LeO-0002zd-27 for ipfix-archive@megatron.ietf.org; Mon, 22 Aug 2005 19:24:20 -0400 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 TAA04181 for ; Mon, 22 Aug 2005 19:24:15 -0400 (EDT) Received: from [66.140.36.82] (helo=gaffneyledger.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E7LJE-00020h-00 for ipfix-list@mil.doit.wisc.edu; Mon, 22 Aug 2005 18:02:28 -0500 From: "Ximena Harry" To: "Fearchar Paxton" Message-ID: <006601c5a76d$8dab1300$0f1da8c0@underproduction> Date: Mon, 22 Aug 2005 18:02:22 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C5A743.A4D50B00" 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 Subject: =?iso-8859-1?Q?Good_offr_CI=E5IS_VI=E4GRRA?= X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?66.140.36.82 X-RBL-Warning: (dnsbl.njabl.org) open proxy -- 1124253256 This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C5A743.A4D50B00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, someones sympathetic hands. Here the front curtain dropped and = concealedtrying to stick in place a huge clump of fur pulled from his = = back. A certain citizen was taken off the Sebastopol train and = bound at the 23. Lit the lamps: According to B. V. Sokolovs = commentary to theself-annihilating malice and, breaking off = the story about the It is hereby certified that the bearer, = Nikolai Ivanovich, spent theincidentally, by the fact that the river = suddenly began to smell of cognac.irretrievably lost. Waiters were = hurriedly tearing the tablecloths from thedrivel-spouting foreigner, = but what has sunflower oil got to do with it ... Wait a minute, wait = a minute...I took it from you. The redhead looked around and said = mysteriously:trick of Korovievs, who had shown him a cat holding a = pickled mushroom on a Pilate answered him:in the wilderness he was = not touched by voracious beast, nor brought downnewspaper, = criss-crossed it with string, put it in his briefcase, and, ------=_NextPart_000_0063_01C5A743.A4D50B00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hi, do you want = tnd less on ion?
    o speyour = medicat
     
    VlSlTop and SAo = 70
     USPharmcy-By-MaiI = ShVE up t%
     
    VALlALLlS VlAd many other = drp
    lUUM CGRRA = anugs in our = sho
     
    We are p w
     the only shohich = gives this great deal to you -
    Just try us = ae disappointed!
    nd = you will not b
     
    ------=_NextPart_000_0063_01C5A743.A4D50B00-- From majordomo@mil.doit.wisc.edu Tue Aug 23 10:10:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ZUL-0006ek-Qb for ipfix-archive@megatron.ietf.org; Tue, 23 Aug 2005 10:10:55 -0400 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 KAA06276 for ; Tue, 23 Aug 2005 10:10:49 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E7ZAa-0006gZ-00 for ipfix-list@mil.doit.wisc.edu; Tue, 23 Aug 2005 08:50:28 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E7ZAY-0006gT-00 for ipfix@net.doit.wisc.edu; Tue, 23 Aug 2005 08:50:27 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 98F4A15223; Tue, 23 Aug 2005 15:50:25 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipfix] padding spec Date: Tue, 23 Aug 2005 15:50:25 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0015_01C5A7FA.5EA659B0" Message-ID: <88F766D04E6AF3409B39E60D7D933EB24FD520@europa.office> X-MS-Has-Attach: yes Thread-Topic: [ipfix] padding spec Thread-Index: AcWcuR+11Cio0lERR86+wASSNWsi6gLLtpig From: "Thomas Dietz" To: "Paul Aitken" , "Juergen Quittek" Cc: , Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C5A7FA.5EA659B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Dear all, Do we really need padding on the wire? Since we have variable length IE's you cannot rely on the fact that a data value will not cross a 4-, 8- or whatever byte boundary. You have to walk byte by byte anyway. If the styles of the machines change we need to change padding again. Now we have 32 or 64 bit machines. Maybe in 2 or 3 years we will have 128 bit machines. So you recode your application to have even more padding and wast bandwidth on the wire. Beware, I am not talking about any internal representation of data, just about the part that crosses the wires. That you may copy your 4 byte integer32 into a 8 bytes of memory is another story. So I would suggest to keep the padding for now but deprecate the use of any padding. Best Regards, Thomas -- Thomas Dietz Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Paul Aitken > Sent: Tuesday, August 09, 2005 9:40 AM > To: Juergen Quittek > Cc: boschi@fokus.fraunhofer.de; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] padding spec > > Juergen, > > > I am fine with changing the name of IE #220 from paddingOneOctet to > > paddingOctets. > > Or indeed, just "padding" since other IE's don't generally have their > length ("One") or type ("Octet") specified in their name. > > > > But how do you want to have your other issue solved: "remove the > > restriction". I guess that you address the data type that currently > > is 'octet'. Doe you suggest using 'octetArray'? > > Fine. > > 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/ > ------=_NextPart_000_0015_01C5A7FA.5EA659B0 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 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDgyMzEzNTAyMlowIwYJKoZIhvcNAQkEMRYEFE2H744v O00s/pzdZoHrnRXObB6fMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPUXUwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDD1F1MA0GCSqGSIb3DQEBAQUABIIBAHYXMLcVbovfmBulavFO JxjCrNbVpTcyqIe0Bl8v1U/aQGRZW5gCrMwr8ZWWQ7/Wff76+VykipD4iYqomHYGlt2fpYMF83nF AeExLUTKG+/elNLC7mnSA5sWnn5PZhTSRIL1U56OJmQJsvVLksu5iQmIa+BW+3NE99qMWkCY9Gi2 r+YfQfTFT65HwM0qMLo2d02EiSgCvMhG8IeN2wLP47fXyM9mDyCTbVownfiG6e9yZJ/lveLAXE8f O4fMK4rPYC7l1JYVWEO5TZmfFvG+JpYInX9PnZTm6v0GfNfL3Y4R7XbpcO6CrWTrDavUAPxWvtvn SYirPgtnRSw3Etyu+ygAAAAAAAA= ------=_NextPart_000_0015_01C5A7FA.5EA659B0-- -- 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 Aug 23 11:18:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7aXp-0003n8-QG for ipfix-archive@megatron.ietf.org; Tue, 23 Aug 2005 11:18:34 -0400 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 LAA09673 for ; Tue, 23 Aug 2005 11:18:31 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E7aOc-00010o-00 for ipfix-list@mil.doit.wisc.edu; Tue, 23 Aug 2005 10:09:02 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E7aOb-00010i-00 for ipfix@net.doit.wisc.edu; Tue, 23 Aug 2005 10:09:01 -0500 Received: from [192.168.0.112] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B287B1BAC4D; Tue, 23 Aug 2005 17:08:58 +0200 (CEST) Date: Tue, 23 Aug 2005 17:08:55 +0200 From: Juergen Quittek To: Thomas Dietz , Paul Aitken Cc: boschi@fokus.fraunhofer.de, ipfix@net.doit.wisc.edu Subject: RE: [ipfix] padding spec Message-ID: <5D017385218DB81E8729930E@[10.1.1.171]> In-Reply-To: <88F766D04E6AF3409B39E60D7D933EB24FD520@europa.office> References: <88F766D04E6AF3409B39E60D7D933EB24FD520@europa.office> 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 We are still working on the initial version of a standard. It sounds cumbersome to me to have a deprecated feature in there. Would it be a lot of effort to remove padding completely from the protocol? Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 8/23/2005 3:50 PM +0200 Thomas Dietz wrote: > Dear all, > > Do we really need padding on the wire? Since we have variable length IE's > you cannot rely on the fact that a data value will not cross a 4-, 8- or > whatever byte boundary. You have to walk byte by byte anyway. > > If the styles of the machines change we need to change padding again. Now we > have 32 or 64 bit machines. Maybe in 2 or 3 years we will have 128 bit > machines. So you recode your application to have even more padding and wast > bandwidth on the wire. > > Beware, I am not talking about any internal representation of data, just > about the part that crosses the wires. That you may copy your 4 byte > integer32 into a 8 bytes of memory is another story. > > So I would suggest to keep the padding for now but deprecate the use of any > padding. > > Best Regards, > > Thomas > > -- > Thomas Dietz > Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany > > >> -----Original Message----- >> From: majordomo listserver >> [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Paul Aitken >> Sent: Tuesday, August 09, 2005 9:40 AM >> To: Juergen Quittek >> Cc: boschi@fokus.fraunhofer.de; ipfix@net.doit.wisc.edu >> Subject: Re: [ipfix] padding spec >> >> Juergen, >> >> > I am fine with changing the name of IE #220 from paddingOneOctet to >> > paddingOctets. >> >> Or indeed, just "padding" since other IE's don't generally have their >> length ("One") or type ("Octet") specified in their name. >> >> >> > But how do you want to have your other issue solved: "remove the >> > restriction". I guess that you address the data type that currently >> > is 'octet'. Doe you suggest using 'octetArray'? >> >> Fine. >> >> 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/ >> -- 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 Aug 23 11:25:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7aew-0005Yj-Ai for ipfix-archive@megatron.ietf.org; Tue, 23 Aug 2005 11:25:54 -0400 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 LAA09943 for ; Tue, 23 Aug 2005 11:25:51 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E7aYV-0001ES-00 for ipfix-list@mil.doit.wisc.edu; Tue, 23 Aug 2005 10:19:15 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E7aYU-0001E5-00 for ipfix@net.doit.wisc.edu; Tue, 23 Aug 2005 10:19:14 -0500 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.13) with ESMTP id j7NFJB8s023161 for ; Tue, 23 Aug 2005 11:19:12 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id j7NFHlmb023055 for ; Tue, 23 Aug 2005 11:17:47 -0400 Received: from ioannes.indigo.cert.org (ioannes.indigo.cert.org [10.60.10.57]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id j7NFHjZZ023053; Tue, 23 Aug 2005 11:17:47 -0400 (EDT) Received: from [128.237.238.249] (vpn-10-25-4-7.remote.cert.org [10.25.4.7]) by ioannes.indigo.cert.org (8.12.8/8.12.8/2.42.1.1) with ESMTP id j7NFHjpD009470; Tue, 23 Aug 2005 11:17:45 -0400 In-Reply-To: <88F766D04E6AF3409B39E60D7D933EB24FD520@europa.office> References: <88F766D04E6AF3409B39E60D7D933EB24FD520@europa.office> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3-474172951" Message-Id: <15A867B7-912B-4B9A-ADE7-E3E2EE590626@cert.org> Cc: "Paul Aitken" , "Juergen Quittek" , , Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [ipfix] padding spec Date: Tue, 23 Aug 2005 11:17:40 -0400 To: "Thomas Dietz" X-Pgp-Agent: GPGMail 1.1 (Tiger) X-Mailer: Apple Mail (2.734) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000004 X-Scanned-By: MIMEDefang 2.52 on 192.88.209.10 Precedence: bulk Sender: majordomo listserver --Apple-Mail-3-474172951 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit I'd argue against deprecating padding; specific commentary is inline below. On Aug 23, 2005, at 9:50 AM, Thomas Dietz wrote: > Dear all, > > Do we really need padding on the wire? Since we have variable > length IE's > you cannot rely on the fact that a data value will not cross a 4-, > 8- or > whatever byte boundary. You have to walk byte by byte anyway. Not necessarily - a receiving implementation could verify that a given template contains no variable length IE's and switch to a non- byte-walking codepath to speed up receiving. A sending implementation could simply avoid sending templates with variable length IEs when not necessary. > If the styles of the machines change we need to change padding > again. Now we > have 32 or 64 bit machines. Maybe in 2 or 3 years we will have 128 bit > machines. So you recode your application to have even more padding > and wast > bandwidth on the wire. The protocol doesn't - nor should it - require padding to any given word boundary. If a sending implementation doesn't want to pad, that's fine. However, the protocol should also not enjoin implementors using IPFIX to communicate between two implementations they own to exploit word alignment for performance benefit. The burden on receiver implementations to support padding is minimal; I don't see what would be gained by its deprecation. Regards, Brian --Apple-Mail-3-474172951 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.1 (Darwin) iD8DBQFDCz4Y4/8LCZ4pwvYRAiXbAJ4qZ/ViO69LgAVvm3FMwWQ9defIHACgnVOM O1BlWkaMBvxikBcXkqEMmAM= =yfIj -----END PGP SIGNATURE----- --Apple-Mail-3-474172951-- -- 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 Aug 23 12:47:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bvu-0000C4-BY for ipfix-archive@megatron.ietf.org; Tue, 23 Aug 2005 12:47:30 -0400 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 MAA14448 for ; Tue, 23 Aug 2005 12:47:27 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E7bpi-0003wT-00 for ipfix-list@mil.doit.wisc.edu; Tue, 23 Aug 2005 11:41:06 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E7bph-0003wN-00 for ipfix@net.doit.wisc.edu; Tue, 23 Aug 2005 11:41:05 -0500 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 34E951BAC4D; Tue, 23 Aug 2005 18:41:03 +0200 (CEST) Date: Tue, 23 Aug 2005 18:41:00 +0200 From: Juergen Quittek To: Brian Trammell , Thomas Dietz Cc: Paul Aitken , boschi@fokus.fraunhofer.de, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] padding spec Message-ID: <457E2B3DB9B4A54FD03E97B8@[192.168.0.112]> In-Reply-To: <15A867B7-912B-4B9A-ADE7-E3E2EE590626@cert.org> References: <15A867B7-912B-4B9A-ADE7-E3E2EE590626@cert.org> 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 Hi Brian, Thanks for the comments. Please find replies inline. --On 8/23/2005 5:17 PM +0200 Brian Trammell wrote: > > I'd argue against deprecating padding; specific commentary is inline below. > > On Aug 23, 2005, at 9:50 AM, Thomas Dietz wrote: > >> Dear all, >> >> Do we really need padding on the wire? Since we have variable >> length IE's >> you cannot rely on the fact that a data value will not cross a 4-, >> 8- or >> whatever byte boundary. You have to walk byte by byte anyway. > > Not necessarily - a receiving implementation could verify that a given template > contains no variable length IE's and switch to a non- byte-walking codepath to > speed up receiving. I doubt that the achieved speed up justifies the resources required for implementing and maintaining two parallel code-paths. > A sending implementation could simply avoid sending templates > with variable length IEs when not necessary. A funny thing is that we just added a variable-length IE for padding. It might happen that the only variable-length IE you are using is the one for padding :-) >> If the styles of the machines change we need to change padding >> again. Now we >> have 32 or 64 bit machines. Maybe in 2 or 3 years we will have 128 bit >> machines. So you recode your application to have even more padding >> and wast >> bandwidth on the wire. > > The protocol doesn't - nor should it - require padding to any given > word boundary. If a sending implementation doesn't want to pad, that's fine. > However, the protocol should also not enjoin implementors using IPFIX to > communicate between two implementations they own to exploit word alignment > for performance benefit. The burden on receiver implementations to support > padding is minimal; I don't see what would be gained by its deprecation. I agree that the burden for the receiver is less. But a compliant receiver MUST implement padding because the exporter is free to use it or not. And my guess would be that implementing re-alignment at the receiver is even less burden that implementing padding. Since IEs in a record may be arbitrarily aligned anyway, I expect minimal advantages from padding of flow records only, even if you really care so much about performance that aligned or non-aligned records would make a difference at all. Therefore, also on the exporter side I do not see that implementing padding on the exporter could be worth the effort. > Regards, > > Brian Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de -- 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 Aug 23 14:30:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7dXQ-00037C-G7 for ipfix-archive@megatron.ietf.org; Tue, 23 Aug 2005 14:30:20 -0400 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 OAA21327 for ; Tue, 23 Aug 2005 14:30:18 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E7dRY-00075o-00 for ipfix-list@mil.doit.wisc.edu; Tue, 23 Aug 2005 13:24:16 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E7dRX-00075j-00 for ipfix@net.doit.wisc.edu; Tue, 23 Aug 2005 13:24:15 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 23 Aug 2005 20:24:14 +0200 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 j7NIOBVP011198; Tue, 23 Aug 2005 20:24:12 +0200 (MEST) Received: from [144.254.112.59] (edin-comm-vl10-dhcp39.cisco.com [144.254.112.59]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA25971; Tue, 23 Aug 2005 19:24:10 +0100 (BST) Message-ID: <430B69CA.6060800@cisco.com> Date: Tue, 23 Aug 2005 19:24:10 +0100 From: Andrew Johnson User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: Brian Trammell , Thomas Dietz , Paul Aitken , boschi@fokus.fraunhofer.de, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] padding spec References: <15A867B7-912B-4B9A-ADE7-E3E2EE590626@cert.org> <457E2B3DB9B4A54FD03E97B8@[192.168.0.112]> In-Reply-To: <457E2B3DB9B4A54FD03E97B8@[192.168.0.112]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all There are two padding ideas here and I'm not entiry sure what is being reference all the time: 1. The optional padding at the end of the flowset (to 32-bits) 2. The padding field within the records I think Thomas wants to deprecate 1, which I'm not really against, especially since you can't always pad AND it's optional anyway. I think the advantage of getting rid of it is that the collector should handle non-aligned records anyway and it removes the area of likely bugs where a variable-length field CAN make the records too small to pad, even if they are never sent that small. i.e. exporter pads and the collector assumes it doesn't. Since IPFIX can be used for a lot of things then I think the padding field is a good thing. The padding field is of a selectable size so you can use it for 64-bit, 128-bit etc in the future. If someone wants to export records all nicely aligned using padding then they can. More inline. Juergen Quittek wrote: > Hi Brian, > > Thanks for the comments. Please find replies inline. > > --On 8/23/2005 5:17 PM +0200 Brian Trammell wrote: > >> >> I'd argue against deprecating padding; specific commentary is inline >> below. >> >> On Aug 23, 2005, at 9:50 AM, Thomas Dietz wrote: >> >>> Dear all, >>> >>> Do we really need padding on the wire? Since we have variable length IE's >>> you cannot rely on the fact that a data value will not cross a 4-, 8- or >>> whatever byte boundary. You have to walk byte by byte anyway. >> >> >> Not necessarily - a receiving implementation could verify that a given template >> contains no variable length IE's and switch to a non- byte-walking codepath to >> speed up receiving. I think certain senders and recievers can be designed to work together using IPFIX. It is certainly possible to optimise this solution with padding all the fields to certain boundries. > I doubt that the achieved speed up justifies the resources required for > implementing and maintaining two parallel code-paths. Maybe not in the general case, but that shouldn't be reason enough to remove it from the protocol. >> A sending implementation could simply avoid sending templates >> with variable length IEs when not necessary. > > > A funny thing is that we just added a variable-length IE for padding. > It might happen that the only variable-length IE you are using is the one > for padding :-) I wouldn't call the padding a variable-length IE (although I you could probably use it that way). Since you can choose the length in the template I would call it a selectable-length IE. This means that that a collector could have aligned and non-aligned paths for different templates that might work quite well. >>> If the styles of the machines change we need to change padding again. Now we >>> have 32 or 64 bit machines. Maybe in 2 or 3 years we will have 128 bit >>> machines. So you recode your application to have even more padding and wast >>> bandwidth on the wire. For the flowset padding we will not be changing the optional alignment from the 32-bit boundry to a higher boundry. For the padding withing records then you could optimise your sender/reciever pair for a certain application. I don't think there is any requirement that a reciever built to handle a certain application must handle ALL applications. If the application you are building a collector for always pads to an 8-byte boundry and never uses variable-length IEs, then by all means optimise for that use. >> The protocol doesn't - nor should it - require padding to any given >> word boundary. If a sending implementation doesn't want to pad, that's fine. >> However, the protocol should also not enjoin implementors using IPFIX to >> communicate between two implementations they own to exploit word alignment >> for performance benefit. The burden on receiver implementations to support >> padding is minimal; I don't see what would be gained by its deprecation. > > > I agree that the burden for the receiver is less. But a compliant receiver > MUST implement padding because the exporter is free to use it or not. And > my guess would be that implementing re-alignment at the receiver is even less > burden that implementing padding. Since IEs in a record may be arbitrarily > aligned anyway, I expect minimal advantages from padding of flow records only, > even if you really care so much about performance that aligned or non-aligned > records would make a difference at all. Therefore, also on the exporter side > I do not see that implementing padding on the exporter could be worth > the effort. I beleive you are looking at the case of a general purpose reciever. If you have a specific application in mind then I don't see the harm in optimising for that application, as long as you verify your assumptions and don't contradict the protocol spec. I think the case where the sender uses padding to neatly align all the data is a good example. You can have an optimal path for this, but you can verify the aligments from the incoming template before choosing that path. 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/ From HettieNewbe@kevlarinc.com Tue Aug 23 16:01:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7exV-0006x5-Ci for ipfix-archive@megatron.ietf.org; Tue, 23 Aug 2005 16:01:21 -0400 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 QAA29105 for ; Tue, 23 Aug 2005 16:01:18 -0400 (EDT) Received: from 200-158-228-35.dsl.telesp.net.br ([200.158.228.35] helo=kevlarinc.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E7epm-0002Fc-00 for ipfix-list@mil.doit.wisc.edu; Tue, 23 Aug 2005 14:53:23 -0500 From: "Hettie Newberry" To: "Geertje Eddy" Message-ID: <000901c5a81c$4c257100$44a2a8c0@oarsmanship> Subject: =?iso-8859-1?Q?Hi,_great_n=C8ws_CIA=EFS_V=ECAGRRA?= Date: Tue, 23 Aug 2005 14:53:14 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C5A7F2.634F6900" 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?200.158.228.35 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C5A7F2.634F6900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, have to wait long. Some little girl of about five opened the door for = Ivanattempt was made not only to catch the criminals, but to explain = all theirMargarita, and the moonlight warmed her pleasantly. Closing = her eyes, sheoccasionally calling on a neighbour.of shoeboxes could = be seen, and several citizenesses sat on little lowdressing room = from the corridor, where the signal bell was already ringing. Merci, = Varenukha replied in amazement, and with whom am I speaking?recognize = him, my friend! Though you ... again I must apologize, but Im = notcondemned men, and that is without doubt Ha-Nozri. And so? ... = Bravo! cried the foreigner. Bravo! You have perfectly = repeatedGoethe once refers to the devil as Junker Woland.out one thing = only: how it could be that he had just been talking withshaken with = tears and began to exclaim: Such a calamity, eh? Whats goingmagician, = as well as his thrice-cursed assistants, and yet it was absolutelylife. = But the front part, the formal part, which housed the sole = andfull moon, into a state of anxiety, suddenly clutching his neck, = looking ------=_NextPart_000_0006_01C5A7F2.634F6900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hi, do yo end l tion?
    u want to sp ess on your medica
     
    Just VISlT = EPharma p and S  70
    ccy-By-Mail = Sho AVE up to %
     
    VAL S VlAGRR  many other m
    lUUM ClALLl A and edications
     
    Tr pointed!
    y us and you will not be disap
     
    ------=_NextPart_000_0006_01C5A7F2.634F6900-- From majordomo@mil.doit.wisc.edu Tue Aug 23 17:21:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7gCs-00077A-Ia for ipfix-archive@megatron.ietf.org; Tue, 23 Aug 2005 17:21:18 -0400 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 RAA12662 for ; Tue, 23 Aug 2005 17:21:15 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E7g5S-0004Xz-00 for ipfix-list@mil.doit.wisc.edu; Tue, 23 Aug 2005 16:13:38 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E7g5R-0004Xt-00 for ipfix@net.doit.wisc.edu; Tue, 23 Aug 2005 16:13:37 -0500 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 216B61BAC4D; Tue, 23 Aug 2005 23:13:35 +0200 (CEST) Date: Tue, 23 Aug 2005 23:13:32 +0200 From: Juergen Quittek To: Andrew Johnson Cc: Brian Trammell , Thomas Dietz , Paul Aitken , boschi@fokus.fraunhofer.de, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] padding spec Message-ID: <2A28E3F79764C154F9F26A1E@[192.168.0.112]> In-Reply-To: <430B69CA.6060800@cisco.com> References: <430B69CA.6060800@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 Andrew, Thanks for your comments. Please find replies inline. --On 8/23/2005 8:24 PM +0200 Andrew Johnson wrote: > Hi all > > There are two padding ideas here and I'm not entiry sure what is being > reference all the time: > 1. The optional padding at the end of the flowset (to 32-bits) > 2. The padding field within the records > > > I think Thomas wants to deprecate 1, which I'm not really against, > especially since you can't always pad AND it's optional anyway. > I think the advantage of getting rid of it is that the collector > should handle non-aligned records anyway and it removes the area > of likely bugs where a variable-length field CAN make the records > too small to pad, even if they are never sent that small. i.e. > exporter pads and the collector assumes it doesn't. > > Since IPFIX can be used for a lot of things then I think the padding > field is a good thing. The padding field is of a selectable size so > you can use it for 64-bit, 128-bit etc in the future. If someone wants > to export records all nicely aligned using padding then they can. > > More inline. > > > Juergen Quittek wrote: >> Hi Brian, >> >> Thanks for the comments. Please find replies inline. >> >> --On 8/23/2005 5:17 PM +0200 Brian Trammell wrote: >> >>> >>> I'd argue against deprecating padding; specific commentary is inline >>> below. >>> >>> On Aug 23, 2005, at 9:50 AM, Thomas Dietz wrote: >>> >>>> Dear all, >>>> >>>> Do we really need padding on the wire? Since we have variable length IE's >>>> you cannot rely on the fact that a data value will not cross a 4-, 8- or >>>> whatever byte boundary. You have to walk byte by byte anyway. >>> >>> >>> Not necessarily - a receiving implementation could verify that a given template >>> contains no variable length IE's and switch to a non- byte-walking codepath to >>> speed up receiving. > > I think certain senders and recievers can be designed to work together > using IPFIX. It is certainly possible to optimise this solution with padding > all the fields to certain boundries. > >> I doubt that the achieved speed up justifies the resources required for >> implementing and maintaining two parallel code-paths. > > Maybe not in the general case, but that shouldn't be reason enough to remove > it from the protocol. > > >>> A sending implementation could simply avoid sending templates >>> with variable length IEs when not necessary. >> >> >> A funny thing is that we just added a variable-length IE for padding. >> It might happen that the only variable-length IE you are using is the one >> for padding :-) > > I wouldn't call the padding a variable-length IE (although I you could > probably use it that way). Since you can choose the length in the template > I would call it a selectable-length IE. This means that that a collector > could have aligned and non-aligned paths for different templates that > might work quite well. Based on the interop event we gave the padding IE (#210) the data type octetArray which definitely is a variable-length IE. >>>> If the styles of the machines change we need to change padding again. Now we >>>> have 32 or 64 bit machines. Maybe in 2 or 3 years we will have 128 bit >>>> machines. So you recode your application to have even more padding and wast >>>> bandwidth on the wire. > > For the flowset padding we will not be changing the optional alignment from > the 32-bit boundry to a higher boundry. For the padding withing records then > you could optimise your sender/reciever pair for a certain application. > > I don't think there is any requirement that a reciever built to handle a > certain application must handle ALL applications. If the application you > are building a collector for always pads to an 8-byte boundry and never > uses variable-length IEs, then by all means optimise for that use. In this case, please don't call your collector compliant with the IPFIX protocol specification. The exporter would be, though. >>> The protocol doesn't - nor should it - require padding to any given >>> word boundary. If a sending implementation doesn't want to pad, that's fine. >>> However, the protocol should also not enjoin implementors using IPFIX to >>> communicate between two implementations they own to exploit word alignment >>> for performance benefit. The burden on receiver implementations to support >>> padding is minimal; I don't see what would be gained by its deprecation. >> >> >> I agree that the burden for the receiver is less. But a compliant receiver >> MUST implement padding because the exporter is free to use it or not. And >> my guess would be that implementing re-alignment at the receiver is even less >> burden that implementing padding. Since IEs in a record may be arbitrarily >> aligned anyway, I expect minimal advantages from padding of flow records only, >> even if you really care so much about performance that aligned or non-aligned >> records would make a difference at all. Therefore, also on the exporter side >> I do not see that implementing padding on the exporter could be worth >> the effort. > > I beleive you are looking at the case of a general purpose reciever. If you > have a specific application in mind then I don't see the harm in optimising > for that application, as long as you verify your assumptions and don't > contradict the protocol spec. I think the case where the sender uses padding > to neatly align all the data is a good example. You can have an optimal path > for this, but you can verify the aligments from the incoming template before > choosing that path. Standards are about interoperability between different implementations. However, if a vendor sells me an IPFIX-compliant receiver, I expect from this software, that is can parse every IPFIX message that was created by a compliant IPFIX exporter. If you build a collector that only works well with a certain exporter, then it is NOT IPFIX-compliant and you do not need a standard at all. This is different for the exporter. Here you can streamline your implementation and only use a small subset of the IPFIX protocol, for example only fixed-length data types or no padding at all. > Andrew Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de -- 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 Aug 23 21:30:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7k65-000447-B2 for ipfix-archive@megatron.ietf.org; Tue, 23 Aug 2005 21:30:33 -0400 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 VAA23943 for ; Tue, 23 Aug 2005 21:30:31 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E7jnO-0002zs-00 for ipfix-list@mil.doit.wisc.edu; Tue, 23 Aug 2005 20:11:14 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E7jnM-0002zm-00 for ipfix@net.doit.wisc.edu; Tue, 23 Aug 2005 20:11:13 -0500 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id EDC8E1BAC4D; Wed, 24 Aug 2005 03:11:09 +0200 (CEST) Date: Wed, 24 Aug 2005 03:11:06 +0200 From: Juergen Quittek To: Andrew Johnson Cc: Brian Trammell , Thomas Dietz , Paul Aitken , boschi@fokus.fraunhofer.de, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] padding spec Message-ID: <497712E694F2DFA9A19CDDB4@[192.168.0.112]> In-Reply-To: <430B69CA.6060800@cisco.com> References: <430B69CA.6060800@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 Hi Andrew, My previous message was not very clear in some points. Here are the replies to the important points of your message. --On 8/23/2005 8:24 PM +0200 Andrew Johnson wrote: > Hi all > > There are two padding ideas here and I'm not entiry sure what is being > reference all the time: > 1. The optional padding at the end of the flowset (to 32-bits) > 2. The padding field within the records You are right. The discussion was not clear in this point. > I think Thomas wants to deprecate 1, which I'm not really against, > especially since you can't always pad AND it's optional anyway. > I think the advantage of getting rid of it is that the collector > should handle non-aligned records anyway and it removes the area > of likely bugs where a variable-length field CAN make the records > too small to pad, even if they are never sent that small. i.e. > exporter pads and the collector assumes it doesn't. I have no general problem with both ways of padding, (1) padding at the end of the data/template set and (2) padding with the padding IE. But we should not have something in the protocol that we consider to deprecate already at this stage. The padding IE (1) is fine for padding if we do not use variable-length IEs. We can use it such that there is no need for additional padding by other means at the end of the data set. If we use variable-length IEs in the flow records, then we also need variable-length padding. This is also possible with the padding IE, but has the problem that it cannot have a length of 0 and that it is potentially confusing that then the length of the padding IE is given as the number of padding octets minus one. But also here, we do not gain much with (2) padding at the end of the data set. A disadvantage of (1) is that we cannot use it for template sets. If an IPFIX message contains a template set followed by data sets, then we can only make sure that the data set is aligned if we use (2). But since field specifiers are anyway 32-bit aligned, I do not consider this a real problem. > Since IPFIX can be used for a lot of things then I think the padding > field is a good thing. The padding field is of a selectable size so > you can use it for 64-bit, 128-bit etc in the future. If someone wants > to export records all nicely aligned using padding then they can. I agree with Thomas and you that the padding IE is useful. It does not create additional effort at the collector, since the collector can treat it like any other IE. So the only padding we should discuss is (2) padding at the end of the data/template set. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 24 00:42:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7n5K-0006nM-1h for ipfix-archive@megatron.ietf.org; Wed, 24 Aug 2005 00:41:58 -0400 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 AAA29469 for ; Wed, 24 Aug 2005 00:41:54 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E7myp-0000lD-00 for ipfix-list@mil.doit.wisc.edu; Tue, 23 Aug 2005 23:35:15 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E7myo-0000ky-00 for ipfix@net.doit.wisc.edu; Tue, 23 Aug 2005 23:35:14 -0500 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.13) with ESMTP id j7O4ZBPe029631 for ; Wed, 24 Aug 2005 00:35:12 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id j7O4XTxD029594 for ; Wed, 24 Aug 2005 00:33:29 -0400 Received: from ioannes.indigo.cert.org (ioannes.indigo.cert.org [10.60.10.57]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id j7O4XSl0029592; Wed, 24 Aug 2005 00:33:29 -0400 (EDT) Received: from [10.117.0.35] (vpn-10-25-4-2.remote.cert.org [10.25.4.2]) by ioannes.indigo.cert.org (8.12.8/8.12.8/2.42.1.1) with ESMTP id j7O4XRpD018930; Wed, 24 Aug 2005 00:33:27 -0400 In-Reply-To: <457E2B3DB9B4A54FD03E97B8@[192.168.0.112]> References: <15A867B7-912B-4B9A-ADE7-E3E2EE590626@cert.org> <457E2B3DB9B4A54FD03E97B8@[192.168.0.112]> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-521913599" Message-Id: Cc: Thomas Dietz , Paul Aitken , boschi@fokus.fraunhofer.de, ipfix@net.doit.wisc.edu Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [ipfix] padding spec Date: Wed, 24 Aug 2005 00:33:21 -0400 To: Juergen Quittek X-Pgp-Agent: GPGMail 1.1 (Tiger) X-Mailer: Apple Mail (2.734) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000004 X-Scanned-By: MIMEDefang 2.52 on 192.88.209.10 Precedence: bulk Sender: majordomo listserver --Apple-Mail-1-521913599 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Juergen: Inline replies, as always. :) On Aug 23, 2005, at 12:41 PM, Juergen Quittek wrote: > Hi Brian, > > Thanks for the comments. Please find replies inline. > > --On 8/23/2005 5:17 PM +0200 Brian Trammell wrote: > >> >> I'd argue against deprecating padding; specific commentary is >> inline below. >> >> On Aug 23, 2005, at 9:50 AM, Thomas Dietz wrote: >> >> >>> Dear all, >>> >>> Do we really need padding on the wire? Since we have variable >>> length IE's >>> you cannot rely on the fact that a data value will not cross a 4-, >>> 8- or >>> whatever byte boundary. You have to walk byte by byte anyway. >>> >> >> Not necessarily - a receiving implementation could verify that a >> given template >> contains no variable length IE's and switch to a non- byte-walking >> codepath to >> speed up receiving. >> > > I doubt that the achieved speed up justifies the resources required > for > implementing and maintaining two parallel code-paths. The application I envision here is "recognizing" that a given IPFIX template corresponds to an existing (pre-IPFIX) record format, and passing control to existing software to handle same. You may well be right, though - I've not done the requisite profiling to back up my intuition that this is worth the effort. >> A sending implementation could simply avoid sending templates >> with variable length IEs when not necessary. >> > > A funny thing is that we just added a variable-length IE for padding. > It might happen that the only variable-length IE you are using is > the one > for padding :-) True enough :) ... We do still get to define fixed length paddingOctets octet arrays for padding, though, correct? (I'm primarily interested in using fixed padding for word alignment purposes, especially in using IPFIX templates to describe existing word-aligned record formats). >>> If the styles of the machines change we need to change padding >>> again. Now we >>> have 32 or 64 bit machines. Maybe in 2 or 3 years we will have >>> 128 bit >>> machines. So you recode your application to have even more padding >>> and wast >>> bandwidth on the wire. >>> >> >> The protocol doesn't - nor should it - require padding to any given >> word boundary. If a sending implementation doesn't want to pad, >> that's fine. >> However, the protocol should also not enjoin implementors using >> IPFIX to >> communicate between two implementations they own to exploit word >> alignment >> for performance benefit. The burden on receiver implementations to >> support >> padding is minimal; I don't see what would be gained by its >> deprecation. >> > > I agree that the burden for the receiver is less. But a compliant > receiver > MUST implement padding because the exporter is free to use it or > not. And > my guess would be that implementing re-alignment at the receiver is > even less > burden that implementing padding. Since IEs in a record may be > arbitrarily > aligned anyway, I expect minimal advantages from padding of flow > records only, > even if you really care so much about performance that aligned or > non-aligned > records would make a difference at all. Therefore, also on the > exporter side > I do not see that implementing padding on the exporter could be > worth the effort. As above, from the exporter's point of view, it may be worth it if the exporter already has word-aligned padded data to work with. The real point I'm trying to make here (and one I think has been adequately made by others) is that supporting padding requires little effort, is already in the protocol and information model, and adds some flexibility to the protocol in how information is represented that may incidentally ease implementation. Thanks, Brian --Apple-Mail-1-521913599 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.1 (Darwin) iD8DBQFDC/iU4/8LCZ4pwvYRAi3+AKDA0QwohxQZ5ZDHWvUP7fq9L8aSUACcDrd6 Hb2CrSjrNpndr2n0bzxN6uA= =TZ5a -----END PGP SIGNATURE----- --Apple-Mail-1-521913599-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 24 03:43:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7pup-0007Ei-UE for ipfix-archive@megatron.ietf.org; Wed, 24 Aug 2005 03:43:20 -0400 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 DAA04757 for ; Wed, 24 Aug 2005 03:43:18 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E7pmy-0005Md-00 for ipfix-list@mil.doit.wisc.edu; Wed, 24 Aug 2005 02:35:12 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E7pmx-0005MX-00 for ipfix@net.doit.wisc.edu; Wed, 24 Aug 2005 02:35:11 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C968015128; Wed, 24 Aug 2005 09:35:10 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipfix] padding spec Date: Wed, 24 Aug 2005 09:35:10 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0006_01C5A88F.1DB4B920" Message-ID: <88F766D04E6AF3409B39E60D7D933EB24FD562@europa.office> X-MS-Has-Attach: yes Thread-Topic: [ipfix] padding spec Thread-Index: AcWoZTxhDwyYU8xvTEqYSMu+aj3ovgAF7nhg From: "Thomas Dietz" To: "Brian Trammell" , "Juergen Quittek" Cc: "Paul Aitken" , , Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C5A88F.1DB4B920 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Brian, Find my comments inline... Regards, Thomas > -----Original Message----- > From: Brian Trammell [mailto:bht@cert.org] > Sent: Wednesday, August 24, 2005 6:33 AM > To: Juergen Quittek > Cc: Thomas Dietz; Paul Aitken; boschi@fokus.fraunhofer.de; > ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] padding spec > > Juergen: > > Inline replies, as always. :) > > On Aug 23, 2005, at 12:41 PM, Juergen Quittek wrote: > > > Hi Brian, > > > > Thanks for the comments. Please find replies inline. > > > > --On 8/23/2005 5:17 PM +0200 Brian Trammell wrote: > > > >> > >> I'd argue against deprecating padding; specific commentary is > >> inline below. > >> > >> On Aug 23, 2005, at 9:50 AM, Thomas Dietz wrote: > >> > >> > >>> Dear all, > >>> > >>> Do we really need padding on the wire? Since we have variable > >>> length IE's > >>> you cannot rely on the fact that a data value will not cross a 4-, > >>> 8- or > >>> whatever byte boundary. You have to walk byte by byte anyway. > >>> > >> > >> Not necessarily - a receiving implementation could verify that a > >> given template > >> contains no variable length IE's and switch to a non- > byte-walking > >> codepath to > >> speed up receiving. > >> > > > > I doubt that the achieved speed up justifies the resources > required > > for > > implementing and maintaining two parallel code-paths. > > The application I envision here is "recognizing" that a given IPFIX > template corresponds to an existing (pre-IPFIX) record format, and > passing control to existing software to handle same. You may well be > right, though - I've not done the requisite profiling to back up my > intuition that this is worth the effort. > > >> A sending implementation could simply avoid sending templates > >> with variable length IEs when not necessary. > >> > > > > A funny thing is that we just added a variable-length IE > for padding. > > It might happen that the only variable-length IE you are using is > > the one > > for padding :-) > > True enough :) ... We do still get to define fixed length > paddingOctets octet arrays for padding, though, correct? (I'm > primarily interested in using fixed padding for word alignment > purposes, especially in using IPFIX templates to describe existing > word-aligned record formats). The only IE for padding I saw in the drafts so far was paddingOctet which had a fixed length of 1 byte (and was not extendible). So what you describe here (fixed length IE) was not in any draft. Maybe we can discuss if we want the fixed length IE or the variable length IE or both IE's for padding. I personally think only the fixed length IE makes sense at all. > > >>> If the styles of the machines change we need to change padding > >>> again. Now we > >>> have 32 or 64 bit machines. Maybe in 2 or 3 years we will have > >>> 128 bit > >>> machines. So you recode your application to have even more padding > >>> and wast > >>> bandwidth on the wire. > >>> > >> > >> The protocol doesn't - nor should it - require padding to any given > >> word boundary. If a sending implementation doesn't want to pad, > >> that's fine. > >> However, the protocol should also not enjoin implementors using > >> IPFIX to > >> communicate between two implementations they own to exploit word > >> alignment > >> for performance benefit. The burden on receiver > implementations to > >> support > >> padding is minimal; I don't see what would be gained by its > >> deprecation. > >> > > > > I agree that the burden for the receiver is less. But a compliant > > receiver > > MUST implement padding because the exporter is free to use it or > > not. And > > my guess would be that implementing re-alignment at the > receiver is > > even less > > burden that implementing padding. Since IEs in a record may be > > arbitrarily > > aligned anyway, I expect minimal advantages from padding of flow > > records only, > > even if you really care so much about performance that aligned or > > non-aligned > > records would make a difference at all. Therefore, also on the > > exporter side > > I do not see that implementing padding on the exporter could be > > worth the effort. > > As above, from the exporter's point of view, it may be worth it if > the exporter already has word-aligned padded data to work with. But you only can add padding at the end of the record! * So if you pad the data corresponding to a IE (e.g. You have a unsigned16 IE and you pad it to 32 bit) you have to remove this padding anyway if the IE is not the last in the record. * If you have padding at the end of the data then it is only one small operation to remove that padding. > > The real point I'm trying to make here (and one I think has been > adequately made by others) is that supporting padding > requires little > effort, is already in the protocol and information model, and adds > some flexibility to the protocol in how information is represented > that may incidentally ease implementation. > > Thanks, > > Brian > > ------=_NextPart_000_0006_01C5A88F.1DB4B920 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 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDgyNDA3MzUwOFowIwYJKoZIhvcNAQkEMRYEFFndRfOE 7YhOlvyRDSCCdBpLW/zmMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPUXUwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDD1F1MA0GCSqGSIb3DQEBAQUABIIBAKg9CcoSt4nl1w+KRXR+ TOogVjv402B1pu/o/qOnh/+CnZK0PzfI+KcHgtm2KYIQGfmi7jsF93PBgdVtYl9pbl92ZEYajVAU yAheryVw/CB5h6dIb+B3BfWNCeqr5SpLG7sFA2aE8aEm8SCGqTOC0EHvwDpB2qgxUEPRlr+/Mn05 +5bE2WRCq4FFyFsr3001gDGurDGiM2m9LmX9oGN7/yfveJn666Vf+eMjYSMyYJEO9U8XSQlL1gVa MJGLf2Cwjlwggq8IKhPWD6+J7CUGXsjTTunPmjPwrY6d73qTbMLa2c+0dqFKmjRBHZYz8O5nMs64 xuEoAaV+lt4YOGfbfuMAAAAAAAA= ------=_NextPart_000_0006_01C5A88F.1DB4B920-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 24 06:17:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7sKK-0005yj-1K for ipfix-archive@megatron.ietf.org; Wed, 24 Aug 2005 06:17:48 -0400 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 GAA11241 for ; Wed, 24 Aug 2005 06:17:45 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E7s1q-0001JF-00 for ipfix-list@mil.doit.wisc.edu; Wed, 24 Aug 2005 04:58:42 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E7s1p-0001JA-00 for ipfix@net.doit.wisc.edu; Wed, 24 Aug 2005 04:58:41 -0500 Received: from [192.168.0.112] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 53FCA1BAC4D; Wed, 24 Aug 2005 11:58:39 +0200 (CEST) Date: Wed, 24 Aug 2005 11:58:37 +0200 From: Juergen Quittek To: ipfix@net.doit.wisc.edu Cc: Paul Aitken , boschi@fokus.fraunhofer.de, Thomas Dietz , Brian Trammell Subject: Padding summary, was: [ipfix] padding spec Message-ID: In-Reply-To: <88F766D04E6AF3409B39E60D7D933EB24FD562@europa.office> References: <88F766D04E6AF3409B39E60D7D933EB24FD562@europa.office> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, This is a try to summarize the discussion on padding. Since the last version (-10) of the info model we have an Information Element for padding of type octetArray. The protocol allows using encoding it as a fixed-length array as well as a variable length array. As a reminder, an IPFIX message is structures as follows: - IPFIX message contains sets - set contains records - data record contains Information Elements (IEs) - template record contains IE specifiers Alignment of IEs within a data record The padding IE gives us flexible means for aligning IEs within a data record. Aligning within a data record can be useful, because you may very easily convert internal data structures into flow records at the exporter and vice versa at the collector. Alignment of IE specifiers within a template record We do not have means for aligning IE specifiers within template records, but there is a limited need for it and IE specifiers are aligned to 32-bit address boundaries anyway. Alignment of records within a set We do not have explicit means for aligning records within a set. However, for template records the need is limited and they are aligned to 32-bit boundaries anyway. For data records we can use padding IEs at the end of a the record extending the length of the record to the next alignment boundary. Note that this way also the sets are aligned (up to 32-bit boundaries) within an IPFIX message, because also at the end of the last records within a set there is a padding IE. Alignment of sets within an IPFIX message If records are already aligned within a set by using padding IEs, then this alignment is probably already achieved. But for aligning sets within an IPFIX message, the protocol further means, as described in section 3.3.1 of the protocol document. This padding mechanism can be applied even if the records within sets are not aligned. Conclusion In my view, the main point of our discussion is whether it makes sense having this additional padding mechanism. I see advantages of padding within a record for aligning internal data structures and flow records. But I see very little advantage in aligning sets if the sets and their contained flow records are not aligned also. Consequently, I suggest removing the padding at the end of a set from the protocol specification. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de -- 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 Liviu@jackwelch.com Wed Aug 24 10:01:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7vok-0003ls-KK for ipfix-archive@megatron.ietf.org; Wed, 24 Aug 2005 10:01:26 -0400 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 KAA21901 for ; Wed, 24 Aug 2005 10:01:24 -0400 (EDT) Received: from 84-122-229-18.onocable.ono.com ([84.122.229.18] helo=jackwelch.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E7vhn-0007dY-00 for ipfix-list@mil.doit.wisc.edu; Wed, 24 Aug 2005 08:54:15 -0500 From: "Liviu Delong" To: "Giada Murillo" Message-ID: <000601c5a8b3$4e86da00$107fa8c0@spiraea> Subject: =?iso-8859-1?Q?Works_Wond=EAr_CIA=EES_V=ECAGRRA?= Date: Wed, 24 Aug 2005 08:54:12 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C5A889.65B0D200" 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?84.122.229.18 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C5A889.65B0D200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Hey, Barguzin [3] ... make the waves rise and fall! ... bawled the = `Thats them coming to arrest us, Azazello replied and drank off = afangs, and deftly offered him one of the dark oaken tabourets. There = were noCommission...was no longer in sight. He ran. At times he had to = drop down right in the Devil knows how! the redhead replied = casually. `I suppose, however,the procurator. There was not a = grain of doubt left that the mysterious consultant hadthese difficulties = had to be overcome at whatever cost. The experienced There were = no grown-ups in the room, evidently they had all run out ofon its left = leg, obviously clowning, dragging it, working it in syncopationwithout = a trace.frequently in this context). The same combination will reappear = in Nikanor She has! Kanavkin cried dashingly.grinding his teeth. = No, no, today, today without fail! Ivan cried out in alarm. ------=_NextPart_000_0003_01C5A889.65B0D200 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hi, do  d less on?
    you want to spen  on your medicati
     
    Just VISlT = E op and SAV 0
    Pharmaccy-By-Mail = Sh E up to 7 %
     
    VALlUU lS V other medication
    M ClALL lAGRRA and many  s
     
    Try us ot be disappointed!
     and you will n
     
    ------=_NextPart_000_0003_01C5A889.65B0D200-- From majordomo@mil.doit.wisc.edu Thu Aug 25 10:48:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8J1x-0000fb-Nm for ipfix-archive@megatron.ietf.org; Thu, 25 Aug 2005 10:48:37 -0400 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 KAA21574 for ; Thu, 25 Aug 2005 10:48:35 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E8Iht-0005uE-00 for ipfix-list@mil.doit.wisc.edu; Thu, 25 Aug 2005 09:27:53 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E8Ihs-0005u9-00 for ipfix@net.doit.wisc.edu; Thu, 25 Aug 2005 09:27:52 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 25 Aug 2005 16:27:51 +0200 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 j7PERmVP007019; Thu, 25 Aug 2005 16:27:49 +0200 (MEST) Received: from [144.254.112.63] (edin-comm-vl10-dhcp43.cisco.com [144.254.112.63]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA18815; Thu, 25 Aug 2005 15:27:47 +0100 (BST) Message-ID: <430DD563.9050202@cisco.com> Date: Thu, 25 Aug 2005 15:27:47 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.8) Gecko/20050603 Fedora/1.7.8-1.2.1.legacy X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Juergen Quittek CC: ipfix@net.doit.wisc.edu Subject: [ipfix] IPFIX INFO draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jeurgen, 5.3.29 headerLengthIPv4 Description: The length of the IPv4 header. Abstract Data Type: octet ElementId: 207 Status: current Units: octets Reference: See RFC 791 for the specification of the IPv4 header. Can we change the units of this to 32 bit words, since that's how IHL is defined in the IPv4 header? 5.3.30 packetLengthIPv4 Description: The total length of the IPv4 packet. Abstract Data Type: unsigned16 ElementId: 190 Status: current Units: octets Reference: See RFC 791 for the specification of the IPv4 total length. If this is the total length field from the IPv4 header, then shouldn't we call it totalLengthIPv4 ? 5.7.5 ipv4Options Abstract Data Type: unsigned64 Data Type Semantics: flags ElementId: 208 Can we insert a diagram and table, similar to ipv6OptionHeaders #64? Finally, what's happening with #204, #205 and #206? o Are we leaving them undefined? If so, are they available for new elements, or are they reserved? o Or should we move #207 to #210 down, so there's no gap? 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 NicodeFou_7303@kfix.com Fri Aug 26 12:44:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hJN-0005F8-H1 for ipfix-archive@megatron.ietf.org; Fri, 26 Aug 2005 12:44:13 -0400 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 MAA01174 for ; Fri, 26 Aug 2005 12:44:09 -0400 (EDT) Received: from 218-160-246-17.dynamic.hinet.net ([218.160.246.17] helo=kfix.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E8h13-0000Ny-00 for ipfix-list@mil.doit.wisc.edu; Fri, 26 Aug 2005 11:25:18 -0500 From: "Nicode Fournier" To: "Lessie Beach" Message-ID: <001f01c5aa5a$b592c300$6244a8c0@perforator> Subject: =?iso-8859-1?Q?Need_to_pres=CAnt_CIAlS_VIAGRR=E1?= Date: Fri, 26 Aug 2005 11:25:02 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C5AA30.CCBCBB00" 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_001C_01C5AA30.CCBCBB00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable and finally a door banged on the fifth floor. Poplavsky froze. Yes, those = intelligent woman, and of course have already guessed who our host is. last = rays. Your story is extremely interesting, Professor, though it does not To cut = the ropes, answered Levi. in Yalta now! Its ridiculous! is the most terrible = vice! When the storms ended and sultry summer came, there appeared in the `It = cant be! the small one whispered, amazed. This is something chairmans = apartment, melting with curiosity. and at once reassured him completely, saying = that it was, of course, one of turning up in the cigarette case, as by the = cigarette case itself. It was of disdain. `I renounced it, as I generally did = everything in life. Lets withdrew into the palace. the barman cheered up = considerably. The professor categorically maintained fact, as they say, is a = fact, and to brush it aside without explanations is ------=_NextPart_000_001C_01C5AA30.CCBCBB00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, do you wapend Iess on youcations?=
    nt to sr meddi
     
    Just = VISlT USPharmaccy-By-hop and = SAVo 70
    Mail SE up = t%
     
    ications
    VlS VlAGRany other = med
    ALlUUM ClALLRA and m
     
    <= /TR>
    Try nt= ed!
    us and you will not be disappoi
    ------=_NextPart_000_001C_01C5AA30.CCBCBB00-- From crocettntjtdreese@telusmail.net Sat Aug 27 17:38:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E98NT-0000pM-9J for ipfix-archive@megatron.ietf.org; Sat, 27 Aug 2005 17:38:16 -0400 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 RAA01276 for ; Sat, 27 Aug 2005 17:38:11 -0400 (EDT) From: crocettntjtdreese@telusmail.net Received: from 0x535e7d28.odnxx4.adsl-dhcp.tele.dk ([83.94.125.40]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E97xJ-0000Ne-00 for ipfix-list@mil.doit.wisc.edu; Sat, 27 Aug 2005 16:11:15 -0500 Message-ID: <004801c5ab4b$d8e96b00$b23fa8c0@decompose> Subject: =?iso-8859-1?Q?Re:_Everything_f=D5r_you_CIA=ECS_VIAGRR=E1?= Date: Sat, 27 Aug 2005 16:11:10 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01C5AB21.F0136300" 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?83.94.125.40 This is a multi-part message in MIME format. ------=_NextPart_000_0045_01C5AB21.F0136300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable up on the window-sill and, throwing back his sharp muzzle, howled savagely = And, at last, by a happy fate ... of nowhere, huge as a hog, black as soot or = as a rook, and with a desperate `I remember! I remember! Theyve opened a new = Georgian tavern in at once entered into the conversation: agitation, which = could be seen even from afar. Flushed spots burned on his Whats this? Kuzmin = said contemptuously. the sixth entrance, while the second opened the normally = boarded-up little leaf floated in some liquid. Aint misbehaving, aint bothering = anybody, just reparating my At that moment a headless skeleton with a torn-off = arm emerged from the file of legionaries is not quite true. There was one = person, but he simply It turned out that the manager of the city affiliate, who = has made a the fragmented sun glittering in thousands of windows facing west, = and at hands of servants behind Pilates back. Three lamps appeared on the table = appeared dubious to him: for all he knew, the thought might get rooted in ------=_NextPart_000_0045_01C5AB21.F0136300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    HeIlo,nd Iess = on s?
     do you = want to speyour meddication
     
    =
    Just VISlT EPhahop and SAVo 70
    rrma SE up t%
     
    VLLlS VlA= r medicatio= n
    ALlUUM = ClAGRRA and many othes
     
    Dols!=
    n't miss the Hot Specia
    ------=_NextPart_000_0045_01C5AB21.F0136300-- From mandy@developershed.com Sun Aug 28 18:18:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9VTc-000222-J2 for ipfix-archive@megatron.ietf.org; Sun, 28 Aug 2005 18:18:08 -0400 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 SAA15205 for ; Sun, 28 Aug 2005 18:18:05 -0400 (EDT) Received: from a213-22-48-134.cpe.netcabo.pt ([213.22.48.134] helo=developershed.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E9V9O-0006GA-00 for ipfix-list@mil.doit.wisc.edu; Sun, 28 Aug 2005 16:57:16 -0500 From: "Mandy Plunkett" To: "Jewel Cervantez" Subject: =?iso-8859-1?Q?Re:_Economize_more_VIAGRR=C4?= Date: Sun, 28 Aug 2005 16:57:04 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C5ABF1.84003000" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Baalamb 4.10 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?213.22.48.134 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C5ABF1.84003000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable give in. A writer is defined not by any identity card, but by what he = interwoven parts, one set in contemporary Moscow, the other in ancient Money, = the artiste went on, must be kept in the state bank, in There, its beginning, = said the master. and to Ivan he said: But I dont advise you to write today. = On-stage appeared a short, fair-haired citizen, who, judging by his Bedsornev = was not there! archives has made known of this process. Eh, thats not the = point right now, Ababkov droned, its that its I was mistaken! Levi cried in a = completely hoarse voice. You are a the shirt-front and tailcoat. The headless = body paddled its feet somehow marionette theatre in Zamoskvorechye. In this = theatre he no longer had to through it together with his primus. of the post. = The body, with its protruding ribs, gave a start. The beside the hog on a = string, and the hogs hat kept sliding down over his account forms the second = chapter, entitled The Gospel of Woland. ------=_NextPart_000_0031_01C5ABF1.84003000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Good = day, l sh
    = Welcome to The One Of The Leading onIine pharmaceuticaops
     
    SAV60ur phmccy-By-Mail Sho
    E = Over % on yoarmacy with US Pharp
     
    VALlUlALlS = VlAGr medicat
    = M CRA and many otheions
    ------=_NextPart_000_0031_01C5ABF1.84003000-- From paulkarlsen@sensewave.com Sun Aug 28 22:06:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Z2L-0001P6-CX for ipfix-archive@megatron.ietf.org; Sun, 28 Aug 2005 22:06:13 -0400 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 WAA24558 for ; Sun, 28 Aug 2005 22:06:10 -0400 (EDT) Received: from [211.59.203.171] (helo=myfunnymail.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E9Yva-00025J-00 for ipfix-list@mil.doit.wisc.edu; Sun, 28 Aug 2005 20:59:14 -0500 Received: from sensewave.com (mailfront.server.freewave.no [62.73.196.124]) by myfunnymail.com (Postfix) with ESMTP id C2E899C15B for ; Mon, 29 Aug 2005 09:47:44 -0700 From: "Pimps G. Chigger" To: Ipfix Subject: =?windows-1251?B?SXBmaXgsIEdvb2Qgb2ZmZXJzIG9mIHdvcmsuIFdvcmsgb2YgYSBobw==?= =?windows-1251?B?dXNl?= Date: Mon, 29 Aug 2005 09:47:44 -0700 Message-ID: <001001c5acb9$cfb73788$c12bb587@sensewave.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2505.0000 X-AntiVirus: OK! AntiVir MailGate Version 2.0.1; AVE: 6.15.0.0; VDF: 6.15.0.6 Content-Transfer-Encoding: base64 RGVhciBTaXIvTWFkYW0uDQoNCkFyZSB5b3UgcmVhbGx5IGxvb2tpbmcgZm9yIGpvYj8NCg0K T25lIG9mIHRoZSBiaWdnZXN0IEZpbmFuY2UgQ29tcGFueSBvZiBFYXN0IEV1cm9wZSBpcyBn bGFkIHRvIG9mZmVyDQpleGNlbGxlbnQgd29yayBwcm92aWRpbmcgcmVhbCBtb25leSB0byB5 b3UhISBObyBuZWVkIHRvIGludmVzdCBvciBidXkNCnByb2R1Y3RzIGluIG9yZGVyIHRvIHdv cmsgd2l0aCB1cy4NCg0KTm8gbW9uZXkgdG8gc3RhcnQ/DQoNCkFib3V0IHVzOg0KDQogRmlu YW5jZSBDb21wYW55LCBMaXRodWFuaWEgIHdhcyBmb3VuZGVkIGluIDE5OTUgYnkgYSB0ZWFt IG9mIA0KYW50aXF1aXRpZXMNCmV4cGVydHMuIEJ5IG5vdyBvdXIgY29tcGFueSBoYXMgZ3Jv d24gZnJvbSBhIHNtYWxsIGNvbXBhbnkgd2l0aCA3DQplbXBsb3llZXMgdG8gYW4gaW50ZXJu YXRpb25hbCBncm91cCB3aXRoIHNldmVyYWwgcmVwcmVzZW50YXRpdmUgb2ZmaWNlcw0KaW4g ZGlmZmVyZW50IGNvdW50cmllcyBvZiB0aGUgd29ybGQuIE5vd2FkYXlzIHdlIGFyZSBub3Qg anVzdCBzZWxsaW5nIA0KYW5kDQpidXlpbmcgYW50aXF1ZXMsIGJ1dCBhcmUgYWxzbyBkZWFs aW5nIHdpdGggb3JnYW5pemF0aW9ucyBvZiANCmludGVybmF0aW9uYWwNCmV4aGliaXRpb25z LCBzZW1pbmFycywgdG91cnMgYW5kIG1hbnkgb3RoZXIgdGhpbmdzLiBGb3IgbW9yZSANCmlu Zm9ybWF0aW9uOg0KaHR0cDovL3JlYWxqb2ItaW53b3JsZC5jb20NCg0KT3VyIHZhY2FuY2ll czoNCg0KTm93IGNsaWVudHMgb2Ygb3VyIGNvbXBhbnkgY29uZHVjdCBmaW5hbmNpYWwgb3Bl cmF0aW9ucyBhbGwgb3ZlciB0aGUgDQp3b3JsZA0KaW5jbHVkaW5nIE5ldyBaZWxhbmQgYnV0 IGR1ZSB0byBzdWZmaWNpZW50IHBlcmZlY3Rpb24gaW4gQmFua2luZyANClNlcnZpY2UNCndl IGhhdmUgc29tZSBkaWZmaWN1bHRpZXMgaW4gdHJhbnNsYXRpb24gYW5kIHJlb3JnYW5pemF0 aW9uIG9mIG91cg0KYnVzaW5lc3MsIHRoZXJlZm9yZSB3ZSBhcmUgcGxhbm5pbmcgdG8gb3Bl biBicmFuY2hlcyBpbiB3aGljaCB3ZSANCnJlcXVpcmUNCk5ldyBaZWxhbmQuICBOb3cgd2Ug YXJlIGxvb2tpbmcgZm9yIGZpbmFuY2lhbCBhc3Npc3RhbnRzIHdobyB3aWxsIGJlDQpyZXNw b25zaWJsZSB0byBhY2NlcHQgcGF5bWVudHMgZnJvbSBvdXIgY2xpZW50cy4gQXQgdGhpcyBt b21lbnQgd2UgDQpwcm92aWRlDQphbmQgb2ZmZXIgd29yayBhdCBob21lLCBhZnRlciBvcGVu aW5nIG9mZmljZXMgaW4gTmV3IFplbGFuZCAgeW91IHdpbGwgDQpoYXZlDQphbiBvcHBvcnR1 bml0eSBmb3Igd29ya2luZyBpbiBvdXIgb2ZmaWNlcyBhcyB3ZWxsLg0KDQogVG9kYXkgd2Ug YXJlIGxvb2tpbmcgZm9yIGZpbmFuY2lhbCBhc3Npc3RhbnRzIHRoYXQgd2lsbCBiZSANCnJl c3BvbnNpYmxldG8NCmFjY2VwdCBwYXltZW50cyBmcm9tIGNsaWVudHMgdGhyb3VnaCBiYW5r IHRyYW5zZmVyLCBiZWNhdXNlIG9mDQppbXBlcmZlY3Rpb24gb2YgYmFuayBzeXN0ZW0uIE5l dyBaZWxhbmRzIHBhcnRuZXJzIG9mIG91ciBjbGllbnRzIGhhdmUNCnNvbWUgZGlmZmljdWx0 aWVzIHdpdGggc2VuZGluZyBiYW5rIHRyYW5zbGF0aW9ucyBhbmQgY2hlcXVlcyB0byBFYXN0 DQpFdXJvcGUuIFlvdSBjYW4gbWFrZSAxMCAlIGNvbW1pc3Npb24gZnJvbSBldmVyeSB0cmFu c2ZlciB5b3Ugd2lsbCANCnJlY2VpdmUNCnRocm91Z2ggcmVsYXRpdmUgdG8gb3VyIGJ1c2lu ZXNzLiBUaGUgcmVzdCBuZWVkcyB0byBiZSB0cmFuc2ZlcnJlZCB0byANCm91cg0KY29tcGFu eSdzIHJlcHJlc2VudGF0aXZlIGJ5IFdlc3Rlcm4gVW5pb247IGFsbCBXZXN0ZXJuIFVuaW9u IGZlZXMgYXJlDQpwYWlkIGJ5IHVzLiBPbiBhdmVyYWdlIHlvdSB3aWxsIGJlIG1ha2luZyAy LDAwMCBVUyBEb2xsYXJzIHBlciB3ZWVrLg0KDQogV2UgYmVsaWV2ZSB0aGF0IHlvdSBjYW4g Z2V0IGdvb2QgZnV0dXJlIGFuZCBhY2hpZXZlbWVudHMgaW4gb3VyIA0KYnVzaW5lc3MuDQpJ ZiBvdXIgb2ZmZXIgaXMgaW50ZXJlc3RpbmcgdG8geW91LCBwbGVhc2UgZmVlbCBmcmVlIGlu IHNlbmRpbmcgYSBtYWlsIA0KdG8NCm91ciBIUiBvZmZpY2UuIEZvciBtb3JlIGluZm9ybWF0 aW9uIG91ciBjcmV3IG9mIEh1bWFuIFJlc291cmNlcyBpcyANCnJlYWR5DQp0byBhbnN3ZXIg YWxsIHlvdXIgcXVlc3Rpb25zLg0KDQogSWYgeW91IGFyZSByZWFkeSB0byBiZWdpbiB3b3Jr IHdpdGggdXMgZG8gbWFrZSByZWdpc3RyYXRpb24gb24gdGhlIA0Kc2l0ZQ0KYW5kIHJlY2Vp dmUgeW91ciBwZXJzb25hbCBhY2NvdW50IGZyb20gb3VyIHNpdGUuIEFmdGVyIHJlZ2lzdHJh dGlvbiANCndpdGgNCnVzIG9uIHRoZSBzaXRlIHdlIHdpbGwgc2VuZCB5b3UgYW4gZS1tYWls IGNvbnRyYWN0IGR1cmluZyAyNCBob3VycyBhbmQgDQp3ZQ0Kc2hhbGwgc3RhcnQgdG8gd29y ayB3aXRoIHlvdSBhdCBvbmNlLiBQbGVhc2UgZ28NCmh0dHA6Ly9yZWFsam9iLWlud29ybGQu Y29tIGNsaWNrICJSRUdJU1RFUiINCg0KQmVzdCBSZWdhcmRzDQpSZWFsIEpvYi0gSW53b3Js ZCBDb21wYW55IExpdGh1YW5pYQ0KY29udGFjdEByZWFsLWpvYi1pbndvcmxkLmNvbQ0KDQo= From majordomo@mil.doit.wisc.edu Mon Aug 29 10:14:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9kOk-0002Vd-Ii for ipfix-archive@megatron.ietf.org; Mon, 29 Aug 2005 10:14:06 -0400 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 KAA11884 for ; Mon, 29 Aug 2005 10:14:04 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E9k5l-0006H7-00 for ipfix-list@mil.doit.wisc.edu; Mon, 29 Aug 2005 08:54:29 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E9k5j-0006H2-00 for ipfix@net.doit.wisc.edu; Mon, 29 Aug 2005 08:54:28 -0500 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 030861BAC4D; Mon, 29 Aug 2005 15:54:25 +0200 (CEST) Date: Mon, 29 Aug 2005 15:54:32 +0200 From: Juergen Quittek To: Paul Aitken Cc: ipfix@net.doit.wisc.edu Subject: [ipfix] Re: IPFIX INFO draft Message-ID: <018355F0A1B887E6A39C80B5@[10.1.1.171]> In-Reply-To: <430DD563.9050202@cisco.com> References: <430DD563.9050202@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 Hi Paul, Thanks for the suggestions. Please find some replies inline. --On 8/25/2005 4:27 PM +0200 Paul Aitken wrote: > Jeurgen, > > > 5.3.29 headerLengthIPv4 > > Description: > The length of the IPv4 header. > Abstract Data Type: octet > ElementId: 207 > Status: current > Units: octets > Reference: > See RFC 791 for the specification of the IPv4 header. > > Can we change the units of this to 32 bit words, since that's how IHL is > defined in the IPv4 header? If we do so, we should mention the unit explicitly in the description, because in all other cases, we use octet a unit for IEs indicating a length. Are there any objections to Paul's proposal? > 5.3.30 packetLengthIPv4 > > Description: > The total length of the IPv4 packet. > Abstract Data Type: unsigned16 > ElementId: 190 > Status: current > Units: octets > Reference: > See RFC 791 for the specification of the IPv4 total length. > > If this is the total length field from the IPv4 header, then shouldn't > we call it totalLengthIPv4 ? Yes, it is. I am also fine with the name you suggest. > 5.7.5 ipv4Options > > Abstract Data Type: unsigned64 > Data Type Semantics: flags > ElementId: 208 > > Can we insert a diagram and table, similar to ipv6OptionHeaders #64? Yes. Can you provide them? > Finally, what's happening with #204, #205 and #206? > > o Are we leaving them undefined? > If so, are they available for new elements, > or are they reserved? > > o Or should we move #207 to #210 down, so there's no gap? I have a clear preference for the second option. Would you be fine with it? > Cheers. > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Aug 29 10:37:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9kl3-0006jt-LM for ipfix-archive@megatron.ietf.org; Mon, 29 Aug 2005 10:37:09 -0400 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 KAA13804 for ; Mon, 29 Aug 2005 10:37:07 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E9kVJ-0006oh-00 for ipfix-list@mil.doit.wisc.edu; Mon, 29 Aug 2005 09:20:53 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E9kVH-0006oc-00 for ipfix@net.doit.wisc.edu; Mon, 29 Aug 2005 09:20:52 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 29 Aug 2005 16:20:49 +0200 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 j7TEKkVP002674; Mon, 29 Aug 2005 16:20:47 +0200 (MEST) Received: from [10.61.64.58] (ams-clip-vpn-dhcp58.cisco.com [10.61.64.58]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA27485; Mon, 29 Aug 2005 15:20:46 +0100 (BST) Message-ID: <431319BC.1030500@cisco.com> Date: Mon, 29 Aug 2005 15:20:44 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.8) Gecko/20050603 Fedora/1.7.8-1.2.1.legacy X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Juergen Quittek CC: ipfix@net.doit.wisc.edu Subject: [ipfix] Re: IPFIX INFO draft References: <430DD563.9050202@cisco.com> <018355F0A1B887E6A39C80B5@[10.1.1.171]> In-Reply-To: <018355F0A1B887E6A39C80B5@[10.1.1.171]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen, >> 5.7.5 ipv4Options >> >> Abstract Data Type: unsigned64 >> Data Type Semantics: flags >> ElementId: 208 >> >> Can we insert a diagram and table, similar to ipv6OptionHeaders #64? > > > Yes. Can you provide them? No I cannot, because the definition does not make sense to me! The [INFO] text is clear: Options are mapped to bits according to their option numbers. Option number X is mapped to bit X. However, looking at http://www.iana.org/assignments/ip-parameters, I see a (sparse) list of 25 options numbered from 0 through 205. Since RFC 791 defines: The option-type octet is viewed as having 3 fields: 1 bit copied flag, 2 bits option class, 5 bits option number. it seems to me that [INFO] requires a 256 bit field. However, [INFO] has: Abstract Data Type: unsigned64 Data Type Semantics: flags So I simply don't understand how this object works. >> Finally, what's happening with #204, #205 and #206? >> >> o Are we leaving them undefined? >> If so, are they available for new elements, >> or are they reserved? >> >> o Or should we move #207 to #210 down, so there's no gap? > > > I have a clear preference for the second option. > Would you be fine with it? I would, provided it's done immediately and announced widely and clearly - because everyone who already has any IPFIX implimentation MUST immediately renumber their #207 - #210. Some people might object to that, and feel it's better to keep the existing numbering and simply reuse #204 - #206 for new elements. I would also be happy with that solution. Renumbering is better for a clean draft. However, leaving a gap seems technically preferable. 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 herodtmmartines@gellifawr.co.uk Mon Aug 29 12:07:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9mAl-0007EA-Tt for ipfix-archive@megatron.ietf.org; Mon, 29 Aug 2005 12:07:47 -0400 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 MAA18472 for ; Mon, 29 Aug 2005 12:07:44 -0400 (EDT) Received: from [207.144.42.120] (helo=gellifawr.co.uk) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E9m1d-0000lN-00 for ipfix-list@mil.doit.wisc.edu; Mon, 29 Aug 2005 10:58:23 -0500 From: "Herod Martines" To: "Wei Comacho" Subject: =?iso-8859-1?Q?Re:_nu_Our_new_great_offr_V=CEAGRRA?= Date: Mon, 29 Aug 2005 10:58:07 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01C5AC88.895C8980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Gingery fu 4.15 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_005E_01C5AC88.895C8980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable But of course! Didnt I say so! the administrator cried agitatedly. with the = procurators seat at Caesarea. During this time, Timofei Kondratievich = Kvastsov stood on the landing, there was also some actor, or not an actor... = with a gramophone in a little It must be said that Varenukhas response was = marked by a slight oddity groaning, nevertheless smiles a senseless, crazed = smile. Oh, city of Yershalaim! What does one not hear in it! A tax collector, = So, Frieda ... prompted Koroviev. They calmed Varenukha down the best they = could, said they would protect What can I do for you? - and was amazed, not = recognizing his own 7. Frieda: Her story is reminiscent of that of Gretchen = in Faust. B. V. thrown down in the semi-dark front hall, so well known to = him, of Styopa to read something written there ... It was the second time in = the same day formal originality, its devastating satire of Soviet life, and = of Soviet around. figure, but with somehow restless and importunate eyes. ------=_NextPart_000_005E_01C5AC88.895C8980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
     
    Gmaceutical s
    ood day, Welcome to The = One Of The Leading onIine pharhops
     
    S0ur pha S
    AVE Over 6% on = yormacy with E = Pha.rrmaccy By MaiIhop
     
    ALlUM Cl
    V..ALlS = VlAGther medica
    .RA and many otions
    ------=_NextPart_000_005E_01C5AC88.895C8980-- From majordomo@mil.doit.wisc.edu Mon Aug 29 13:44:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9nfx-0001m5-AA for ipfix-archive@megatron.ietf.org; Mon, 29 Aug 2005 13:44:05 -0400 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 NAA23167 for ; Mon, 29 Aug 2005 13:44:04 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1E9naW-0002oF-00 for ipfix-list@mil.doit.wisc.edu; Mon, 29 Aug 2005 12:38:28 -0500 Received: from cweg03.cweg.stud.uni-goettingen.de ([134.76.63.99] helo=mail.anderson.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1E9naU-0002nr-00 for ipfix@net.doit.wisc.edu; Mon, 29 Aug 2005 12:38:27 -0500 Received: from gate-mh.sernet.de ([193.159.216.158] helo=[192.168.42.180]) by mail.anderson.de with asmtp (Exim 4.20) id 1E9naT-00034b-VV for ipfix@net.doit.wisc.edu; Mon, 29 Aug 2005 19:38:26 +0200 Message-ID: <43134811.7030407@CS.Uni-Goettingen.DE> Date: Mon, 29 Aug 2005 19:38:25 +0200 From: Sven Anderson Organization: Institute for Informatics Goettingen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] info-model update: version -10 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Juergen, Juergen Quittek schrieb: > I just submitted a new version of the IPFIX info model to the > I-D repository. Until it gets posted you can preview it at > . > > Main changes include: > - rephrased section 2.3, third bullet item: > removed 'pre' prefix, elaborated 'post' prefix > - added paragraph 4 of section 5 on the 'post' prefix > - changed descriptions of all information element with > 'post' prefix > - reordered information elements with 'post' prefix such > that all of them immediately follow the corresponding > unprefixes element (if such an element exists). [...] > I hope, this is the version that will be submitted to the IETF. > If you think we still need more improvement, then please comment. On 4th of August I wrote a description of an alternative proposal to the middlebox issue. I'm wondering that there is no reaction at all to this. Is it really so much out of question? I'm fine with any reason, why it is not suitable, but I'd appreciate a short note about the reason. ;-) Thanks, Sven -- Sven Anderson Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de Georg-August-Universitaet Goettingen Lotzestr. 16-18, 37083 Goettingen, Germany -- 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 8arvandus@applelinks.net Mon Aug 29 20:31:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9u2G-00069p-PP for ipfix-archive@megatron.ietf.org; Mon, 29 Aug 2005 20:31:32 -0400 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 UAA26151 for ; Mon, 29 Aug 2005 20:31:31 -0400 (EDT) Received: from 69-169-199-128.sbtnvt.adelphia.net ([69.169.199.128]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1E9tju-00042T-00 for ipfix-list@mil.doit.wisc.edu; Mon, 29 Aug 2005 19:12:36 -0500 Message-ID: From: "Richard K. Lee" <8arvandus@applelinks.net> To: ipfix-list@mil.doit.wisc.edu Subject: =?iso-8859-1?B?VmlhZ3JhIC0gZHV0eS1mcmVlIHByaWNl?= Date: Mon, 29 Aug 2005 23:56:02 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_15D01102.4E362852" 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_15D01102.4E362852 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_12C2B698.CA990EB6" ------=_NextPart_001_0001_12C2B698.CA990EB6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Full erection No prescription asked 2 popular medicines: CIALIS - http://www.pillsofpassion.biz/sv/ VIAGRA - http://www.pillsofpassion.biz/vt/ Discreet packaging _________________________________________________________________________ To change your mail details, go here _________________________________________________________________________ ------=_NextPart_001_0001_12C2B698.CA990EB6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

    Full erection
    No prescription asked

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

    Discreet packaging


    _________________________________________________________________________
    To change your mail details, go here
    _________________________________________________________________________

    ------=_NextPart_001_0001_12C2B698.CA990EB6-- ------=_NextPart_000_0000_15D01102.4E362852-- From knecmalam@wems.com Tue Aug 30 07:02:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA3t3-0002ti-A4 for ipfix-archive@megatron.ietf.org; Tue, 30 Aug 2005 07:02:41 -0400 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 HAA04944 for ; Tue, 30 Aug 2005 07:02:37 -0400 (EDT) Received: from c-bg-d-p2-125.bvcom.net ([212.200.141.125] helo=wems.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1EA3b5-0003Mw-00 for ipfix-list@mil.doit.wisc.edu; Tue, 30 Aug 2005 05:44:07 -0500 From: "Malamis Knecht" To: "Lir Fuhr" Subject: =?iso-8859-1?Q?Re:_e6_It_Works_Wonders_V=CFAGRRA?= Date: Tue, 30 Aug 2005 05:43:51 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C5AD25.CCB90580" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Meatman yj 5.50 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?212.200.141.125 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C5AD25.CCB90580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable did not find any Koroviev there, and no one in the house either knew or had = through a succession of narrators, finally joins the Moscow story at the = morning, and that she was leaving her house and her former life forever. = table, another shot up into the air, crackling with starch, white as a And = the foreigner gazed around at the tall buildings that rectangularly `And = heres something I dont understand ... How is it midnight, management, and = Sofya Pavlovna obediently asked Koroviev: I thank you for everything that has = been done in this affair. I ask Never happens, you say? said Woland. Thats = true. But we shall try. suddenly blazed up, followed by the curtains, and now = the fire, howling as fireplace a small red-haired fellow with a knife in his = belt was roasting The laddie mustve got stuck on the Klyazma, came the = thick-voiced Griboedovs, they were now clear as ever. stubborn, and demanded = not one but two guns. Azazello took a second gun from into the oblong hall = where, behind frosted-glass windows with gold 5. Valerius Gratus: According = to Flavius Josephus, in Antiquities of ------=_NextPart_000_0028_01C5AD25.CCB90580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
     
    =
    Good day, = Welcomeharmaceutical shop
     to T.he One Of = The Leading onIine ps
     <= /DIV>
    SAV60 your ph Sh
    E Over % = onarmacy with cPharrmaccy By Mai.Ifop
    <= /FONT>
     
    V= ALllALlS Vy other = m
    UM ClAGRA and maneddi= cations
    ------=_NextPart_000_0028_01C5AD25.CCB90580-- From majordomo@mil.doit.wisc.edu Tue Aug 30 08:59:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA5hl-0007NM-9e for ipfix-archive@megatron.ietf.org; Tue, 30 Aug 2005 08:59:11 -0400 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 IAA10666 for ; Tue, 30 Aug 2005 08:58:59 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EA5U2-0006wa-00 for ipfix-list@mil.doit.wisc.edu; Tue, 30 Aug 2005 07:44:58 -0500 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 1EA5U0-0006wV-00 for ipfix@net.doit.wisc.edu; Tue, 30 Aug 2005 07:44:57 -0500 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 j7UCitX19449; Tue, 30 Aug 2005 14:44:55 +0200 (CEST) Received: from [10.61.65.196] (ams-clip-vpn-dhcp452.cisco.com [10.61.65.196]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j7UCinp27266; Tue, 30 Aug 2005 14:44:49 +0200 (CEST) Message-ID: <431454BE.4010000@cisco.com> Date: Tue, 30 Aug 2005 14:44:46 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] info-model update: version -10 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Juergen, [sorry for the delay, I was on vacation for 3 weeks] I have one editorial issue for all the post I.E.s I see that you put the references to the post specifications in every "post" I.E. If I take for example. 5.3.21 postClassOfServiceIPv4 Description: The definition of this Information Element is identical to the definition of Information Element 'classOfServiceIPv4', except for the special semantics of the 'post' prefix that is described in the third bullet item of section 2.3 and the fourth paragraph of section 5. I'm wondering... Do you expect that the references will be present for all I.E.? I guess so Do you expect that the references will be present for future IANA-administered I.E? I guess so. Then you need a reference to the RFC number. What will happen when we will have a new RFC number (for example, we move from proposed standard to draft standard to internet standard). To be consistent, we should reference the newly defined RFC. What will happen for the already specified I.E. when a new RFC number is out? I guess that we can't/don't want to change their descriptions to refer to the new RFCs. So I'm wondering if this isn't too complicated and a source of confusion? I've always been referring to post as "after packet treatment" specifically for this reason. What about simplifying the postClassOfServiceIPv4 I.E.s to : 5.3.21 postClassOfServiceIPv4 Description: The definition of this Information Element is identical to the definition of Information Element 'classOfServiceIPv4', after packet treatment. To make sure there is no ambiguity, the draft could further clarify. o Middleboxes [RFC3234] may change Flow properties, such as the DSCP value or the source IP address. If an IPFIX Observation Point is located in the path of a Flow before one or more middleboxes that potentially modify packets of the Flow, then it may be desirable to report also flow properties after the modification performed by the middleboxes. THIS IS REFERRED TO AS "AFTER PACKET TREATMENT" IN INFORMATION ELEMENT DESCRIPTIONS. "after packet treatment" is the best term I could come up with. However, if you have a better term in mind, fine with me. The main point is to avoid the reference in the description. Regards, Benoit. > Dear all, > > I just submitted a new version of the IPFIX info model to the > I-D repository. Until it gets posted you can preview it at > . > > > Main changes include: > - rephrased section 2.3, third bullet item: > removed 'pre' prefix, elaborated 'post' prefix > - added paragraph 4 of section 5 on the 'post' prefix > - changed descriptions of all information element with > 'post' prefix > - reordered information elements with 'post' prefix such > that all of them immediately follow the corresponding > unprefixes element (if such an element exists). > - elaborated description of flowEndReason > - fixed several minor typos > > You can see all changes between version -09 and -10 at > . > > I hope, this is the version that will be submitted to the IETF. > If you think we still need more improvement, then please comment. > > Thanks, > > Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Aug 30 10:32:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7AD-00057N-7H for ipfix-archive@megatron.ietf.org; Tue, 30 Aug 2005 10:32:37 -0400 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 KAA16348 for ; Tue, 30 Aug 2005 10:32:26 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EA6zW-0005VD-00 for ipfix-list@mil.doit.wisc.edu; Tue, 30 Aug 2005 09:21:34 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EA6zU-0005Uw-00 for ipfix@net.doit.wisc.edu; Tue, 30 Aug 2005 09:21:32 -0500 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id D3ECC1BAC4D; Tue, 30 Aug 2005 16:21:31 +0200 (CEST) Date: Tue, 30 Aug 2005 16:21:39 +0200 From: Juergen Quittek To: Paul Aitken Cc: ipfix@net.doit.wisc.edu Subject: [ipfix] Re: IPFIX INFO draft Message-ID: In-Reply-To: <431319BC.1030500@cisco.com> References: <431319BC.1030500@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 Paul, --On 8/29/2005 4:20 PM +0200 Paul Aitken wrote: > Juergen, > >>> 5.7.5 ipv4Options >>> >>> Abstract Data Type: unsigned64 >>> Data Type Semantics: flags >>> ElementId: 208 >>> >>> Can we insert a diagram and table, similar to ipv6OptionHeaders #64? >> >> >> Yes. Can you provide them? > > No I cannot, because the definition does not make sense to me! > > The [INFO] text is clear: > > Options are mapped to bits according to their option numbers. > Option number X is mapped to bit X. > > However, looking at http://www.iana.org/assignments/ip-parameters, I see > a (sparse) list of 25 options numbered from 0 through 205. I assume that your browser badly formats the table of the IANA web page. The column for option numbers is ordered from 0 to 24 and has no gaps. > Since RFC 791 defines: > > The option-type octet is viewed as having 3 fields: > > 1 bit copied flag, > 2 bits option class, > 5 bits option number. > > it seems to me that [INFO] requires a 256 bit field. The option type octet has the structure that you described. However, for identifying an IPv4 option, only the 5-bit option number is relevant. > However, [INFO] has: > > Abstract Data Type: unsigned64 > Data Type Semantics: flags > > > So I simply don't understand how this object works. The data type has 64 bits. Currently, 25 (0-24) of them are already assigned by the IETF and more might come in the future. The current idea is to use the option number for indexing a bit position in the unsigned64 value. This maps all 25 already defined IPv4 options and leaves spaces for 39 further ones. > >>> Finally, what's happening with #204, #205 and #206? >>> >>> o Are we leaving them undefined? >>> If so, are they available for new elements, >>> or are they reserved? >>> >>> o Or should we move #207 to #210 down, so there's no gap? >> >> >> I have a clear preference for the second option. >> Would you be fine with it? > > I would, provided it's done immediately and announced widely and clearly > - because everyone who already has any IPFIX implimentation MUST > immediately renumber their #207 - #210. Please note that still the IESG review might result in protocol changes. Everybody who already has an IPFIX implementation should be aware that this implementation is pre-standard as long as the RFC is published. Consequently, he/she should consider potential protocol changes until RFC publication in her/his plans. (Probably it is reasonably safe to consider the protocol stable after it entered the RFC editor queue.) > Some people might object to that, and feel it's better to keep the > existing numbering and simply reuse #204 - #206 for new elements. I > would also be happy with that solution. > > Renumbering is better for a clean draft. However, leaving a gap seems > technically preferable. I do not have a real problem with leaving a gap and filling it later. But if we leave it, we should add a statement to the info model draft on why there is a gap. Otherwise, I expect comments on the gap from the IESG. > Cheers. > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de -- 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 Aug 30 10:43:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7Kq-00007A-NC for ipfix-archive@megatron.ietf.org; Tue, 30 Aug 2005 10:43:36 -0400 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 KAA16908 for ; Tue, 30 Aug 2005 10:43:34 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EA7Cs-0007D3-00 for ipfix-list@mil.doit.wisc.edu; Tue, 30 Aug 2005 09:35:22 -0500 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 1EA7Cr-0007Cn-00 for ipfix@net.doit.wisc.edu; Tue, 30 Aug 2005 09:35:21 -0500 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 j7UEZKg26449 for ; Tue, 30 Aug 2005 16:35:20 +0200 (CEST) Received: from [10.61.65.196] (ams-clip-vpn-dhcp452.cisco.com [10.61.65.196]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j7UEZJp07872 for ; Tue, 30 Aug 2005 16:35:19 +0200 (CEST) Message-ID: <43146EA7.2000701@cisco.com> Date: Tue, 30 Aug 2005 16:35:19 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix Subject: [ipfix] IPFIX Protocol Specifications for Billing Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, FYI. http://www.ietf.org/internet-drafts/draft-bclaise-ipfix-reliability-00.txt Regards, Benoit. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Aug 30 11:23:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7xF-0000tZ-8S for ipfix-archive@megatron.ietf.org; Tue, 30 Aug 2005 11:23:17 -0400 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 LAA18655 for ; Tue, 30 Aug 2005 11:23:14 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EA7kj-0002vB-00 for ipfix-list@mil.doit.wisc.edu; Tue, 30 Aug 2005 10:10:21 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EA7kh-0002v6-00 for ipfix@net.doit.wisc.edu; Tue, 30 Aug 2005 10:10:19 -0500 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 170C61BAC4D; Tue, 30 Aug 2005 17:10:19 +0200 (CEST) Date: Tue, 30 Aug 2005 17:10:27 +0200 From: Juergen Quittek To: Benoit Claise Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] info-model update: version -10 Message-ID: In-Reply-To: <431454BE.4010000@cisco.com> References: <431454BE.4010000@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, --On 8/30/2005 2:44 PM +0200 Benoit Claise wrote: > Hi Juergen, > > [sorry for the delay, I was on vacation for 3 weeks] > I have one editorial issue for all the post I.E.s > > I see that you put the references to the post specifications in every > "post" I.E. > If I take for example. > > 5.3.21 postClassOfServiceIPv4 > > Description: > The definition of this Information Element is identical to the > definition of Information Element 'classOfServiceIPv4', except for > the special semantics of the 'post' prefix that is described in > the third bullet item of section 2.3 and the fourth paragraph of > section 5. > > I'm wondering... > Do you expect that the references will be present for all I.E.? I guess so > Do you expect that the references will be present for future > IANA-administered I.E? I guess so. Then you need a reference to the RFC > number. > What will happen when we will have a new RFC number (for example, we > move from proposed standard to draft standard to internet standard). To > be consistent, we should reference the newly defined RFC. > What will happen for the already specified I.E. when a new RFC number is > out? I guess that we can't/don't want to change their descriptions to > refer to the new RFCs. > So I'm wondering if this isn't too complicated and a source of confusion? > > I've always been referring to post as "after packet treatment" > specifically for this reason. You are right. Bad referencing as I did here is not a good idea. However, just saying 'after packet treatment' without a reference to what is meant by packet treatment does neither help. (For example in the context of a NeTraMet-based IPFIX implementation "packet treatment" would probably refer to processing the packet in the packet matching engine.) > What about simplifying the postClassOfServiceIPv4 I.E.s to : > > 5.3.21 postClassOfServiceIPv4 > > Description: > The definition of this Information Element is identical to the > definition of Information Element 'classOfServiceIPv4', after > packet treatment. Alternative suggestion: The definition of this Information Element is identical to the definition of Information Element 'classOfServiceIPv4', except that it reports a potentially modified value caused by a middlebox function after the packet passed the observation point. > To make sure there is no ambiguity, the draft could further clarify. > > o Middleboxes [RFC3234] may change Flow properties, such as the DSCP > value or the source IP address. If an IPFIX Observation Point is > located in the path of a Flow before one or more middleboxes that > potentially modify packets of the Flow, then it may be desirable > to report also flow properties after the modification performed by > the middleboxes. THIS IS REFERRED TO AS "AFTER PACKET TREATMENT" IN > INFORMATION ELEMENT DESCRIPTIONS. > > "after packet treatment" is the best term I could come up with. However, if you have a better term in mind, fine with me. > The main point is to avoid the reference in the description. If you define AFTER PACKET TREATMENT as above, you still need a reference to this definition. > Regards, Benoit. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de -- 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 Aug 30 13:40:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAA5X-0006Q8-PT for ipfix-archive@megatron.ietf.org; Tue, 30 Aug 2005 13:40:00 -0400 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 NAA25772 for ; Tue, 30 Aug 2005 13:39:56 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EA9zK-00055D-00 for ipfix-list@mil.doit.wisc.edu; Tue, 30 Aug 2005 12:33:34 -0500 Received: from relay03.pair.com ([209.68.5.17]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1EA9zI-00054w-00 for ipfix@net.doit.wisc.edu; Tue, 30 Aug 2005 12:33:32 -0500 Received: (qmail 90778 invoked from network); 30 Aug 2005 17:33:31 -0000 Received: from unknown (HELO ?192.168.0.162?) (unknown) by unknown with SMTP; 30 Aug 2005 17:33:31 -0000 X-pair-Authenticated: 207.237.36.98 In-Reply-To: <43146EA7.2000701@cisco.com> References: <43146EA7.2000701@cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: ipfix Content-Transfer-Encoding: 7bit From: Carter Bullard Subject: Re: [ipfix] IPFIX Protocol Specifications for Billing Date: Tue, 30 Aug 2005 13:33:31 -0400 To: Benoit Claise X-Mailer: Apple Mail (2.734) Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit SCTP is proposed as the only reliable transport for IPFIX, and not one statement as to why TCP is inappropriate. I'm fascinated that TCP, the only IETF STANDARD for connection oriented reliable data transport, isn't even a consideration for IPFIX. I'm sure that I'm living in the past, and not up on the modern world of real telecommunications, out of touch, brain-dead, challenged, deranged whatever, but it just seems, ....., wrong. Somewhere I heard, seems so long ago, that SCTP was ubiquitous, free, highly available, etc...., but I'm still wondering when my redhat enterprise WS is going to get a SCTP stack. I've got an ISO stack, but no SCTP stack. That seems telling. My Windows box doesn't have one, none of the SGI machines, no formal support for SCTP from HP (except for SS7 platform ...), or IBM (anymore). I'm still trying to connect to my Cisco, Juniper, Nortel, Marconi, Lucent, Laurel routers with SCTP, but nada from any of them. Oh and what about that ethereal DOS attack that was caused by SCTP? So why is SCTP on the list and no mention of TCP? Even RFC 3257 states "Many Internet applications therefore should find that either TCP or SCTP will meet their transport requirements". I'd really like to see some dialogue as to why not TCP. Surely IPFIX is not that special? Carter On Aug 30, 2005, at 10:35 AM, Benoit Claise wrote: > Dear all, > > FYI. > http://www.ietf.org/internet-drafts/draft-bclaise-ipfix- > reliability-00.txt > > 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/ > > -- 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 Aug 30 18:51:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAEwp-0000ap-CQ for ipfix-archive@megatron.ietf.org; Tue, 30 Aug 2005 18:51:19 -0400 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 SAA15055 for ; Tue, 30 Aug 2005 18:51:15 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EAEgN-000788-00 for ipfix-list@mil.doit.wisc.edu; Tue, 30 Aug 2005 17:34:19 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EAEgM-000783-00 for ipfix@net.doit.wisc.edu; Tue, 30 Aug 2005 17:34:18 -0500 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 16B511BAC4D; Wed, 31 Aug 2005 00:34:16 +0200 (CEST) Date: Wed, 31 Aug 2005 00:34:23 +0200 From: Juergen Quittek To: Sven Anderson Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] info-model update: version -10 Message-ID: <6A909BBD25D7E05D111F47FD@[192.168.0.112]> In-Reply-To: <4312E2BE.10606@anderson.de> References: <4312E2BE.10606@anderson.de> 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 Sven, --On 8/29/2005 12:26 PM +0200 Sven Anderson wrote: > Hi Juergen, > > Juergen Quittek schrieb: >> I just submitted a new version of the IPFIX info model to the >> I-D repository. Until it gets posted you can preview it at >> . >> >> Main changes include: >> - rephrased section 2.3, third bullet item: >> removed 'pre' prefix, elaborated 'post' prefix >> - added paragraph 4 of section 5 on the 'post' prefix >> - changed descriptions of all information element with >> 'post' prefix >> - reordered information elements with 'post' prefix such >> that all of them immediately follow the corresponding >> unprefixes element (if such an element exists). > [...] >> I hope, this is the version that will be submitted to the IETF. >> If you think we still need more improvement, then please comment. > > On 8th of August I wrote a description of an alternative proposal to the > middlebox issue. I'm wondering that there is no reaction at all to this. > Is it really so much out of question? I'm fine with any reason, why it is > not suitable, but I'd appreciate a short note about the reason. ;-) Sorry for not replying earlier to your suggestions. It was probably bad timing. You sent your email just after we had agreed on a solution in the IPFIX session at Paris. I'll send a reply in a separate message. Thanks, Juergen > Thanks, > > Sven > > -- > sven anderson "Falls Sie glauben, dass Technologie Ihre > http://sven.anderson.de Sicherheitsprobleme l=F6sen kann, verstehen > tel: +49-551-9969285 Sie die Probleme nicht, und Sie haben von > mobile: +49-179-4939223 Technologie keine Ahnung." (B. Schneier) -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 31 03:25:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAMyb-0001UR-8F for ipfix-archive@megatron.ietf.org; Wed, 31 Aug 2005 03:25:41 -0400 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 DAA05480 for ; Wed, 31 Aug 2005 03:25:39 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EAMqi-0005KS-00 for ipfix-list@mil.doit.wisc.edu; Wed, 31 Aug 2005 02:17:32 -0500 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 1EAMqh-0005KN-00 for ipfix@net.doit.wisc.edu; Wed, 31 Aug 2005 02:17:32 -0500 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 j7V7HUl23750; Wed, 31 Aug 2005 09:17:30 +0200 (CEST) Received: from [10.61.65.106] (ams-clip-vpn-dhcp362.cisco.com [10.61.65.106]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j7V7HT304137; Wed, 31 Aug 2005 09:17:29 +0200 (CEST) Message-ID: <43155987.3000300@cisco.com> Date: Wed, 31 Aug 2005 09:17:27 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] info-model update: version -10 References: <431454BE.4010000@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen, > Benoit, > > --On 8/30/2005 2:44 PM +0200 Benoit Claise wrote: > >> Hi Juergen, >> >> [sorry for the delay, I was on vacation for 3 weeks] >> I have one editorial issue for all the post I.E.s >> >> I see that you put the references to the post specifications in every >> "post" I.E. >> If I take for example. >> >> 5.3.21 postClassOfServiceIPv4 >> >> Description: >> The definition of this Information Element is identical to the >> definition of Information Element 'classOfServiceIPv4', except for >> the special semantics of the 'post' prefix that is described in >> the third bullet item of section 2.3 and the fourth paragraph of >> section 5. >> >> I'm wondering... >> Do you expect that the references will be present for all I.E.? I >> guess so >> Do you expect that the references will be present for future >> IANA-administered I.E? I guess so. Then you need a reference to the RFC >> number. >> What will happen when we will have a new RFC number (for example, we >> move from proposed standard to draft standard to internet standard). To >> be consistent, we should reference the newly defined RFC. >> What will happen for the already specified I.E. when a new RFC number is >> out? I guess that we can't/don't want to change their descriptions to >> refer to the new RFCs. >> So I'm wondering if this isn't too complicated and a source of >> confusion? >> >> I've always been referring to post as "after packet treatment" >> specifically for this reason. > > > You are right. Bad referencing as I did here is not a good idea. > However, just saying 'after packet treatment' without a reference > to what is meant by packet treatment does neither help. > (For example in the context of a NeTraMet-based IPFIX implementation > "packet treatment" would probably refer to processing the packet > in the packet matching engine.) > >> What about simplifying the postClassOfServiceIPv4 I.E.s to : >> >> 5.3.21 postClassOfServiceIPv4 >> >> Description: >> The definition of this Information Element is identical to the >> definition of Information Element 'classOfServiceIPv4', after >> packet treatment. > > > Alternative suggestion: > > The definition of this Information Element is identical to the > definition of Information Element 'classOfServiceIPv4', except > that it reports a potentially modified value caused by a > middlebox function after the packet passed the observation point. Fine with me. Thanks. Regards, Benoit. > >> To make sure there is no ambiguity, the draft could further clarify. >> >> o Middleboxes [RFC3234] may change Flow properties, such as the DSCP >> value or the source IP address. If an IPFIX Observation Point is >> located in the path of a Flow before one or more middleboxes that >> potentially modify packets of the Flow, then it may be desirable >> to report also flow properties after the modification performed by >> the middleboxes. THIS IS REFERRED TO AS "AFTER PACKET >> TREATMENT" IN >> INFORMATION ELEMENT DESCRIPTIONS. >> >> "after packet treatment" is the best term I could come up with. >> However, if you have a better term in mind, fine with me. >> The main point is to avoid the reference in the description. > > > If you define AFTER PACKET TREATMENT as above, you still need a reference > to this definition. > >> Regards, Benoit. > > > Thanks, > > Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 31 03:42:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EANEt-0005wc-Lu for ipfix-archive@megatron.ietf.org; Wed, 31 Aug 2005 03:42:33 -0400 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 DAA06055 for ; Wed, 31 Aug 2005 03:42:29 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EAMza-0005ZZ-00 for ipfix-list@mil.doit.wisc.edu; Wed, 31 Aug 2005 02:26:42 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EAMzY-0005ZU-00 for ipfix-info@net.doit.wisc.edu; Wed, 31 Aug 2005 02:26:40 -0500 Received: from [192.168.0.112] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id EAB4B1BAC4D; Wed, 31 Aug 2005 09:26:38 +0200 (CEST) Date: Wed, 31 Aug 2005 09:26:46 +0200 From: Juergen Quittek To: Sven Anderson , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] Proposal for IFPIX observations at middleboxes Message-ID: 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 Sven, As said before, your proposal of introducing 'observation groups' into the IPFIX protocol came at a bad time just after we agreed on a solution on the middlebox problem at the IPFIX session at IETF 63. At the session we also discussed the proposal you made before the session. Anyway, in the past we have been discussing means for structuring IPFIX records several times already. The general feeling was that we should use such means carefully only if really necessary, because it complicates the protocol and defining a clear semantics that is unambiguous in all complex cases is not that easy. Also we only added structuring, such a scopes and sequential ordering, only when strong use cases were present that could not be covered with more simple solutions. since we agreed a rather simple solution for the middlebox problem at the IETF meeting, I do not think we should re-enter this discussion with a more complex (though mightier) solution. Thanks, Juergen --=20 Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 8/4/2005 7:05 PM +0200 Sven Anderson wrote: > Hi all, > > I will try to explain again my idea for reporting flows from middleboxes > as clear and short(?) as possible: > > When IP packets travel through a middlebox, their properties may change. > Examples would be TTL, IP adresses (NAT), DSCP or even fragmentation or > replication (multicasting). That means, that if an Observation Domain > includes several Observation Points, and the same packet passes more than > one of these Observation Points, some properties can be ambiguous in this > Observation Domain. > > You could solve this by saying, that every propery of a flow-report > has to derive from the same observation point. But this would be > restrictive. Sometimes it is desirable, that you can classify a single > Flow by properties, that derive from _different_ Observation Points. For > example a flow-definition that includes the source IP address before and > after a NAT, or the DSCP at three different Observation Points (before > ingress linecard, after ingress linecard, after egress linecard). > > To realise this, you need a way to use certain properties more than one > time in a flow-template, to correspond to the different states at the > different Observation Points. One way to do this, is the introduction of > additional post- I.E.s, which then correspond to the first and the last > Observation Point in the Observation Domain. But this is a restriction to > two special Observation Points, and the second example from above is not > solvable with this approach. > > A more general solution would be to allow the use of the same I.E. more > than one time in the same template. The order of the multiple I.E.s > corresponds to the different observations as the packet travels through > the middlebox. The problem here is, that you cannot tell then, to which of > the different observations the _singular_ I.E.s belong to. > > To solve this, you need a possibility to build goups of I.E.s in the > Template: The I.E. values in one "Observation Group" always derive from > the same Observation Point (for each packet!). The Observation Groups are > ordered accordingly to the sequence of Observation Points the packet is > passing. Of course there are also fields which don't depend on the > Observation Point and can be reported in any Observation Group, like > ingressInterface (not egress!), as it is always the same, no matter where > in the middlebox the packet is observed. (You may say, that these fields > _have_ to be reported in the first group then, if this is an advantage.) > > Important to note is, that packets of a Flow defined by (for example) two > Observation Groups don't necessarily pass the same sequence of two > Observation Points. They just share the same Flow poperties at the their > first and second Observation Points respectively. To make sure, that all > packets passed the same sequence of Observation Points you have to include > an (yet to be defined) I.E. "observationPointID" as a Flow Key in each > Observation Group. > > BTW.: It's possible that a Flow has the same observationPointID in > different Observation Groups. For example if your Flow contains two > Observation Groups, corresponding to Observation Points at the ingress and > egress interface, you could have Flows where ingress and egress interface > and therefore the observationPointID is the same (e.g. after some NAT). > > The next question is: what is a good way to define these groups? Here are > just two ideas: > > - my first idea, which I descibed in an former mail, was to define > "Combined Templates", which are a ordered list of other Templates. Each > Template in the Combined Template represents an Observation Group. The > reports for Combined Templates are just normal reports with all the Fields > of all the listed Templates concatenated. The disadvantage is, that a > change of IPFIX-PROTO is necessary. > > - another idea is to define a special separator I.E. with length 0, like > "newObservationGroup". This pseudo-field separates the Fields in the > Template into different Observation Groups. In the reports they don't > appear, but the collector has the template and knows where to split. Here > no change in IPFIX-PROTO is necessary. (Jeroen Massar had a very similar idea) > > I think this concept is a superset of the proposals of J=FCrgen and Benoit. > Instead of using post-I.E.s Benoit could use Templates like this (using > the second grouping-mechanism): > > > [...different Fields...] > > > ** > > > The DSCP field in the second ObservationGroup is the same as his postDSCP > field. > > J=FCrgen would do it maybe like this: > > > ** > > > [...different Fields...] > > > instead of using an preDestinationIPv4Address Field. > > Why do I like this concept: > > - it includes all the possibilities of the other solutions. > > - you can have as many Observation Groups as you want. (I have an > VPN-Relay here, where I will need 3 Observation Groups, which is not > possible with the pre-/post- solutions.) > > - it is always clear, which fields derive from the same Observation Points > (same packet state). This is especially true for the counter Fields! You > can have even the same counter in different Observation Groups, if you > expect the packet size to be changed. > > - you don't need any post-/pre- variants of the I.E.s You just need the > newObservationGroup I.E.. The observationPointID is a good idea anyway, I > think. > > - you don't need complicated semantics, you just report an ordered > sequence of packet states. (And that's all you know, in fact.) > > I'm not really sure, but I think, that the in- and out- counters also get > obsolete then. Wouldn't it be the same as having a counter in the first > and last Observation Group? > > A side note: I think a packet-altering instance - like a NAT process - > which is reporting information to the metering process, should always be > seen as _two_ observation points, one before and one after the change. > > Anyway, this is my "work in progress" idea. I hope I could present this > quite complex object in an understandable manner. Now tell me, why it is a > bad idea. :-) > > > Cheers, > > Sven > > -- > Sven Anderson > Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de > Georg-August-Universitaet Goettingen > Lotzestr. 16-18, 37083 Goettingen, Germany > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 31 09:27:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EASdC-00047a-Rj for ipfix-archive@megatron.ietf.org; Wed, 31 Aug 2005 09:27:59 -0400 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 JAA20389 for ; Wed, 31 Aug 2005 09:27:56 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EASVv-0003af-00 for ipfix-list@mil.doit.wisc.edu; Wed, 31 Aug 2005 08:20:27 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EASVu-0003aa-00 for ipfix@net.doit.wisc.edu; Wed, 31 Aug 2005 08:20:26 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Aug 2005 15:20:26 +0200 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 j7VDKMVP011950; Wed, 31 Aug 2005 15:20:23 +0200 (MEST) Received: from [10.61.64.120] (ams-clip-vpn-dhcp120.cisco.com [10.61.64.120]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA15189; Wed, 31 Aug 2005 14:20:22 +0100 (BST) Message-ID: <4315AE94.6090502@cisco.com> Date: Wed, 31 Aug 2005 14:20:20 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.8) Gecko/20050603 Fedora/1.7.8-1.2.1.legacy X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Juergen Quittek CC: ipfix@net.doit.wisc.edu Subject: [ipfix] Re: IPFIX INFO draft References: <431319BC.1030500@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen, >>>> 5.7.5 ipv4Options >>>> >>>> Abstract Data Type: unsigned64 >>>> Data Type Semantics: flags >>>> ElementId: 208 >>>> >>>> Can we insert a diagram and table, similar to ipv6OptionHeaders #64? >>> >>> >>> >>> Yes. Can you provide them? >> >> >> No I cannot, because the definition does not make sense to me! >> >> The [INFO] text is clear: >> >> Options are mapped to bits according to their option numbers. >> Option number X is mapped to bit X. >> >> However, looking at http://www.iana.org/assignments/ip-parameters, I see >> a (sparse) list of 25 options numbered from 0 through 205. > > > I assume that your browser badly formats the table of the IANA web page. > The column for option numbers is ordered from 0 to 24 and has no gaps. OK, I see. >> Since RFC 791 defines: >> >> The option-type octet is viewed as having 3 fields: >> >> 1 bit copied flag, >> 2 bits option class, >> 5 bits option number. >> >> it seems to me that [INFO] requires a 256 bit field. > > > The option type octet has the structure that you described. > However, for identifying an IPv4 option, only the 5-bit option > number is relevant. > The data type has 64 bits. Currently, 25 (0-24) of them are already > assigned by the IETF and more might come in the future. The current idea > is to use the option number for indexing a bit position in the unsigned64 > value. This maps all 25 already defined IPv4 options and leaves spaces for > 39 further ones. While this is sufficient for encoding valid options, it is quite insufficient for truly reporting real traffic, because someone could easily craft some traffic with an option set to copy=0, class=0, number=2 (ie, value=2). How then would I report this? If I strip out the copy and class info, and only regard the option number, then I will incorrectly report it as a security option (which is similar, except copy=1 so value=130). If I'm diligent, perhaps I will realise that only an option with a value of 130 should cause bit 2 to be set, so I won't set bit 2 for an option with the value of 2, 32+2, 64+2, or 96+2. But this is a complicated mapping. So I propose that we change the name from "ipv4Options" to "ipv4OptionsNumber" and simply encode the 5 bit option number, regardless of the "copy" or "class" bits. Then it's clear from the name exactly what we're doing. Besides, the text should also clearly state this too. Later, if someone really does need to differentiate the copy, class and number bits, then we can create an unsigned256 ipv4Options element. The table for ipv4OptionsNumber is: Number Name ------ ------------------------------- 0 EOOL - End of Options List 1 NOP - No Operation 2 SEC - Security 3 LSR - Loose Source Route 4 TS - Time Stamp 5 E-SEC - Extended Security 6 CIPSO - Commercial Security 7 RR - Record Route 8 SID - Stream ID 9 SSR - Strict Source Route 10 ZSU - Experimental Measurement 11 MTUP - MTU Probe 12 MTUR - MTU Reply 13 FINN - Experimental Flow Control 14 VISA - Expermental Access Control 15 ENCODE - ??? 16 IMITD - IMI Traffic Descriptor 17 EIP - Extended Internet Protocol 18 TR - Traceroute 19 ADDEXT - Address Extension 20 RTRALT - Router Alert 21 SDB - Selective Directed Broadcast 22 NSAPA - NSAP Addresses 23 DPS - Dynamic Packet State 24 UMP - Upstream Multicast Pkt. And so the diagram is: 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | EOOL | NOP | SEC | LSR | TS |E-SEC |CIPSO | RR | +------+------+------+------+------+------+------+------+ 8 9 10 11 12 13 14 15 +------+------+------+------+------+------+------+------+ | SID | SSR | ZSU | MTUP | MTUR | FINN | VISA |ENCODE| +------+------+------+------+------+------+------+------+ 16 17 18 19 20 21 22 23 +------+------+------+------+------+------+------+------+ |IMITD | EIP | TR |ADDEXT|RTRALT| SDB |NSAPA | DPS | +------+------+------+------+------+------+------+------+ 24 25 26 27 28 29 30 31 +------+------+------+------+------+------+------+------+ | UMP | Reserved | +------+------+------+------+------+------+------+------+ . . . . . . 56 57 58 59 60 61 62 63 +------+------+------+------+------+------+------+------+ | Reserved | +------+------+------+------+------+------+------+------+ >>>> Finally, what's happening with #204, #205 and #206? >>>> >>>> o Are we leaving them undefined? >>>> If so, are they available for new elements, >>>> or are they reserved? >>>> >>>> o Or should we move #207 to #210 down, so there's no gap? >>> >>> >>> >>> I have a clear preference for the second option. >>> Would you be fine with it? As per another email I sent earlier today, I propose to keep #207 to #210 unchanged since I believe this is the best solution for everyone. 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 Wed Aug 31 10:02:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EATAe-00066u-Uu for ipfix-archive@megatron.ietf.org; Wed, 31 Aug 2005 10:02:33 -0400 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 KAA21838 for ; Wed, 31 Aug 2005 10:02:30 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EAT5Q-0004PR-00 for ipfix-list@mil.doit.wisc.edu; Wed, 31 Aug 2005 08:57:08 -0500 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 1EAT5P-0004PM-00 for ipfix@net.doit.wisc.edu; Wed, 31 Aug 2005 08:57:07 -0500 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 j7VDuvv18538; Wed, 31 Aug 2005 15:56:57 +0200 (CEST) Received: from [10.61.65.106] (ams-clip-vpn-dhcp362.cisco.com [10.61.65.106]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j7VDuu322160; Wed, 31 Aug 2005 15:56:56 +0200 (CEST) Message-ID: <4315B727.8090703@cisco.com> Date: Wed, 31 Aug 2005 15:56:55 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix@net.doit.wisc.edu, Paul Aitken , boschi@fokus.fraunhofer.de, Thomas Dietz , Brian Trammell Subject: Re: Padding summary, was: [ipfix] padding spec References: <88F766D04E6AF3409B39E60D7D933EB24FD562@europa.office> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080407020008070800080703" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------080407020008070800080703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Juergen and all, > Dear all, > > This is a try to summarize the discussion on padding. > > Since the last version (-10) of the info model we have an Information > Element > for padding of type octetArray. The protocol allows using encoding it > as a > fixed-length array as well as a variable length array. > > As a reminder, an IPFIX message is structures as follows: > - IPFIX message contains sets > - set contains records > - data record contains Information Elements (IEs) > - template record contains IE specifiers > > > Alignment of IEs within a data record > > The padding IE gives us flexible means for aligning IEs within a data > record. > Aligning within a data record can be useful, because you may very easily > convert internal data structures into flow records at the exporter and > vice versa at the collector. > > > Alignment of IE specifiers within a template record > > We do not have means for aligning IE specifiers within template records, > but there is a limited need for it and IE specifiers are aligned to > 32-bit > address boundaries anyway. > > > Alignment of records within a set > > We do not have explicit means for aligning records within a set. > However, > for template records the need is limited and they are aligned to 32-bit > boundaries anyway. For data records we can use padding IEs at the end > of a the record extending the length of the record to the next alignment > boundary. Note that this way also the sets are aligned (up to 32-bit > boundaries) within an IPFIX message, because also at the end of the last > records within a set there is a padding IE. > > > Alignment of sets within an IPFIX message > > If records are already aligned within a set by using padding IEs, then > this alignment is probably already achieved. But for aligning sets > within > an IPFIX message, the protocol further means, as described in section > 3.3.1 > of the protocol document. This padding mechanism can be applied even if > the records within sets are not aligned. > > > Conclusion > > In my view, the main point of our discussion is whether it makes sense > having this additional padding mechanism. I see advantages of padding > within a record for aligning internal data structures and flow records. > > But I see very little advantage in aligning sets if the sets and their > contained flow records are not aligned also. > > Consequently, I suggest removing the padding at the end of a set from > the protocol specification. I understand your way of thinking and agree with you when you wrote "But I see very little advantage in aligning sets if the sets and their contained flow records are not aligned also. " However, I'm not sure if your conclusion is the right one. I'm wondering why we should remove some flexibility from the IPFIX protocol specifications, some flexibility that requires little effort. Don't forget that the padding at the end of the Set is optional. See section 3.3.1 "The Exporting Process MAY insert some padding octets" I don't have right now a good example of why this would be needed. But maybe in the future? What about http://www.ietf.org/internet-drafts/draft-trammell-ipfix-file-00.txt? Would a Set alignment provide some benefits? I'm not sure yet, potentially. Why close the door now? With Paul Aitken, we went through padding again in the protocol draft. We would like to copy a sentence from [IPFIX-INFO] that should be part of [IPFIX-PROTO] Padding The Exporting Process MAY insert some padding octets, so that the subsequent Set starts at an aligned boundary. Padding MUST be composed of zero (0) octets. The padding length MUST be shorter than any allowable Record in this Set. _If padding of the IPFIX Message is desired in combination with very short Records, then the padding Information Element 'paddingOctets' [IPFI-INFO] can be used for padding Flow Records such that their length is increased to a multiple of 4 or 8 octets._ Because Template Sets are always 4-octet aligned by definition padding is only needed in case of other alignments e.g. on 8- octet boundaries. Further more, we would like to add a clarification in the section 9 " The Collecting Process's Side" The Collector MUST accept padding in Data Records and Template Records. _The padding size is the Set Length minus the size of the Set Header (4 octets for the Set ID and the Set Length), modulo the Record size deduced from the Template Record._ Any objections? Regards, Benoit. --------------080407020008070800080703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Juergen and all,
    Dear all,

    This is a try to summarize the discussion on padding.

    Since the last version (-10) of the info model we have an Information Element
    for padding of type octetArray.  The protocol allows using encoding it as a
    fixed-length array as well as a variable length array.

    As a reminder, an IPFIX message is structures as follows:
     - IPFIX message    contains  sets
     - set              contains  records
     - data record      contains  Information Elements (IEs)
     - template record  contains  IE specifiers


    Alignment of IEs within a data record

    The padding IE gives us flexible means for aligning IEs within a data record.
    Aligning within a data record can be useful, because you may very easily
    convert internal data structures into flow records at the exporter and
    vice versa at the collector.


    Alignment of IE specifiers within a template record

    We do not have means for aligning IE specifiers within template records,
    but there is a limited need for it and IE specifiers are aligned to 32-bit
    address boundaries anyway.


    Alignment of records within a set

    We do not have explicit means for aligning records within a set.  However,
    for template records the need is limited and they are aligned to 32-bit
    boundaries anyway.  For data records we can use padding IEs at the end
    of a the record extending the length of the record to the next alignment
    boundary.  Note that this way also the sets are aligned (up to 32-bit
    boundaries) within an IPFIX message, because also at the end of the last
    records within a set there is a padding IE.


    Alignment of sets within an IPFIX message

    If records are already aligned within a set by using padding IEs, then
    this alignment is probably already achieved.  But for aligning sets within
    an IPFIX message, the protocol further means, as described in section 3.3.1
    of the protocol document.  This padding mechanism can be applied even if
    the records within sets are not aligned.


    Conclusion

    In my view, the main point of our discussion is whether it makes sense
    having this additional padding mechanism.  I see advantages of padding
    within a record for aligning internal data structures and flow records.

    But I see very little advantage in aligning sets if the sets and their
    contained flow records are not aligned also.

    Consequently, I suggest removing the padding at the end of a set from
    the protocol specification.
    I understand your way of thinking and agree with you when you wrote "But I see very little advantage in aligning sets if the sets and their contained flow records are not aligned also. "
    However, I'm not sure if your conclusion is the right one.
    I'm wondering why we should remove some flexibility from the IPFIX protocol specifications, some flexibility that requires little effort.
    Don't forget that the padding at the end of the Set is optional. See section 3.3.1 "The Exporting Process MAY insert some padding octets"
    I don't have right now a good example of why this would be needed. But maybe in the future?
    What about http://www.ietf.org/internet-drafts/draft-trammell-ipfix-file-00.txt? Would a Set alignment provide some benefits? I'm not sure yet, potentially. Why close the door now?


    With Paul Aitken, we went through padding again in the protocol draft.
    We would like to copy a sentence from [IPFIX-INFO] that should be part of [IPFIX-PROTO]
          Padding 
         The Exporting Process MAY insert some padding octets, so that 
         the subsequent Set starts at an aligned boundary.  Padding 
         MUST be composed of zero (0) octets.  The padding length MUST 
         be shorter than any allowable Record in this Set.  
         If padding of the IPFIX Message is desired in combination
         with very short Records, then the padding Information Element
         'paddingOctets' [IPFI-INFO] can be used for padding Flow Records such 
         that their length is increased to a multiple of 4 or 8 octets.
         Because Template Sets are always 4-octet aligned by definition  
         padding is only needed in case of other alignments e.g. on 8- 
         octet boundaries. 

Further more, we would like to add a clarification in the section 9 "
The Collecting Process's Side"
       The Collector MUST accept padding in Data Records and Template 
   Records.  The padding size is the Set Length minus the size of 
   the Set Header (4 octets for the Set ID and the Set Length), 
   modulo the Record size deduced from the Template Record.

    Any objections?

    Regards, Benoit. --------------080407020008070800080703-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 31 12:21:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAVKv-00042u-6R for ipfix-archive@megatron.ietf.org; Wed, 31 Aug 2005 12:21:17 -0400 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 MAA28894 for ; Wed, 31 Aug 2005 12:21:13 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EAV1U-0007D5-00 for ipfix-list@mil.doit.wisc.edu; Wed, 31 Aug 2005 11:01:12 -0500 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 1EAV1T-0007D0-00 for ipfix@net.doit.wisc.edu; Wed, 31 Aug 2005 11:01:11 -0500 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 j7VG0xT26302; Wed, 31 Aug 2005 18:00:59 +0200 (CEST) Received: from [10.61.65.84] (ams-clip-vpn-dhcp340.cisco.com [10.61.65.84]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j7VG0v315374; Wed, 31 Aug 2005 18:00:57 +0200 (CEST) Message-ID: <4315D439.10004@cisco.com> Date: Wed, 31 Aug 2005 18:00:57 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu CC: Benoit Claise , Juergen Quittek , Paul Aitken , boschi@fokus.fraunhofer.de, Thomas Dietz , Brian Trammell Subject: Re: Padding summary, was: [ipfix] padding spec -> please state your point of view References: <88F766D04E6AF3409B39E60D7D933EB24FD562@europa.office> <4315B727.8090703@cisco.com> In-Reply-To: <4315B727.8090703@cisco.com> Content-Type: multipart/alternative; boundary="------------080904080501000501000303" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------080904080501000501000303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Please state your point of view, as we're at the end of the last-call. Should the protocol draft continue to specify the optional padding at the end of Set (see section 3.3.1)? Or should this be removed? Regards, Benoit. > Juergen and all, > >> Dear all, >> >> This is a try to summarize the discussion on padding. >> >> Since the last version (-10) of the info model we have an Information >> Element >> for padding of type octetArray. The protocol allows using encoding >> it as a >> fixed-length array as well as a variable length array. >> >> As a reminder, an IPFIX message is structures as follows: >> - IPFIX message contains sets >> - set contains records >> - data record contains Information Elements (IEs) >> - template record contains IE specifiers >> >> >> Alignment of IEs within a data record >> >> The padding IE gives us flexible means for aligning IEs within a data >> record. >> Aligning within a data record can be useful, because you may very easily >> convert internal data structures into flow records at the exporter and >> vice versa at the collector. >> >> >> Alignment of IE specifiers within a template record >> >> We do not have means for aligning IE specifiers within template records, >> but there is a limited need for it and IE specifiers are aligned to >> 32-bit >> address boundaries anyway. >> >> >> Alignment of records within a set >> >> We do not have explicit means for aligning records within a set. >> However, >> for template records the need is limited and they are aligned to 32-bit >> boundaries anyway. For data records we can use padding IEs at the end >> of a the record extending the length of the record to the next alignment >> boundary. Note that this way also the sets are aligned (up to 32-bit >> boundaries) within an IPFIX message, because also at the end of the last >> records within a set there is a padding IE. >> >> >> Alignment of sets within an IPFIX message >> >> If records are already aligned within a set by using padding IEs, then >> this alignment is probably already achieved. But for aligning sets >> within >> an IPFIX message, the protocol further means, as described in section >> 3.3.1 >> of the protocol document. This padding mechanism can be applied even if >> the records within sets are not aligned. >> >> >> Conclusion >> >> In my view, the main point of our discussion is whether it makes sense >> having this additional padding mechanism. I see advantages of padding >> within a record for aligning internal data structures and flow records. >> >> But I see very little advantage in aligning sets if the sets and their >> contained flow records are not aligned also. > >> >> Consequently, I suggest removing the padding at the end of a set from >> the protocol specification. > > I understand your way of thinking and agree with you when you wrote > "But I see very little advantage in aligning sets if the sets and > their contained flow records are not aligned also. " > However, I'm not sure if your conclusion is the right one. > I'm wondering why we should remove some flexibility from the IPFIX > protocol specifications, some flexibility that requires little effort. > Don't forget that the padding at the end of the Set is optional. See > section 3.3.1 "The Exporting Process MAY insert some padding octets" > I don't have right now a good example of why this would be needed. But > maybe in the future? > What about > http://www.ietf.org/internet-drafts/draft-trammell-ipfix-file-00.txt? > Would a Set alignment provide some benefits? I'm not sure yet, > potentially. Why close the door now? > > > With Paul Aitken, we went through padding again in the protocol draft. > We would like to copy a sentence from [IPFIX-INFO] that should be part > of [IPFIX-PROTO] > > Padding > The Exporting Process MAY insert some padding octets, so that > the subsequent Set starts at an aligned boundary. Padding > MUST be composed of zero (0) octets. The padding length MUST > be shorter than any allowable Record in this Set. > _If padding of the IPFIX Message is desired in combination > with very short Records, then the padding Information Element > 'paddingOctets' [IPFI-INFO] can be used for padding Flow Records such > that their length is increased to a multiple of 4 or 8 octets._ > Because Template Sets are always 4-octet aligned by definition > padding is only needed in case of other alignments e.g. on 8- > octet boundaries. > >Further more, we would like to add a clarification in the section 9 " >The Collecting Process's Side" > > The Collector MUST accept padding in Data Records and Template > Records. _The padding size is the Set Length minus the size of > the Set Header (4 octets for the Set ID and the Set Length), > modulo the Record size deduced from the Template Record._ > > > Any objections? > > Regards, Benoit. --------------080904080501000501000303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

    Please state your point of view, as we're at the end of the last-call.
    Should the protocol draft continue to specify the optional padding at the end of Set (see section 3.3.1)? Or should this be removed?

    Regards, Benoit.

    Juergen and all,
    Dear all,

    This is a try to summarize the discussion on padding.

    Since the last version (-10) of the info model we have an Information Element
    for padding of type octetArray.  The protocol allows using encoding it as a
    fixed-length array as well as a variable length array.

    As a reminder, an IPFIX message is structures as follows:
     - IPFIX message    contains  sets
     - set              contains  records
     - data record      contains  Information Elements (IEs)
     - template record  contains  IE specifiers


    Alignment of IEs within a data record

    The padding IE gives us flexible means for aligning IEs within a data record.
    Aligning within a data record can be useful, because you may very easily
    convert internal data structures into flow records at the exporter and
    vice versa at the collector.


    Alignment of IE specifiers within a template record

    We do not have means for aligning IE specifiers within template records,
    but there is a limited need for it and IE specifiers are aligned to 32-bit
    address boundaries anyway.


    Alignment of records within a set

    We do not have explicit means for aligning records within a set.  However,
    for template records the need is limited and they are aligned to 32-bit
    boundaries anyway.  For data records we can use padding IEs at the end
    of a the record extending the length of the record to the next alignment
    boundary.  Note that this way also the sets are aligned (up to 32-bit
    boundaries) within an IPFIX message, because also at the end of the last
    records within a set there is a padding IE.


    Alignment of sets within an IPFIX message

    If records are already aligned within a set by using padding IEs, then
    this alignment is probably already achieved.  But for aligning sets within
    an IPFIX message, the protocol further means, as described in section 3.3.1
    of the protocol document.  This padding mechanism can be applied even if
    the records within sets are not aligned.


    Conclusion

    In my view, the main point of our discussion is whether it makes sense
    having this additional padding mechanism.  I see advantages of padding
    within a record for aligning internal data structures and flow records.

    But I see very little advantage in aligning sets if the sets and their
    contained flow records are not aligned also.

    Consequently, I suggest removing the padding at the end of a set from
    the protocol specification.
    I understand your way of thinking and agree with you when you wrote "But I see very little advantage in aligning sets if the sets and their contained flow records are not aligned also. "
    However, I'm not sure if your conclusion is the right one.
    I'm wondering why we should remove some flexibility from the IPFIX protocol specifications, some flexibility that requires little effort.
    Don't forget that the padding at the end of the Set is optional. See section 3.3.1 "The Exporting Process MAY insert some padding octets"
    I don't have right now a good example of why this would be needed. But maybe in the future?
    What about http://www.ietf.org/internet-drafts/draft-trammell-ipfix-file-00.txt? Would a Set alignment provide some benefits? I'm not sure yet, potentially. Why close the door now?


    With Paul Aitken, we went through padding again in the protocol draft.
    We would like to copy a sentence from [IPFIX-INFO] that should be part of [IPFIX-PROTO]
          Padding 
         The Exporting Process MAY insert some padding octets, so that 
         the subsequent Set starts at an aligned boundary.  Padding 
         MUST be composed of zero (0) octets.  The padding length MUST 
         be shorter than any allowable Record in this Set.  
         If padding of the IPFIX Message is desired in combination
         with very short Records, then the padding Information Element
         'paddingOctets' [IPFI-INFO] can be used for padding Flow Records such 
         that their length is increased to a multiple of 4 or 8 octets.
         Because Template Sets are always 4-octet aligned by definition  
         padding is only needed in case of other alignments e.g. on 8- 
         octet boundaries. 

Further more, we would like to add a clarification in the section 9 "
The Collecting Process's Side"
       The Collector MUST accept padding in Data Records and Template 
   Records.  The padding size is the Set Length minus the size of 
   the Set Header (4 octets for the Set ID and the Set Length), 
   modulo the Record size deduced from the Template Record.

    Any objections?

    Regards, Benoit.

    --------------080904080501000501000303-- -- 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 cornenmqu@rooibos.ch Wed Aug 31 12:57:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAVu5-0006V1-IV for ipfix-archive@megatron.ietf.org; Wed, 31 Aug 2005 12:57:37 -0400 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 MAA00454 for ; Wed, 31 Aug 2005 12:57:33 -0400 (EDT) Received: from 61-231-19-181.dynamic.hinet.net ([61.231.19.181] helo=rooibos.ch) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1EAVe6-0000Gf-00 for ipfix-list@mil.doit.wisc.edu; Wed, 31 Aug 2005 11:41:07 -0500 Received: from [192.168.221.104] (helo=misfit) by rooibos.ch with smtp (Phenomenal 5.14 (Problematical)) id kOkPoc-yhsmkO-Ax for ipfix-list@mil.doit.wisc.edu; Wed, 31 Aug 2005 11:39:55 -0500 Message-ID: <000b01c5ae4a$9cb75280$68dda8c0@misfit> Reply-To: "Corne Maris" From: "Corne Maris" To: "Parvin Batz" Subject: =?iso-8859-1?Q?Do_y=D4u_know_what?_C=CEAIS_V=CDAGRRA?= Date: Wed, 31 Aug 2005 11:39:53 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C5AE20.B3E14A80" 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_0008_01C5AE20.B3E14A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, with asphalt, and in wintertime was dominated by a snow pile with a = shovel Proof my handwriting my signature wire urgently = confirmation placeinto some clever arrangement, twisted himself up = like a screw, and then, The doctor glanced questioningly at = Riukhin, who muttered glumly:his iron hands, Azazello turned her over = like a doll, face to him, andafter a long, refreshing sleep, with = a wolfish appetite besides. And on This conversation, as was = learned afterwards, was about Jesus Christ. And the most interesting = thing about this bunk, said Woland, is thatMargarita flying in the = black tail of his cloak, alighted with them besidesparkled.and he said = even with a sort of reverie:master whispered solemnly and raised his = hand. Yes, he astounded medepartment, was suddenly transformed. His = eyes flashed with bellicose fire, No dramas, no dramas, Azazello = returned, making faces, you must alsooften in which certain bond numbers = would win a significant amount of money.flight. Something told her that = she would be waited for in the place she was ------=_NextPart_000_0008_01C5AE20.B3E14A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hi, do  d less  on?
    you want to spen on your medicati
     
    Just = VISlT EPharmaccy-By-M hop and SAV to 70
    ail S E up  %
     
    VALlU S Vl nd many other medication
    UM ClALLl AGRRA a s
     
    Try u t be disappointed!
    s and you will no
     
    ------=_NextPart_000_0008_01C5AE20.B3E14A80-- From majordomo@mil.doit.wisc.edu Wed Aug 31 13:36:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAWVV-0008Vx-Vu for ipfix-archive@megatron.ietf.org; Wed, 31 Aug 2005 13:36:18 -0400 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 NAA02015 for ; Wed, 31 Aug 2005 13:36:14 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EAWPV-0001XL-00 for ipfix-list@mil.doit.wisc.edu; Wed, 31 Aug 2005 12:30:05 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EAWPU-0001XD-00 for ipfix@net.doit.wisc.edu; Wed, 31 Aug 2005 12:30:04 -0500 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.13) with ESMTP id j7VHTxsq005000 for ; Wed, 31 Aug 2005 13:30:02 -0400 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id j7VHTp7b004984 for ; Wed, 31 Aug 2005 13:29:51 -0400 Received: from ioannes.indigo.cert.org (ioannes.indigo.cert.org [10.60.10.57]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id j7VHToP6004982; Wed, 31 Aug 2005 13:29:51 -0400 (EDT) Received: from [128.237.244.221] (vpn-10-25-4-10.remote.cert.org [10.25.4.10]) by ioannes.indigo.cert.org (8.12.8/8.12.8/2.42.1.1) with ESMTP id j7VHTopD010685; Wed, 31 Aug 2005 13:29:50 -0400 In-Reply-To: <4315D439.10004@cisco.com> References: <88F766D04E6AF3409B39E60D7D933EB24FD562@europa.office> <4315B727.8090703@cisco.com> <4315D439.10004@cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3--974185066" Message-Id: <9388949B-0A0F-4D17-A4E1-9826090F01D5@cert.org> Cc: ipfix@net.doit.wisc.edu, Juergen Quittek , Paul Aitken , boschi@fokus.fraunhofer.de, Thomas Dietz Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: Padding summary, was: [ipfix] padding spec -> please state your point of view Date: Wed, 31 Aug 2005 13:29:46 -0400 To: Benoit Claise X-Pgp-Agent: GPGMail 1.1 (Tiger) X-Mailer: Apple Mail (2.734) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000004 X-Scanned-By: MIMEDefang 2.52 on 192.88.209.16 Precedence: bulk Sender: majordomo listserver --Apple-Mail-3--974185066 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Not required at the exporter, minimal effort required at the collector, no document effort required to leave it in - I say we keep 3.3.1. - Brian On Aug 31, 2005, at 12:00 PM, Benoit Claise wrote: > Dear all, > > Please state your point of view, as we're at the end of the last-call. > Should the protocol draft continue to specify the optional padding > at the end of Set (see section 3.3.1)? Or should this be removed? > > Regards, Benoit. > >> Juergen and all, >>> Dear all, >>> >>> This is a try to summarize the discussion on padding. >>> >>> Since the last version (-10) of the info model we have an >>> Information Element >>> for padding of type octetArray. The protocol allows using >>> encoding it as a >>> fixed-length array as well as a variable length array. >>> >>> As a reminder, an IPFIX message is structures as follows: >>> - IPFIX message contains sets >>> - set contains records >>> - data record contains Information Elements (IEs) >>> - template record contains IE specifiers >>> >>> >>> Alignment of IEs within a data record >>> >>> The padding IE gives us flexible means for aligning IEs within a >>> data record. >>> Aligning within a data record can be useful, because you may very >>> easily >>> convert internal data structures into flow records at the >>> exporter and >>> vice versa at the collector. >>> >>> >>> Alignment of IE specifiers within a template record >>> >>> We do not have means for aligning IE specifiers within template >>> records, >>> but there is a limited need for it and IE specifiers are aligned >>> to 32-bit >>> address boundaries anyway. >>> >>> >>> Alignment of records within a set >>> >>> We do not have explicit means for aligning records within a set. >>> However, >>> for template records the need is limited and they are aligned to >>> 32-bit >>> boundaries anyway. For data records we can use padding IEs at >>> the end >>> of a the record extending the length of the record to the next >>> alignment >>> boundary. Note that this way also the sets are aligned (up to 32- >>> bit >>> boundaries) within an IPFIX message, because also at the end of >>> the last >>> records within a set there is a padding IE. >>> >>> >>> Alignment of sets within an IPFIX message >>> >>> If records are already aligned within a set by using padding IEs, >>> then >>> this alignment is probably already achieved. But for aligning >>> sets within >>> an IPFIX message, the protocol further means, as described in >>> section 3.3.1 >>> of the protocol document. This padding mechanism can be applied >>> even if >>> the records within sets are not aligned. >>> >>> >>> Conclusion >>> >>> In my view, the main point of our discussion is whether it makes >>> sense >>> having this additional padding mechanism. I see advantages of >>> padding >>> within a record for aligning internal data structures and flow >>> records. >>> >>> But I see very little advantage in aligning sets if the sets and >>> their >>> contained flow records are not aligned also. >>> >>> Consequently, I suggest removing the padding at the end of a set >>> from >>> the protocol specification. >> I understand your way of thinking and agree with you when you >> wrote "But I see very little advantage in aligning sets if the >> sets and their contained flow records are not aligned also. " >> However, I'm not sure if your conclusion is the right one. >> I'm wondering why we should remove some flexibility from the IPFIX >> protocol specifications, some flexibility that requires little >> effort. >> Don't forget that the padding at the end of the Set is optional. >> See section 3.3.1 "The Exporting Process MAY insert some padding >> octets" >> I don't have right now a good example of why this would be needed. >> But maybe in the future? >> What about http://www.ietf.org/internet-drafts/draft-trammell- >> ipfix-file-00.txt? Would a Set alignment provide some benefits? >> I'm not sure yet, potentially. Why close the door now? >> >> >> With Paul Aitken, we went through padding again in the protocol >> draft. >> We would like to copy a sentence from [IPFIX-INFO] that should be >> part of [IPFIX-PROTO] >> Padding The Exporting Process MAY insert some padding octets, so >> that the subsequent Set starts at an aligned boundary. Padding >> MUST be composed of zero (0) octets. The padding length MUST be >> shorter than any allowable Record in this Set. If padding of the >> IPFIX Message is desired in combination with very short Records, >> then the padding Information Element 'paddingOctets' [IPFI-INFO] >> can be used for padding Flow Records such that their length is >> increased to a multiple of 4 or 8 octets. Because Template Sets >> are always 4-octet aligned by definition padding is only needed in >> case of other alignments e.g. on 8- octet boundaries. Further >> more, we would like to add a clarification in the section 9 " The >> Collecting Process's Side" The Collector MUST accept padding in >> Data Records and Template Records. The padding size is the Set >> Length minus the size of the Set Header (4 octets for the Set ID >> and the Set Length), modulo the Record size deduced from the >> Template Record. >> Any objections? >> >> Regards, Benoit. > --Apple-Mail-3--974185066 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.1 (Darwin) iD8DBQFDFekN4/8LCZ4pwvYRAgcKAKCtzF8uDy4GXPbljir0T421bypREQCgnBTO jsvDRPk4+qLdOls6PazEXpo= =ox7R -----END PGP SIGNATURE----- --Apple-Mail-3--974185066-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 31 16:56:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAZdZ-0001IC-QA for ipfix-archive@megatron.ietf.org; Wed, 31 Aug 2005 16:56:49 -0400 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 QAA14545 for ; Wed, 31 Aug 2005 16:56:42 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EAZUM-00071V-00 for ipfix-list@mil.doit.wisc.edu; Wed, 31 Aug 2005 15:47:18 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EAZUL-00071Q-00 for ipfix@net.doit.wisc.edu; Wed, 31 Aug 2005 15:47:17 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Aug 2005 22:47:16 +0200 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 j7VKlDVP012957; Wed, 31 Aug 2005 22:47:13 +0200 (MEST) Received: from [10.61.65.99] (ams-clip-vpn-dhcp355.cisco.com [10.61.65.99]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA02000; Wed, 31 Aug 2005 21:47:07 +0100 (BST) Message-ID: <43161749.3080307@cisco.com> Date: Wed, 31 Aug 2005 21:47:05 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.8) Gecko/20050603 Fedora/1.7.8-1.2.1.legacy X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu CC: Brian Trammell , Benoit Claise , Juergen Quittek , boschi@fokus.fraunhofer.de, Thomas Dietz Subject: Re: Padding summary, was: [ipfix] padding spec -> please state your point of view References: <88F766D04E6AF3409B39E60D7D933EB24FD562@europa.office> <4315B727.8090703@cisco.com> <4315D439.10004@cisco.com> <9388949B-0A0F-4D17-A4E1-9826090F01D5@cert.org> In-Reply-To: <9388949B-0A0F-4D17-A4E1-9826090F01D5@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 Trammell wrote: > Not required at the exporter, minimal effort required at the collector, > no document effort required to leave it in - I say we keep 3.3.1. I'm very much in agreement. Padding isn't mandated in the existing drafts; it's purely optional. So why go to the trouble of removing it? It makes the protocol less flexible and requires more work which delays us even further... If we removed it then we would have to write some new text mandating that the set length MUST be the exact size of the set, no more or less. And we'd have to decide whether a collector may, should, or must accept or reject records in sets with incorrect lengths. Whereas it's zero-effort, zero-confusion, max-clarity and max-flexibility to leave it alone. 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 Wed Aug 31 17:43:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAaMh-0006CT-0e for ipfix-archive@megatron.ietf.org; Wed, 31 Aug 2005 17:43:27 -0400 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 RAA17170 for ; Wed, 31 Aug 2005 17:43:23 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EAaHN-0000hT-00 for ipfix-list@mil.doit.wisc.edu; Wed, 31 Aug 2005 16:37:57 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EAaHL-0000hH-00 for ipfix@net.doit.wisc.edu; Wed, 31 Aug 2005 16:37:55 -0500 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8A6AE1BAC4D; Wed, 31 Aug 2005 23:37:52 +0200 (CEST) Date: Wed, 31 Aug 2005 23:38:00 +0200 From: Juergen Quittek To: Brian Trammell , Benoit Claise Cc: ipfix@net.doit.wisc.edu, Paul Aitken , boschi@fokus.fraunhofer.de, Thomas Dietz Subject: Re: Padding summary, was: [ipfix] padding spec -> please state your point of view Message-ID: <6DBCD35F85D34288CFE53F2A@[192.168.0.112]> In-Reply-To: <9388949B-0A0F-4D17-A4E1-9826090F01D5@cert.org> References: <9388949B-0A0F-4D17-A4E1-9826090F01D5@cert.org> 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 Hi Brian, --On 8/31/2005 7:29 PM +0200 Brian Trammell wrote: > Not required at the exporter, minimal effort required at the collector, > no document effort required to leave it in - I say we keep 3.3.1. You are right: it does not cost us much keeping it. You just forgot to mentions that it is of no practical use anymore since we introduced the padding IE. I am fine with still keeping it, but only because it is there and removing it would further delay the standardization process. We can make a recommendation not to use it when we write the IPFIX implementation guidelines. Thanks, Juergen > - Brian > > On Aug 31, 2005, at 12:00 PM, Benoit Claise wrote: > >> Dear all, >> >> Please state your point of view, as we're at the end of the last-call. >> Should the protocol draft continue to specify the optional padding >> at the end of Set (see section 3.3.1)? Or should this be removed? >> >> Regards, Benoit. >> >>> Juergen and all, >>>> Dear all, >>>> >>>> This is a try to summarize the discussion on padding. >>>> >>>> Since the last version (-10) of the info model we have an >>>> Information Element >>>> for padding of type octetArray. The protocol allows using >>>> encoding it as a >>>> fixed-length array as well as a variable length array. >>>> >>>> As a reminder, an IPFIX message is structures as follows: >>>> - IPFIX message contains sets >>>> - set contains records >>>> - data record contains Information Elements (IEs) >>>> - template record contains IE specifiers >>>> >>>> >>>> Alignment of IEs within a data record >>>> >>>> The padding IE gives us flexible means for aligning IEs within a >>>> data record. >>>> Aligning within a data record can be useful, because you may very >>>> easily >>>> convert internal data structures into flow records at the >>>> exporter and >>>> vice versa at the collector. >>>> >>>> >>>> Alignment of IE specifiers within a template record >>>> >>>> We do not have means for aligning IE specifiers within template >>>> records, >>>> but there is a limited need for it and IE specifiers are aligned >>>> to 32-bit >>>> address boundaries anyway. >>>> >>>> >>>> Alignment of records within a set >>>> >>>> We do not have explicit means for aligning records within a set. >>>> However, >>>> for template records the need is limited and they are aligned to >>>> 32-bit >>>> boundaries anyway. For data records we can use padding IEs at >>>> the end >>>> of a the record extending the length of the record to the next >>>> alignment >>>> boundary. Note that this way also the sets are aligned (up to 32- >>>> bit >>>> boundaries) within an IPFIX message, because also at the end of >>>> the last >>>> records within a set there is a padding IE. >>>> >>>> >>>> Alignment of sets within an IPFIX message >>>> >>>> If records are already aligned within a set by using padding IEs, >>>> then >>>> this alignment is probably already achieved. But for aligning >>>> sets within >>>> an IPFIX message, the protocol further means, as described in >>>> section 3.3.1 >>>> of the protocol document. This padding mechanism can be applied >>>> even if >>>> the records within sets are not aligned. >>>> >>>> >>>> Conclusion >>>> >>>> In my view, the main point of our discussion is whether it makes >>>> sense >>>> having this additional padding mechanism. I see advantages of >>>> padding >>>> within a record for aligning internal data structures and flow >>>> records. >>>> >>>> But I see very little advantage in aligning sets if the sets and >>>> their >>>> contained flow records are not aligned also. >>>> >>>> Consequently, I suggest removing the padding at the end of a set >>>> from >>>> the protocol specification. >>> I understand your way of thinking and agree with you when you >>> wrote "But I see very little advantage in aligning sets if the >>> sets and their contained flow records are not aligned also. " >>> However, I'm not sure if your conclusion is the right one. >>> I'm wondering why we should remove some flexibility from the IPFIX >>> protocol specifications, some flexibility that requires little >>> effort. >>> Don't forget that the padding at the end of the Set is optional. >>> See section 3.3.1 "The Exporting Process MAY insert some padding >>> octets" >>> I don't have right now a good example of why this would be needed. >>> But maybe in the future? >>> What about http://www.ietf.org/internet-drafts/draft-trammell- >>> ipfix-file-00.txt? Would a Set alignment provide some benefits? >>> I'm not sure yet, potentially. Why close the door now? >>> >>> >>> With Paul Aitken, we went through padding again in the protocol >>> draft. >>> We would like to copy a sentence from [IPFIX-INFO] that should be >>> part of [IPFIX-PROTO] >>> Padding The Exporting Process MAY insert some padding octets, so >>> that the subsequent Set starts at an aligned boundary. Padding >>> MUST be composed of zero (0) octets. The padding length MUST be >>> shorter than any allowable Record in this Set. If padding of the >>> IPFIX Message is desired in combination with very short Records, >>> then the padding Information Element 'paddingOctets' [IPFI-INFO] >>> can be used for padding Flow Records such that their length is >>> increased to a multiple of 4 or 8 octets. Because Template Sets >>> are always 4-octet aligned by definition padding is only needed in >>> case of other alignments e.g. on 8- octet boundaries. Further >>> more, we would like to add a clarification in the section 9 " The >>> Collecting Process's Side" The Collector MUST accept padding in >>> Data Records and Template Records. The padding size is the Set >>> Length minus the size of the Set Header (4 octets for the Set ID >>> and the Set Length), modulo the Record size deduced from the >>> Template Record. >>> Any objections? >>> >>> 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 Wed Aug 31 17:59:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAacO-0001iF-VR for ipfix-archive@megatron.ietf.org; Wed, 31 Aug 2005 17:59:41 -0400 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 RAA17925 for ; Wed, 31 Aug 2005 17:59:37 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EAaWu-0001Ne-00 for ipfix-list@mil.doit.wisc.edu; Wed, 31 Aug 2005 16:54:00 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EAaWt-0001NY-00 for ipfix@net.doit.wisc.edu; Wed, 31 Aug 2005 16:54:00 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Aug 2005 23:53:59 +0200 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 j7VLrtVP025437; Wed, 31 Aug 2005 23:53:56 +0200 (MEST) Received: from [10.61.65.99] (ams-clip-vpn-dhcp355.cisco.com [10.61.65.99]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA07845; Wed, 31 Aug 2005 22:53:54 +0100 (BST) Message-ID: <431626F0.7040300@cisco.com> Date: Wed, 31 Aug 2005 22:53:52 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.8) Gecko/20050603 Fedora/1.7.8-1.2.1.legacy X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Juergen Quittek CC: Brian Trammell , Benoit Claise , ipfix@net.doit.wisc.edu, boschi@fokus.fraunhofer.de, Thomas Dietz Subject: Re: Padding summary, was: [ipfix] padding spec -> please state your point of view References: <9388949B-0A0F-4D17-A4E1-9826090F01D5@cert.org> <6DBCD35F85D34288CFE53F2A@[192.168.0.112]> In-Reply-To: <6DBCD35F85D34288CFE53F2A@[192.168.0.112]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen, > You just forgot to mentions that it is of no practical use anymore > since we introduced the padding IE. Why do you say that? I consider that padding with the padding IE is *explicit* padding, because you clearly state "I am adding padding here". Whereas padding at the end of a set by making the set length longer than (the set header size) + (the number of records) x (the record size) is *implicit* padding, because you don't say anywhere that you're doing this; it's just extra, trailing data in the set that the collector has to deal with. We might not see any use for this today, but who's to say what might happen in future? eg, if someone invents a transport which is optimised for 1000-octet blocks? Then we might be quite glad we had the foresight not to disallow this possibility. > We can make a recommendation not to use it when we write the IPFIX > implementation guidelines. Rather, I would say "to use it appropriately", where "appropriately" is defined by the implimentation and customer requirements. 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 Wed Aug 31 18:38:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAbDU-0002BD-IT for ipfix-archive@megatron.ietf.org; Wed, 31 Aug 2005 18:38:01 -0400 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 SAA22366 for ; Wed, 31 Aug 2005 18:37:56 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EAb8z-0002mD-00 for ipfix-list@mil.doit.wisc.edu; Wed, 31 Aug 2005 17:33:21 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EAb8x-0002m3-00 for ipfix@net.doit.wisc.edu; Wed, 31 Aug 2005 17:33:19 -0500 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A16D41BAC4D; Thu, 1 Sep 2005 00:33:17 +0200 (CEST) Date: Thu, 01 Sep 2005 00:33:24 +0200 From: Juergen Quittek To: Paul Aitken Cc: Brian Trammell , Benoit Claise , ipfix@net.doit.wisc.edu, boschi@fokus.fraunhofer.de, Thomas Dietz Subject: Re: Padding summary, was: [ipfix] padding spec -> please state your point of view Message-ID: In-Reply-To: <431626F0.7040300@cisco.com> References: <9388949B-0A0F-4D17-A4E1-9826090F01D5@cert.org> <6DBCD35F85D34288CFE53F2A@[192.168.0.112]> <431626F0.7040300@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 Hi Paul, --On 8/31/2005 10:53 PM +0100 Paul Aitken wrote: > Juergen, > >> You just forgot to mentions that it is of no practical use anymore >> since we introduced the padding IE. > > Why do you say that? Because I think so. > I consider that padding with the padding IE is *explicit* padding, > because you clearly state "I am adding padding here". Yes, and it does not need any special support by the collector, because you just use an ordinary IE. > Whereas padding at the end of a set by making the set length longer than > (the set header size) + (the number of records) x (the record size) is > *implicit* padding, because you don't say anywhere that you're doing this; > it's just extra, trailing data in the set that the collector has to deal with. > > We might not see any use for this today, Thank you for sharing my view that there is no use case for this way of padding today. > but who's to say what might > happen in future? eg, if someone invents a transport which is optimised > for 1000-octet blocks? Then we might be quite glad we had the foresight > not to disallow this possibility. Sorry, I'm not foreseeing it. >> We can make a recommendation not to use it when we write the IPFIX >> implementation guidelines. > > Rather, I would say "to use it appropriately", where "appropriately" > is defined by the implimentation and customer requirements. Agreed. > Cheers. > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. Thanks, Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 31 18:50:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAbQ3-0005mR-Oe for ipfix-archive@megatron.ietf.org; Wed, 31 Aug 2005 18:50:59 -0400 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 SAA22925 for ; Wed, 31 Aug 2005 18:50:56 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EAbIL-00033t-00 for ipfix-list@mil.doit.wisc.edu; Wed, 31 Aug 2005 17:43:01 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EAbIK-00033j-00 for ipfix@net.doit.wisc.edu; Wed, 31 Aug 2005 17:43:00 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Sep 2005 00:47:19 +0200 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 j7VMguVP004045; Thu, 1 Sep 2005 00:42:56 +0200 (MEST) Received: from [10.61.65.99] (ams-clip-vpn-dhcp355.cisco.com [10.61.65.99]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA11658; Wed, 31 Aug 2005 23:42:54 +0100 (BST) Message-ID: <4316326C.5040407@cisco.com> Date: Wed, 31 Aug 2005 23:42:52 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.8) Gecko/20050603 Fedora/1.7.8-1.2.1.legacy X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Juergen Quittek CC: Brian Trammell , Benoit Claise , ipfix@net.doit.wisc.edu, boschi@fokus.fraunhofer.de, Thomas Dietz Subject: Re: Padding summary, was: [ipfix] padding spec -> please state your point of view References: <9388949B-0A0F-4D17-A4E1-9826090F01D5@cert.org> <6DBCD35F85D34288CFE53F2A@[192.168.0.112]> <431626F0.7040300@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen, >> Why do you say that? > > Because I think so. Indeed, it's the best reason. But then it begs the question "and why do you think so?" >> We might not see any use for this today, > > Thank you for sharing my view that there is > no use case for this way of padding today. When I say "We", I speak only for my team: it's easier for us not to impliment this optional part of the specification. While it's good that we are also in agreement with you, I cannot speak for anyone else - obviously they must do that for themselves - and I cannot predict with much accuracy what people may need of the protocol tomorrow. So I don't like to place undue restrictions where they are not necessary. >> but who's to say what might >> happen in future? eg, if someone invents a transport which is optimised >> for 1000-octet blocks? Then we might be quite glad we had the foresight >> not to disallow this possibility. > > Sorry, I'm not foreseeing it. I do not see that as any reason to mandate against extra flexibility in the protocol. 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 Wed Aug 31 19:51:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAcMJ-00014y-Pd for ipfix-archive@megatron.ietf.org; Wed, 31 Aug 2005 19:51:11 -0400 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 TAA27693 for ; Wed, 31 Aug 2005 19:51:07 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EAcDt-0005HY-00 for ipfix-list@mil.doit.wisc.edu; Wed, 31 Aug 2005 18:42:29 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EAcDs-0005HQ-00 for ipfix@net.doit.wisc.edu; Wed, 31 Aug 2005 18:42:28 -0500 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 6D49B1BAC4D; Thu, 1 Sep 2005 01:42:26 +0200 (CEST) Date: Thu, 01 Sep 2005 01:42:33 +0200 From: Juergen Quittek To: Paul Aitken Cc: Brian Trammell , Benoit Claise , ipfix@net.doit.wisc.edu, boschi@fokus.fraunhofer.de, Thomas Dietz Subject: Re: Padding summary, was: [ipfix] padding spec -> please state your point of view Message-ID: In-Reply-To: <4316326C.5040407@cisco.com> References: <9388949B-0A0F-4D17-A4E1-9826090F01D5@cert.org> <6DBCD35F85D34288CFE53F2A@[192.168.0.112]> <431626F0.7040300@cisco.com> <4316326C.5040407@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 Hi Paul, --On 8/31/2005 11:42 PM +0100 Paul Aitken wrote: > Juergen, > >>> Why do you say that? >> >> Because I think so. > > Indeed, it's the best reason. But then it begs the > question "and why do you think so?" I tried to explain it in the first message with subject 'Padding summary'. But the main reason why I think it is useless is that I do not see any concrete use case (as you do as well). >>> We might not see any use for this today, >> >> Thank you for sharing my view that there is >> no use case for this way of padding today. > > When I say "We", I speak only for my team: it's easier for us not > to impliment this optional part of the specification. > > While it's good that we are also in agreement with you, I cannot > speak for anyone else - obviously they must do that for themselves > - and I cannot predict with much accuracy what people may need of > the protocol tomorrow. So I don't like to place undue > restrictions where they are not necessary. I am not arguing for restrictions. I am arguing that there is a feature in the protocol that does not have a use case (at least not yet). >>> but who's to say what might >>> happen in future? eg, if someone invents a transport which is optimised >>> for 1000-octet blocks? Then we might be quite glad we had the foresight >>> not to disallow this possibility. >> >> Sorry, I'm not foreseeing it. > > I do not see that as any reason to mandate against extra flexibility in the protocol. The common procedure for standardizing protocol features is first identifying requirements based on scenarios and use cases. Without any use case, I do not see a requirement for the padding mechanism we have in the protocol document. Consequently, I do not see any need for standardizing this feature. > Cheers. > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de -- 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/