From 99adolphus@acadiacom.net Tue May 31 00:08:20 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11789 for ; Tue, 31 May 2005 00:08:20 -0400 (EDT) Received: from smtp.doit.wisc.edu ([144.92.9.43]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dcxl1-00028H-00 for ipfix-list@mil.doit.wisc.edu; Mon, 30 May 2005 22:49:35 -0500 Received: from pcp0012011045pcs.selrsv01.pa.comcast.net (pcp0012011045pcs.selrsv01.pa.comcast.net [69.249.130.13]) by smtp.doit.wisc.edu (8.13.3/8.12.6) with SMTP id j4V3nPeC115052 for ; Mon, 30 May 2005 22:49:29 -0500 Message-ID: <232f01c5665a$330057ce$10010ed1@acadiacom.net> From: "Richard K. Lee" <99adolphus@acadiacom.net> To: ipfix-list@mil.doit.wisc.edu Subject: =?iso-8859-1?B?Q2lhbGlzIC0gZHV0eS1mcmVlIHByaWNl?= Date: Wed, 01 Jun 2005 03:35:05 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_FFD24835.7E86D212" 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_FFD24835.7E86D212 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_C6C96112.64F56869" ------=_NextPart_001_0001_C6C96112.64F56869 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Perfect erection Prolonged effect No prescription required Only $2.99/$1.99 per dose (2 doses in each pill): CIALIS - http://www.popularpills.biz/sv/ VIAGRA - http://www.popularpills.biz/vt/ Discreet packaging _________________________________________________________________________ To change your mail preferences, go here _________________________________________________________________________ ------=_NextPart_001_0001_C6C96112.64F56869 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Perfect erection
Prolonged effect
No prescription required

Only $2.99/$1.99 per dose (2 doses in each pill):
CIALIS - http://www.popularpills.biz/sv/
VIAGRA - http://www.popularpills.biz/vt/

Discreet packaging

_________________________________________________________________________
To change your mail preferences, go here
_________________________________________________________________________

------=_NextPart_001_0001_C6C96112.64F56869-- ------=_NextPart_000_0000_FFD24835.7E86D212-- From Rudyard@jleduc.com Wed Jun 1 01:51:53 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00622 for ; Wed, 1 Jun 2005 01:51:53 -0400 (EDT) Received: from host41-46.pool8248.interbusiness.it ([82.48.46.41] helo=jleduc.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DdLpf-0005UL-00 for ipfix-list@mil.doit.wisc.edu; Wed, 01 Jun 2005 00:32:00 -0500 From: "Rudyard Medina" To: "Kortney Rubio" Subject: Re: My Girl Looves the New Me Date: Wed, 1 Jun 2005 00:31:57 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C5666B.39F7C480" 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?82.48.46.41 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C5666B.39F7C480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, very considerable time. This, I insist, is no reflection upon histhat = they had actively roused themselves, Wolverstone's sloop wasOf your = honesty, M. de Rivarol.slave, and has no power to shape his fate. = Peter Blood was sold For we laid her board and board,of the = Captain's, and fell into step beside him.and in announcing that he = preferred it to England, he had indulgedlonger in a foetid gaol with = great peril to my health and even life.not England answer now?were = past. Meanwhile their treatment at the hands of Don Miguelman's arm, = and bade him open his mouth that he might see his teeth.treasure-ship = of the fleet, with plate on board to the value ofThe man was tall and = built on lines of agile strength, with aIt remains for you, monsieur, = who have experience of these savageis sending me to Europe in my = brother's charge. I implore you,You shall be advised of my resolve. ------=_NextPart_000_0026_01C5666B.39F7C480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,mariners he = had brought from France. He had left behind him at do you = need to spend Iess on your druggs?

SavBut, = sir... one of them began.e over 70% with PharrThe = stranger's fingers touched the top of Don Diego's = head,macyByMail Shop

moment = indifferently victualled for a long voyage. The crews = ofVlAGRA VAimproper.LlUM = Clquivering with anger.ALlS = LEVlWhen he had done, Captain Blood, = who until that moment had stoodTRA and many = other.

With each purchase youthirds of them were armed with muskets, some of which they had = found get:

Top purchased his = own pardon for forty thousand pounds. Peter = BloodquaIity

BEST PRlCESaved you? = Miss Bishop was aghast. Saved you from what, Mary?S

Total conheadlong, = into speech, gasping, breathless.fidentiaIity

Home devessel grew = clearer. Presently her masts stood out sharp and = blackIivery

------=_NextPart_000_0026_01C5666B.39F7C480-- From majordomo@mil.doit.wisc.edu Wed Jun 1 02:01:31 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02624 for ; Wed, 1 Jun 2005 02:01:31 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DdM2M-0005fT-00 for ipfix-list@mil.doit.wisc.edu; Wed, 01 Jun 2005 00:45:06 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DdM2L-0005fO-00 for ipfix@net.doit.wisc.edu; Wed, 01 Jun 2005 00:45:05 -0500 Received: from [192.168.0.112] (HSI-KBW-082-212-046-135.hsi.kabelbw.de [82.212.46.135]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 26E231BAC4D for ; Wed, 1 Jun 2005 07:45:03 +0200 (CEST) Date: Wed, 01 Jun 2005 07:45:02 +0200 From: Juergen Quittek To: ipfix@net.doit.wisc.edu Subject: [ipfix] IPFIX interoperability testing in Paris 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, At the IETF meeting in Washington we discussed about an IPFIX interoperability testing event as soon as the documents are in a mature state. This has been achieved with the new versions of all our documents that have been posted this week. On the three days before the IETF meeting in Paris there will be a first IPFIX interoperability testing event at the same location as the IETF meeting. It is hosted by two European research projects and by ETSI. Participation is free of charge. The event will give us valuable feedback on ambiguities and missing clarifications in our IPFIX documents. Everybody who already has an implementation of IPFIX is very welcome. Let's see how many independent implementations are already out there. Please find a preliminary announcement at http://www.ist-mome.org/events/interop/. Note that the list of drafts given as reference for IPFIX on this web page are not the current ones. This will be updated to the new versions in the next days. Also there are no description of test cases available, yet. These will be provided until mid of June on the same web page. 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 Jun 1 02:28:14 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02634 for ; Wed, 1 Jun 2005 02:28:14 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DdMXv-00079Z-00 for ipfix-list@mil.doit.wisc.edu; Wed, 01 Jun 2005 01:17:43 -0500 Received: from groucho.itss.auckland.ac.nz ([130.216.190.11] helo=smtpa.itss.auckland.ac.nz) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DdMXu-00079O-00 for ipfix@net.doit.wisc.edu; Wed, 01 Jun 2005 01:17:42 -0500 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 308FF34D3A for ; Wed, 1 Jun 2005 18:17:41 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11206-16 for ; Wed, 1 Jun 2005 18:17:41 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 16DBE345C1 for ; Wed, 1 Jun 2005 18:17:41 +1200 (NZST) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id j516Hff04618 for ipfix@net.doit.wisc.edu; Wed, 1 Jun 2005 18:17:41 +1200 Received: from dhcp-38-21.cs.auckland.ac.nz (dhcp-38-21.cs.auckland.ac.nz [130.216.38.236]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Wed, 1 Jun 2005 18:17:40 +1200 Message-ID: <1117606660.609c196d245c5@webmail.auckland.ac.nz> Date: Wed, 1 Jun 2005 18:17:40 +1200 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] WG last call on all four 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.38.236 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all: After our meeting at IETF in Minneapolis we agreed to revise the drafts to reflect the discussions there, then run another WG last call. The revisions have taken quite a while, but we now have the drafts ready. The current versions are: Architecture 08.txt Protocol 15.txt Info 07.txt AS 05.txt This email signals the start of a new WG last call. It will end in two weeks, i.e. about 15 June. Provided no new problems (show-stoppers, not simple editorial changes) emerge,we'll then be ready to 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 naeemcheema20@yahoo.se Wed Jun 1 08:17:09 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11146 for ; Wed, 1 Jun 2005 08:17:09 -0400 (EDT) Received: from [217.165.63.227] (helo=yahoo33.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DdRym-0006w4-00 for ipfix-list@mil.doit.wisc.edu; Wed, 01 Jun 2005 07:05:48 -0500 From: Naeem To: ipfix-list@mil.doit.wisc.edu Reply-To: naeemcheema@excite.com Subject: Best regards Date: Wed, 01 Jun 2005 16:05:48 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="acfe02d6-8393-4434-a6e7-4d6019a56bef" Message-Id: This is a multi-part message in MIME format --acfe02d6-8393-4434-a6e7-4d6019a56bef Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From The Desk of Mr. Naeem Cheema Manager National Bank of Abu Dhabi Dubai United Arab Emirate (U.A.E.) Email: naeemcheema2000@excite.com I am Mr. Naeem Cheema Branch Manger of national bank of Abu Dhabi I am = writing following an Opportunity in my office that will be of immense benefit = to both of us. In my department I discovered an abandoned sum of $12, million = ($12, 000, 000, 00) United state dollars) in an account that belongs to one = of our foreign customers, Late Mr. Morris Thompson an American who unfortunately lost his life In the plane crash of Alaska Airlines Flight 261 which crashed on January 31 2000, including his wife and only daughter. You shall read More about the crash on visiting this site. http://www.cnn.com/2000/US/02/01/alaska.airlines.list/ and http://www.nativefederation.org/history/people/mThompson.html Since we got information about his death, we have been expecting his Next of kin or relatives to come over and claim his money because we Cannot release it unless somebody applies for it as next of kin or Relation to the deceased as indicated in our banking guidelines. Unfortunately I learnt that his supposed next of kin being his only Daughter died along with him in the plane crash leaving nobody with The knowledge of this fund behind for the claim, and the banking law and = guidelines here united Arab emirate that such money Remained after six years = the money will be transferred into banking treasury as unclaimed funds, Note: I want you to stand as the business patina of Late Morris Thompson so = that my bank can transfer the money to your account with out any problem, so = now I will like you to provide me your full name and address so that the = attorney will prepare the necessary documents and affidavit that will put you = in place as the next of kin of late Morris Thompson, We shall employ the services of an attorney for drafting and notarization of = the will and to obtain the necessary documents and letter of probate = administration in your favor for the transfer A bank account in any part of = the world, then I will facilitate the transfer of this money to you as the = beneficiary next of kin, The money will be paid into your account for us to share in the ratio of 60% = form and 40% for you, there is no risk at all as the paperwork For this transaction will be done by the attorney and my position as branch = manager guarantees the successful execution of this transaction if you are = interested, please reply immediately via the private email address above, Upon your response, I shall then provide you with more details and relevant documents that will help you understand the transaction. Please send me your confidential telephone and fax numbers for easy communication. Please observe = utmost confidentiality, and rest assured that this transaction would be most profitable for both of us because I shall require your assistance to invest my share in your country. Please reply me through this my private email = address: naeemcheema2000@excite.com Waiting to hear from you Best regards, Mr. Naeem Cheema --acfe02d6-8393-4434-a6e7-4d6019a56bef-- From majordomo@mil.doit.wisc.edu Thu Jun 2 06:48:26 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29210 for ; Thu, 2 Jun 2005 06:48:26 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DdmoC-0001Ip-00 for ipfix-list@mil.doit.wisc.edu; Thu, 02 Jun 2005 05:20:16 -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 1DdmoB-0001Ih-00 for ipfix@net.doit.wisc.edu; Thu, 02 Jun 2005 05:20:15 -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 j52AKC417000; Thu, 2 Jun 2005 12:20:12 +0200 (CEST) Received: from [10.61.80.114] (ams-clip-vpn-dhcp4211.cisco.com [10.61.80.114]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j52AKAF08589; Thu, 2 Jun 2005 12:20:11 +0200 (CEST) Message-ID: <429EDD58.7090309@cisco.com> Date: Thu, 02 Jun 2005 12:20:08 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nevil Brownlee CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] WG last call on all four IPFIX drafts References: <1117606660.609c196d245c5@webmail.auckland.ac.nz> In-Reply-To: <1117606660.609c196d245c5@webmail.auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Nevil, Do we have any news about IANA? Regards, Benoit. >Hi all: > >After our meeting at IETF in Minneapolis we agreed to revise the >drafts to reflect the discussions there, then run another WG last call. >The revisions have taken quite a while, but we now have the drafts >ready. The current versions are: > > Architecture 08.txt > Protocol 15.txt > Info 07.txt > AS 05.txt > >This email signals the start of a new WG last call. It will end >in two weeks, i.e. about 15 June. Provided no new problems (show-stoppers, >not simple editorial changes) emerge,we'll then be ready to 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/ > > -- 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 Jun 2 06:54:29 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29576 for ; Thu, 2 Jun 2005 06:54:28 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DdmtU-0001MG-00 for ipfix-list@mil.doit.wisc.edu; Thu, 02 Jun 2005 05:25:44 -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 1DdmtT-0001M8-00 for ipfix-arch@net.doit.wisc.edu; Thu, 02 Jun 2005 05:25:43 -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 j52APee17333; Thu, 2 Jun 2005 12:25:40 +0200 (CEST) Received: from [10.61.80.114] (ams-clip-vpn-dhcp4211.cisco.com [10.61.80.114]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j52APdF13302; Thu, 2 Jun 2005 12:25:39 +0200 (CEST) Message-ID: <429EDEA1.4030901@cisco.com> Date: Thu, 02 Jun 2005 12:25:37 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nevil Brownlee CC: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] simple editorial changes for the architecture draft version 8 Content-Type: multipart/alternative; boundary="------------030206050705050201030202" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------030206050705050201030202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Nevil, I reviewed the architecture draft one last time. Here is a list of simple editorial changes. - Note that *_vvery_ Observation Point is associated with an Observation Domain (defined below), and that* one Observation Point may be a superset of several other Observation Points. For example one Observation Point can be an entire line card. That would be the superset of the individual Observation Points at the line card's interfaces. vvery -> every. Btw, as we say "For the same terms defined here and in IPFIX-PROTO [3] the definitions are equivalent in both documents.", I will update this in IPFIX-PROTO. - you should update the observation domain definition, to make it consistent with IPFIX-PROTO. Observation Domain An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. Each Observation Domain presents itself using a unique ID to the Collecting Process to identify the IPFIX Messages it generates. For example, a router line card may be an observation domain if it is composed of several interfaces: each of which is an Observation Point. _Every Observation Point is associated with an Observation Domain. _ -> add the last sentence - "1. Changes/Issues from the -07 Draft" will have to be removed before the next version for the IESG :) - section 7.3 Control Information "The ID must be sent within the Flow Records in order to be able to match the right configuration _control information_" -> Control Information - 6.3.2 Filter Functions, Fi Several such filters could be used in any sequence to select packets. Note that packets selected by a (sequence of) filter function(s) may be further classified by other filter functions, i.e. the selected packets may belong to several Flows, any or all of which are exported. At the minimum, change: function -> function(s) Now, I'm wondering if the sentence makes sense. New proposal: Several such filters could be used in any sequence to select packets. Note that packets selected by a filter function may be further classified by other filter functions, i.e. the selected packets may belong to several Flows, any or all of which are exported. - Section 6.7 Summary +--------------------|----------------------------------------------+ | | Exporting Process | |+-------------------|-------------------------------------------+ | || v IPFIX Protocol | | ||+-----------------------------+ +----------------------------+| | |||Rules for | |Functions || | ||| Picking/sending Templates | |-Packetize selected Control || | ||| Picking/sending Flow Records|->| & data Information into || | ||| Encoding Template & data | | IPFIX export packets. || | ||| Selecting Flows to export(*)| |-Handle export errors || | ||+-----------------------------+ +----------------------------+| | |+----------------------------+----------------------------------+ | |+----------------------------+----------------------------------+ | | | | | exported IPFIX Messages | | | | | +------------+-----------------+ | | | Anonymize export packet(*) | | | +------------+-----------------+ | | | | | +------------+-----------------+ | | | Transport Protocol | | | +------------+-----------------+ | | | | +-----------------------------+-------------------------------------+ IPFIX export packets -> IPFIX Messages Anonymize export packet(*) -> Anynomize IPFIX Messages (*) - section 7.1 Information Model Overview However, the list of fields that can be transmitted by the protocol, such as Flow attributes (source IP address, number of packets, etc.) and information about the Metering and Exporting Process (packet Observation Point, sampling rate, Flow timeout interval, etc.), is not specified in IPFIX-PROTO [3]. Flow timeout -> Flow timeout - there are 3 occurrences of "Field Type". See section 7.1 and 13.2 (two times) "Field Type" should not be capitalized, as there is no definition. The second occurrence says: "Within an IPFIX message the field type is indicated by its Field Type." Proposal: Within an IPFIX message the field type is indicated by its "field type" [IPFIX-PROTO] - Section 8. IPFIX Protocol Details When the IPFIX Working Group was chartered there were existing common practices in the area of Flow export, for example NetFlow, CRANE, LFAP, RTFM, etc. do you want to add the references? You will find the right format in RFC3955 NetFlow: RFC3954 CRANE: RFC3423 LFAP: RFC2124 RTFM: Nevil, you should know the RFC - A minor point. Shouldn't we group the authors by affiliations in the top page. Regards, Benoit. ** --------------030206050705050201030202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi Nevil,

I reviewed the architecture draft one last time.
Here is a list of simple editorial changes.

-  Note that vvery Observation Point is associated with an
      Observation Domain (defined below), and that one Observation Point
      may be a superset of several other Observation Points.  For
      example one Observation Point can be an entire line card.  That
      would be the superset of the individual Observation Points at the
      line card's interfaces.

	vvery -> every.

Btw, as we say "For the same terms defined here and in IPFIX-PROTO [3] the definitions are equivalent in both documents.", I will update this in IPFIX-PROTO.

- you should update  the observation domain definition, to make it consistent with IPFIX-PROTO.
 Observation Domain 
    
   An Observation Domain is the largest set of Observation Points for 
   which Flow information can be aggregated by a Metering Process.  
   Each Observation Domain presents itself using a unique ID to the 
   Collecting Process to identify the IPFIX Messages it generates.  For 
   example, a router line card may be an observation domain if it is 
   composed of several interfaces: each of which is an Observation 
   Point.  Every Observation Point is associated with an Observation 
   Domain. 

	-> add the last sentence

- "1.  Changes/Issues from the -07 Draft" will have to be removed before the next version for the IESG :)

- section 7.3  Control Information
   "The ID must be sent within the Flow Records in order to be able to match the right configuration
   control information"
   	
	-> Control Information

-  6.3.2  Filter Functions, Fi

   Several such filters could be used in any sequence to select packets.
   Note that packets selected by a (sequence of) filter function(s) may be
   further classified by other filter functions, i.e. the selected
   packets may belong to several Flows, any or all of which are
   exported.

   At the minimum, change: function -> function(s)

   Now, I'm wondering if the sentence makes sense. 
   New proposal:
   Several such filters could be used in any sequence to select packets.
   Note that packets selected by a filter function may be
   further classified by other filter functions, i.e. the selected
   packets may belong to several Flows, any or all of which are
   exported.

-  Section 6.7  Summary
   +--------------------|----------------------------------------------+
   |                    |     Exporting Process                        |
   |+-------------------|-------------------------------------------+  |
   ||                   v       IPFIX Protocol                      |  |
   ||+-----------------------------+  +----------------------------+|  |
   |||Rules for                    |  |Functions                   ||  |
   ||| Picking/sending Templates   |  |-Packetize selected Control ||  |
   ||| Picking/sending Flow Records|->|  & data Information into   ||  |
   ||| Encoding Template & data    |  |  IPFIX export packets.     ||  |
   ||| Selecting Flows to export(*)|  |-Handle export errors       ||  |
   ||+-----------------------------+  +----------------------------+|  |
   |+----------------------------+----------------------------------+  |
   |+----------------------------+----------------------------------+  |
   |                             |                                     |
   |                    exported IPFIX Messages                        |
   |                             |                                     |
   |                +------------+-----------------+                   |
   |                |  Anonymize export packet(*)  |                   |
   |                +------------+-----------------+                   |
   |                             |                                     |
   |                +------------+-----------------+                   |
   |                |       Transport  Protocol    |                   |
   |                +------------+-----------------+                   |
   |                             |                                     |
   +-----------------------------+-------------------------------------+

   IPFIX export packets -> IPFIX Messages
   Anonymize export packet(*) -> Anynomize IPFIX Messages (*)

-  section 7.1  Information Model Overview

   However, the
   list of fields that can be transmitted by the protocol, such as Flow
   attributes (source IP address, number of packets, etc.) and
   information about the Metering and Exporting Process (packet
   Observation Point, sampling rate, Flow  timeout interval, etc.), is
   not specified in IPFIX-PROTO [3].  
	Flow  timeout -> Flow timeout

- there are 3 occurrences of "Field Type". See section 7.1 and 13.2 (two times)
  "Field Type" should not be capitalized, as there is no definition.

  The second occurrence says: "Within an IPFIX message the field type is indicated by its Field Type."
  Proposal: Within an IPFIX message the field type is indicated by its "field type" [IPFIX-PROTO]

-  Section 8.  IPFIX Protocol Details

   When the IPFIX Working Group was chartered there were existing common
   practices in the area of Flow export, for example NetFlow, CRANE,
   LFAP, RTFM, etc.  

   do you want to add the references? You will find the right format in RFC3955
	NetFlow: RFC3954
	CRANE: RFC3423
	LFAP: RFC2124
	RTFM: Nevil, you should know the RFC

- A minor point. Shouldn't we group the authors by affiliations in the top page.

Regards, Benoit.

--------------030206050705050201030202-- -- 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 Jun 3 05:09:35 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07204 for ; Fri, 3 Jun 2005 05:09:35 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1De7mS-0003zd-00 for ipfix-list@mil.doit.wisc.edu; Fri, 03 Jun 2005 03:43:52 -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 1De7mR-0003zX-00 for ipfix-info@net.doit.wisc.edu; Fri, 03 Jun 2005 03:43:51 -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 j538hlH07101 for ; Fri, 3 Jun 2005 10:43:47 +0200 (CEST) Received: from [10.61.64.27] (ams-clip-vpn-dhcp27.cisco.com [10.61.64.27]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j538hlF14517 for ; Fri, 3 Jun 2005 10:43:47 +0200 (CEST) Message-ID: <42A01840.10505@cisco.com> Date: Fri, 03 Jun 2005 10:43:44 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-info@net.doit.wisc.edu Subject: [ipfix-info] IANA in IPFIX-INFO: extension? 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, The IANA section in IPFIX is pretty light, while it's fully specified in IPFIX-ARCH. If IPFIX-INFO is standard track (*), shouldn't expand this IANA section with information in IPFIX-ARCH? If IPFIX-INFO is not standard track but IPFIX-ARCH is, then a pointer to the IPFIX-ARCH IANA section would already be a plus. (*) I'm always confused by which drafts will be standard track or not Regards, Benoit. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Jun 3 05:55:35 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11632 for ; Fri, 3 Jun 2005 05:55:35 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1De8iQ-0004pp-00 for ipfix-list@mil.doit.wisc.edu; Fri, 03 Jun 2005 04:43:46 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1De8iO-0004ph-00 for ipfix-info@net.doit.wisc.edu; Fri, 03 Jun 2005 04:43:44 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7700ED9E8; Fri, 3 Jun 2005 11:56:08 +0200 (CEST) Received: from [10.1.1.171] ([10.1.1.171]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Jun 2005 11:44:06 +0200 Date: Fri, 03 Jun 2005 11:43:43 +0200 From: Juergen Quittek To: Benoit Claise , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] IANA in IPFIX-INFO: extension? Message-ID: In-Reply-To: <42A01840.10505@cisco.com> References: <42A01840.10505@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 03 Jun 2005 09:44:06.0633 (UTC) FILETIME=[C8C20D90:01C56820] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, IPFIX-PROTOCOL and IPFIX-INFO will definitely be standards track. So far I thought that IPFIX-ARCH would become informational, but I am not sure about this. The IAMA considerations in IPFIX-ARCH have two sub-sections (13.1 and 13.2). 13.1 applies to the protocol and 13.2 to the info model. So content-wise 13.2 should be reflected by the IANA considerations in IPFIX-INFO. I agree that the first paragraph in the IANA considerations section of IPFIX-INFO is rather light. I suggest to replace it by the second paragraph of section 12.2 in IPFIX-PROTO. Thanks, Juergen --On 6/3/2005 10:43 AM +0200 Benoit Claise wrote: > Dear all, > > The IANA section in IPFIX is pretty light, while it's fully specified in IPFIX-ARCH. > If IPFIX-INFO is standard track (*), shouldn't expand this IANA section with information in IPFIX-ARCH? > If IPFIX-INFO is not standard track but IPFIX-ARCH is, then a pointer to the IPFIX-ARCH IANA section would already be a plus. > > (*) I'm always confused by which drafts will be standard track or not > > 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 Fri Jun 3 06:20:03 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13225 for ; Fri, 3 Jun 2005 06:20:02 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1De9Az-0005xY-00 for ipfix-list@mil.doit.wisc.edu; Fri, 03 Jun 2005 05:13:17 -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 1De9Ay-0005x1-00 for ipfix-info@net.doit.wisc.edu; Fri, 03 Jun 2005 05:13:16 -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 j53ADFI13050; Fri, 3 Jun 2005 12:13:15 +0200 (CEST) Received: from [10.61.64.27] (ams-clip-vpn-dhcp27.cisco.com [10.61.64.27]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j53ADEF14080; Fri, 3 Jun 2005 12:13:14 +0200 (CEST) Message-ID: <42A02D38.5090801@cisco.com> Date: Fri, 03 Jun 2005 12:13:12 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] IANA in IPFIX-INFO: extension? References: <42A01840.10505@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, > Hi Benoit, > > IPFIX-PROTOCOL and IPFIX-INFO will definitely be standards track. > So far I thought that IPFIX-ARCH would become informational, > but I am not sure about this. > > The IAMA considerations in IPFIX-ARCH have two sub-sections > (13.1 and 13.2). > > 13.1 applies to the protocol and 13.2 to the info model. > So content-wise 13.2 should be reflected by the IANA considerations > in IPFIX-INFO. > > I agree that the first paragraph in the IANA considerations section > of IPFIX-INFO is rather light. I suggest to replace it by the > second paragraph of section 12.2 in IPFIX-PROTO. That makes sense. Regards, Benoit. > > Thanks, > > Juergen > > > --On 6/3/2005 10:43 AM +0200 Benoit Claise wrote: > >> Dear all, >> >> The IANA section in IPFIX is pretty light, while it's fully specified >> in IPFIX-ARCH. >> If IPFIX-INFO is standard track (*), shouldn't expand this IANA >> section with information in IPFIX-ARCH? >> If IPFIX-INFO is not standard track but IPFIX-ARCH is, then a pointer >> to the IPFIX-ARCH IANA section would already be a plus. >> >> (*) I'm always confused by which drafts will be standard track or not >> >> 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 Fri Jun 3 07:49:52 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18915 for ; Fri, 3 Jun 2005 07:49:52 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DeATt-0007F5-00 for ipfix-list@mil.doit.wisc.edu; Fri, 03 Jun 2005 06:36: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 1DeATs-0007Ez-00 for ipfix-info@net.doit.wisc.edu; Fri, 03 Jun 2005 06:36:52 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 03 Jun 2005 13:36:52 +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 j53Bal7F029744; Fri, 3 Jun 2005 13:36:48 +0200 (MEST) Received: from cisco.com (ams-clip-vpn-dhcp4525.cisco.com [10.61.81.172]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA01801; Fri, 3 Jun 2005 12:36:47 +0100 (BST) Message-ID: <42A040CE.70302@cisco.com> Date: Fri, 03 Jun 2005 12:36:46 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise CC: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] IANA in IPFIX-INFO: extension? References: <42A01840.10505@cisco.com> In-Reply-To: <42A01840.10505@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Protocol will be STDs. An arch RFC does not usually need to be STDs, because it does not usually specify anything needed for interoperability. Info should be STD as well, since it contains the default set of IEs, and contains the .xml to set them up. Since it is the document that causes IANA to set up the IE registry it should be the place where we define the IE policy. - Stewart Benoit Claise wrote: > Dear all, > > The IANA section in IPFIX is pretty light, while it's fully specified in > IPFIX-ARCH. > If IPFIX-INFO is standard track (*), shouldn't expand this IANA section > with information in IPFIX-ARCH? > If IPFIX-INFO is not standard track but IPFIX-ARCH is, then a pointer to > the IPFIX-ARCH IANA section would already be a plus. > > (*) I'm always confused by which drafts will be standard track or not > > 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 Lin5293@hk.com Sat Jun 4 02:59:27 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10381 for ; Sat, 4 Jun 2005 02:59:26 -0400 (EDT) Received: from [61.253.44.202] (helo=hk.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DeSHM-0007DE-00 for ipfix-list@mil.doit.wisc.edu; Sat, 04 Jun 2005 01:37:08 -0500 From: "Tehila Lin" To: "Hayfa Edmondson" Subject: Re: EExtra news Date: Sat, 4 Jun 2005 01:37:05 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C568CF.D28E7E80" 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?61.253.44.202 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C568CF.D28E7E80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, In the great harbour of Port Royal, spacious enough to have givenThief = and pirate should he prove henceforth; no more nor less; asnot trouble = your excellency with this letter but that I am a humaneIt is what has = happened. Come and look.fellow-slaves awaited him in deep anxiety and = some hope.a steady haughtiness that went well with his firm lips. = ThoughPLANS OF ESCAPEat Gibraltar not only time to hear of our coming, = but time in whichirony. They were in the Dutch brig.Not that he was = by any means a coward. But this cooped-up fightingdone - that they = were coming into some wild, savage country, theI would have stayed if = it could have availed.He broke off abruptly. A moment he frowned, = deep in thought; thenthat was the Governor's office, when Major = Mallard brought him wordbefore all these gentlemen who have the honour = to serve the Kingthe ships. ------=_NextPart_000_0002_01C568CF.D28E7E80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, dto = shift the greater number and the more powerful of their gunso = you want to spend Iess on your meddications?

Our neUntil who died?w great offer -

Save The Baron swung upon him snarling. He = understands his business,over 75% with Pharmathem was sick and the = other half sickening, this rogue kept his legscyByMail = Shop

VlAA storm = or something else, said Cahusac grimly. Have youGRA ClAArabella, yet knew her beyond his reach = irrevocably and for all time.LlS VALthat gleaming pistol, Bishop obeyed without demur. His = recentlUM with the same quiet = efficiency. Peter Blood had a genius for theseLEVlTRA and many = other.

With each purrchthe = broiling heat, to climb the heights to the north of the = town,ase you get:

Top quaThen the = Captain stepped to the press, and pulled open one of = theIity

BesHe vowed that the = thought of her should continue ever before himt prices

Total cglad to have = some one upon whom he could fasten the sharp fangs = ofonfidentiaIity

Home deIiveashore.ry

P.lordship saw = ahead beyond the English ship and to larboard of herS. Try us = and you will not be disappointed!

------=_NextPart_000_0002_01C568CF.D28E7E80-- From Pittman_8495@gdamsea.com Mon Jun 6 18:00:19 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21718 for ; Mon, 6 Jun 2005 18:00:18 -0400 (EDT) Received: from [85.48.2.3] (helo=gdamsea.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DfPNz-0004KN-00 for ipfix-list@mil.doit.wisc.edu; Mon, 06 Jun 2005 16:43:58 -0500 From: "Stamatia Pittman" To: "Maryam Swanson" Subject: Re: Sexual Rebbirth Date: Mon, 6 Jun 2005 16:43:49 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C56AE0.D2B19880" 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_0012_01C56AE0.D2B19880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, directions of Hayton, the bo'sun, the swabbers were at work in = thegold-laced coat that advertised his new position, and slippingof = governors, advanced him money for the proper equipment of hisin to the = harbour mouth, within saker shot of Rivarol's threelater that day, the = division made, they would have parted companyI see that you = understand, Bishop laughed coarsely. Two birdsview, and equally = arrested and at gaze, stood Lord Julian. But heYou'll keep that = opinion to yourself, the Captain answered him.He maybe lean, but he's = tough; tough and healthy. When half ofHis excellency frowned = thoughtfully. I understand... in part,Colonel Kirke if his lordship = should be handled like a common felon.had announced that he might be = expected.which might be converted into gold and shared amongst them = all.- a Spanish ship, perforce, since none other would be so boldlywho = would satisfy their curiosity to a surfeit. On that he shooklevel yet = with M. de Rivarol, and wipe off some other scores at the ------=_NextPart_000_0012_01C56AE0.D2B19880 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, do you want to spend Iess on your dby the pennon she was flying. The sight = thrilled her curiously; itrrugs?

The PHARMACY-BY-MAlHe was a little bewildered.L = SHOP offeindifferent handling = of their ships led to the sinking of two ofrs you a great = deaI

VlASpain.GRA = VAat mademoiselle, and observed the grey = despair that had almostLlUM Clforce.ALlS Lthey added six = barrels of gunpowder, placed on end like guns at theEVlTRA and = many other.

With eathe means to = be adopted.ch purchase you get:

out from Brest under the command of M. = le Baron de Rivarol forGreat Prices

Tnot, this man will butcher us all = without mercy.op quaIity

Homethat William of Orange had been = invited to come over. deIivery

Totalexquisite than death. = confidentiaIity

Try us and you wilbear such fruit that a change of climate was desirable. = Williaml not be disappointed!

------=_NextPart_000_0012_01C56AE0.D2B19880-- From majordomo@mil.doit.wisc.edu Mon Jun 6 18:23:30 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25014 for ; Mon, 6 Jun 2005 18:23:29 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DfPjE-0004sO-00 for ipfix-list@mil.doit.wisc.edu; Mon, 06 Jun 2005 17:05:52 -0500 Received: from groucho.itss.auckland.ac.nz ([130.216.190.11] helo=smtpa.itss.auckland.ac.nz) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DfPjC-0004sF-00 for ipfix-info@net.doit.wisc.edu; Mon, 06 Jun 2005 17:05:50 -0500 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 26BFB3468E; Tue, 7 Jun 2005 10:05:49 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03276-05; Tue, 7 Jun 2005 10:05:49 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 09F6434192; Tue, 7 Jun 2005 10:05:49 +1200 (NZST) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id j56M5mp03398; Tue, 7 Jun 2005 10:05:48 +1200 Received: from dhcp-38-21.cs.auckland.ac.nz (dhcp-38-21.cs.auckland.ac.nz [130.216.38.236]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Tue, 7 Jun 2005 10:05:48 +1200 Message-ID: <1118095548.7b7cc7b84b8ab@webmail.auckland.ac.nz> Date: Tue, 7 Jun 2005 10:05:48 +1200 From: Nevil Brownlee To: Stewart Bryant Cc: Benoit Claise , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] IANA in IPFIX-INFO: extension? References: <42A01840.10505@cisco.com> <42A040CE.70302@cisco.com> In-Reply-To: <42A040CE.70302@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.38.236 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all: Quoting Stewart Bryant : > > Protocol will be STDs. > > An arch RFC does not usually need to be STDs, because it does > not usually specify anything needed for interoperability. > > Info should be STD as well, since it contains the default > set of IEs, and contains the .xml to set them up. Since it > is the document that causes IANA to set up the IE registry > it should be the place where we define the IE policy. Exactly. Protocol and Info will be Standards-track, Architecture and AS will be Ibnformational. I liked Juergen's suggestion for improving the IANA Cosiderations part of Info; that's the kind of editorial change we need to make after the WG Last Call, before we submit the drafts to IESG. Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From Phuon9812@johnhcarter.com Tue Jun 7 12:35:18 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09397 for ; Tue, 7 Jun 2005 12:35:17 -0400 (EDT) Received: from 85-124-73-91.dynamic.xdsl-line.inode.at ([85.124.73.91] helo=johnhcarter.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Dfgmc-0004Y7-00 for ipfix-list@mil.doit.wisc.edu; Tue, 07 Jun 2005 11:18:31 -0500 From: "Phuong Godwin" To: "Zahira Moulton" Subject: Re: It Worrks Great Date: Tue, 7 Jun 2005 11:18:28 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C56B7C.89AF2200" 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_003A_01C56B7C.89AF2200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Rend my vitals, but we're come from Scylla to Charybdis.have reason to ask, = said he, and sighed. I had hope' it would notIf the Spaniards = understood nothing of all this, the forlornthings even more unspeakable = seen on that dreadful evening roseOh, I understand, laughed Blood. But, = I ask myself, do you?led to it.done - that they were coming into some = wild, savage country, theI pray you do, and in God's name be brief, man. = For if I am to bethe buccaneer found himself, his lordship was disposed = to take hison me with some damage to my ship and loss of life to five of = mySoon the shrewd Wolverstone discovered that rum was not what ailedM. = de Rivarol's hawk-face flamed scarlet. His dark eyes bulged.their = wounds.he announced, with that object.womankind is more or less of a = stagnation. Miss Arabella BishopI am glad to have your admission of = that without any of the ------=_NextPart_000_003A_01C56B7C.89AF2200 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Sir/Madam.

We are pleased to introduce ourselves as one of the = leading online pharmaceutical shoOn the = 15th September of the year 1688 - a memorable year in = theps.

Save over 60 PerBlood may have made reluctant - loudly approved him. When they = hadcent On Meds today with PharmaMsuddenly been rent that = morning, she was permitted at last to seeaiI = Shop

insistent.VI		RIn the calmest season of the year, the surf will hinder any = suchA		he began to find the catechism intriguing.AL		LLord Jeffreys, whose terrible fame had come ahead of him = fromI
Ainspiration Was in his glance.G	CProvidence to Trinidad.I	IAnd = meanwhile in the Caribbean, the Spanish Admiral Don Miguel = deS VAye. Cahusac was = Levasseur's lieutenant, until he died.A	UOf = course. The Spaniard rubbed his hands, and Mr. Blood = observedM	S and many other.

With each puIt was = not until two months later - on the 19th of September, ifrchase = you get:

Top quaIitleast of the = defiance aroused in him by a blow which he dared not,y

Best Prichis = frenzy.es

Total confidentthat = fact will save the waste of a deal of words.iaIity

Home Tortuga during = those two days before Wolverstone's arrival. = ButdeIivery

Have a nice day.

------=_NextPart_000_003A_01C56B7C.89AF2200-- From majordomo@mil.doit.wisc.edu Tue Jun 7 17:56:59 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17169 for ; Tue, 7 Jun 2005 17:56:59 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dfltg-0003hs-00 for ipfix-list@mil.doit.wisc.edu; Tue, 07 Jun 2005 16:46: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 1Dflte-0003hn-00 for ipfix-info@net.doit.wisc.edu; Tue, 07 Jun 2005 16:46: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 j57Ljo500286 for ; Tue, 7 Jun 2005 23:45:55 +0200 (CEST) Received: from [10.61.65.182] (ams-clip-vpn-dhcp438.cisco.com [10.61.65.182]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j57LjhF12535 for ; Tue, 7 Jun 2005 23:45:49 +0200 (CEST) Message-ID: <42A61588.1090705@cisco.com> Date: Tue, 07 Jun 2005 23:45:44 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-info@net.doit.wisc.edu Subject: [ipfix-info] simple editorial changes for the information model draft Content-Type: multipart/alternative; boundary="------------080700000805090604080800" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------080700000805090604080800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Juergen, I reviewed the information model draft one last time. For everybody interest, we discussed with Juergen a list of new I.E. to be added. However, as we wanted to make the date of June 1st for the last-call, and as these new I.E. can be considered as editorial changes, these new I.E.s were not inserted in the current draft version. These I.E. will be the subject of a separate email. Here is a list of simple editorial changes. - http://ietf.levkowetz.com/drafts/ipfix/info/draft-ietf-ipfix-info-07.nits.txt - Section 4, Information Element Identifiers "Enterprise-specific identifiers can be chosen by an enterprise arbitrarily within the range of 1-32767. The same identifier may be assigned by other enterprises for different purposes." -> "Enterprise-specific Information Elements identifiers can be chosen by an enterprise arbitrarily within the range of 1-32767. The same identifier may be assigned by other enterprises for different purposes." - Section 4, Information Element Identifiers "The following list gives an overview of the Information Element identifiers that are specified in section 5 and are not compatible with field types used by NetFlow version 9 [RFC3954]" -> "The following list gives an overview of the Information Element identifiers that are specified in section 5 and are compatible with Information Elements used by NetFlow version 9 [RFC3954]" - Section 5. Information Elements "The Information Elements that are derived from fields of packets or from packet treatment, such as the Information Elements in groups 3.-6., can serve as Flow Keys used for mapping packets to flows. But they also may contain values that are not constant for a single flow. For example a flow using a certain source IPv4 address as flow key has sourceIPv4Address as constant property but may have destinationIPv4Address as a property that changes from packet to packet." I don't understand the sentence starting with "But". Either this is a flow key, and then this I.E. is constant in a flow. Or it's not a flow key and it's not worth mentioning! I mean... by definition a flow is defined by his flow keys. So the following sentence is wrong "But they (I understand by "they", the I.E.s that serve as Flow Keys" also may contain values that are not constant for a single flow." - Section 5. Information Elements For such Information Elements that are derived from fields of packets or from packet treatment, the IPFIX information model makes the general assumption that their value is determined by the first packet observed for the corresponding Flow, unless the description of the Information Element explicitly specifies a different semantics. semantics -> semantic - Section 5.2.5 exportedFlowTotalCount Description: The total number of Flows Records reported that the Exporting Process successfully sent as Data Records since the Exporting Process (re-)initialization to the Collecting Process receiving a report that contains this Information Element. What does "reported" mean? Can't we simply delete it? - Section 5.2.6 observedFlowTotalCount Description: The total number of Flows observed in the Observation Domain since the Metering Process (re-)initialization for this Observation Point. ElementId: 3 We should be in line with the RFC 3954 that explains something different: Number of Flows that were aggregated; - Section 5.7 Min/Max Flow Properties Information Elements in this section are results of minimum or maximum operations over all packets of a flow. TCP flags and ipv6OptionHeaders don't fall into this description. New proposal: "Information Elements in this section are results of minimum or maximum operations over all packets of a flow.Information Elements in this section are the results of minimum, a maximum, or a logical operations over all packets of a flow." - 5.7.5 ipv6OptionHeaders New proposal: Description: IPv6 extension headers observed in packets of this flow. The information is encoded in a set of bit fields. For each IPv6 option header there is a bit in this set. The bit is set to 1 if any observed packet of this flow contains the corresponding IPv6 extension header. Otherwise, if no observed packet of this flow contained the resepective IPv6 extension header, the value of the corresponding bit is 0. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Res | FRA1| ROU | FRA0| UNK | Res | HOP | DST | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 8 9 10 11 12 13 14 15 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | PAY | AUT | ENC | Reserved | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 16 17 18 19 20 21 22 23 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | Reserved | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 24 25 26 27 28 29 30 31 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | Reserved | +-----+-----+-----+-----+-----+-----+-----+-----+ Bit IPv6 Option Description 0, Res Reserved 1, FRA1 44 Fragmentation header - not first fragment 2, ROU 43 Routing header 3, FRA0 44 Fragment header - first fragment 4, UNK Unknown Layer 4 header (compressed, encrypted, not supported) 5, Res Reserved 6, HOP 0 Hop-by-hop option header 7, DST 60 Destination option header 8, PAY 108 Payload compression header 9, AUT 51 Authentication Header 10, ENC 50 Encrypted security payload 11 to 31 Reserved - Capitalization A lot of instances where "IPFIX message" is not capitalized. A couple of instances where "IPFIX device" is not capitalized "flow" sometimes is in lower case, should be "Flow" - Section 5.10.3 flowEndReason Description: The reason for flow termination. The range of values includes Abstract Data Type: octet Data Type Semantics: identifier ElementId: 136 Status: current The description is incomplete. The person who requested it should complete the description - Section 6. Extending the Information Model Extension is done by defining new Information Elements. Each new information item MUST be assigned a unique Information Element identifier as part of its definition. -> Extension is done by defining new Information Elements. Each new Information Element MUST be assigned a unique Information Element identifier as part of its definition. Regards, Benoit. --------------080700000805090604080800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Juergen,

I reviewed the information model draft one last time.

For everybody interest, we discussed with Juergen a list of new I.E. to be added.
However, as we wanted to make the date of June 1st for the last-call, and as these new I.E. can be considered as editorial changes, these new I.E.s were not inserted in the current draft version.
These I.E. will be the subject of a separate email.

Here is a list of simple editorial changes.

- http://ietf.levkowetz.com/drafts/ipfix/info/draft-ietf-ipfix-info-07.nits.txt

- Section 4, Information Element Identifiers

"Enterprise-specific identifiers can be chosen by an enterprise
arbitrarily within the range of 1-32767. The same identifier may be
assigned by other enterprises for different purposes."

->
"Enterprise-specific Information Elements identifiers can be chosen by an enterprise
arbitrarily within the range of 1-32767. The same identifier may be
assigned by other enterprises for different purposes."

- Section 4, Information Element Identifiers

"The following list gives an overview of the Information Element
identifiers that are specified in section 5 and are not compatible
with field types used by NetFlow version 9 [RFC3954]"

->
"The following list gives an overview of the Information Element
identifiers that are specified in section 5 and are compatible
with Information Elements used by NetFlow version 9 [RFC3954]"

- Section 5. Information Elements

"The Information Elements that are derived from fields of packets or
from packet treatment, such as the Information Elements in groups
3.-6., can serve as Flow Keys used for mapping packets to flows. But
they also may contain values that are not constant for a single flow.
For example a flow using a certain source IPv4 address as flow key
has sourceIPv4Address as constant property but may have
destinationIPv4Address as a property that changes from packet to
packet."

I don't understand the sentence starting with "But".
Either this is a flow key, and then this I.E. is constant in a flow.
Or it's not a flow key and it's not worth mentioning!
I mean... by definition a flow is defined by his flow keys. So the following sentence is wrong
"But they (I understand by "they", the I.E.s that serve as Flow Keys" also may contain values that are not constant for a single flow."

- Section 5. Information Elements

For such Information Elements that are derived from fields of packets
or from packet treatment, the IPFIX information model makes the
general assumption that their value is determined by the first packet
observed for the corresponding Flow, unless the description of the
Information Element explicitly specifies a different semantics.

semantics -> semantic

- Section 5.2.5 exportedFlowTotalCount

Description:
The total number of Flows Records reported that the Exporting
Process successfully sent as Data Records since the Exporting
Process (re-)initialization to the Collecting Process receiving a
report that contains this Information Element.

What does "reported" mean? Can't we simply delete it?

- Section 5.2.6 observedFlowTotalCount

Description:
The total number of Flows observed in the Observation Domain since
the Metering Process (re-)initialization for this Observation
Point.
ElementId: 3

We should be in line with the RFC 3954 that explains something different: Number of Flows that were aggregated;

- Section 5.7 Min/Max Flow Properties

Information Elements in this section are results of minimum or
maximum operations over all packets of a flow.

TCP flags and ipv6OptionHeaders don't fall into this description.
New proposal:

"Information Elements in this section are results of minimum or maximum operations over all packets of a flow.Information Elements in this section are the results of minimum, a maximum, or a logical operations over all packets of a flow."

- 5.7.5  ipv6OptionHeaders

 New proposal:

Description:
     IPv6 extension headers observed in packets of this flow. The
     information is encoded in a set of bit fields. For each IPv6
     option header there is a bit in this set. The bit is set to 1 if
     any observed packet of this flow contains the corresponding IPv6
     extension header. Otherwise, if no observed packet of this flow
     contained the resepective IPv6 extension header, the value of the
     corresponding bit is 0.

              0     1     2     3     4     5     6     7
          +-----+-----+-----+-----+-----+-----+-----+-----+
          | Res | FRA1| ROU | FRA0| UNK | Res | HOP | DST | ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

              8     9    10    11    12    13    14    15
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... | PAY | AUT | ENC |         Reserved            | ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             16    17    18    19    20    21    22    23
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |                  Reserved                     | ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             24    25    26    27    28    29    30    31
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |                  Reserved                     |
          +-----+-----+-----+-----+-----+-----+-----+-----+

      Bit     IPv6 Option   Description

       0, Res               Reserved
       1, FRA1     44       Fragmentation header - not first fragment
       2, ROU      43       Routing header
       3, FRA0     44       Fragment header - first fragment
       4, UNK               Unknown Layer 4 header
                           (compressed, encrypted, not supported)
       5, Res               Reserved
       6, HOP       0       Hop-by-hop option header
       7, DST      60       Destination option header
       8, PAY     108       Payload compression header
       9, AUT      51       Authentication Header
      10, ENC     50        Encrypted security payload
      11 to 31              Reserved

- Capitalization
    A lot of instances where "IPFIX message" is not capitalized.
    A couple of instances where "IPFIX device" is not capitalized
    "flow" sometimes is in lower case, should be "Flow"

- Section 5.10.3 flowEndReason

   Description:
      The reason for flow termination.  The range of values includes
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 136
   Status: current

The description is incomplete. The person who requested it should complete the description

- Section 6.  Extending the Information Model

   Extension is done by defining new Information Elements.  Each new
   information item MUST be assigned a unique Information Element
   identifier as part of its definition.

   Extension is done by defining new Information Elements.  Each new
   Information Element MUST be assigned a unique Information Element
   identifier as part of its definition.

Regards, Benoit.
--------------080700000805090604080800-- -- 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 Jun 7 18:02:16 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17739 for ; Tue, 7 Jun 2005 18:02:16 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dfm1J-00040B-00 for ipfix-list@mil.doit.wisc.edu; Tue, 07 Jun 2005 16:54:01 -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 1Dfm1H-0003zz-00 for ipfix-info@net.doit.wisc.edu; Tue, 07 Jun 2005 16:53:59 -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 j57LrwR00707 for ; Tue, 7 Jun 2005 23:53:58 +0200 (CEST) Received: from [10.61.65.182] (ams-clip-vpn-dhcp438.cisco.com [10.61.65.182]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j57LrvF17480 for ; Tue, 7 Jun 2005 23:53:57 +0200 (CEST) Message-ID: <42A61775.4040000@cisco.com> Date: Tue, 07 Jun 2005 23:53:57 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-info@net.doit.wisc.edu Subject: [ipfix-info] IPFIX-INFO open issue 1: octet count including layer 2 payload 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, The last-call finishes on June 15th, so it's time to get a consensus regarding this open issue described in the latest section of [IPFIX-INFO] octet count including MPLS header: Does the octet count concern IP packets only or also sub-IP layers such as MPLS? This is a follow up on the thread http://ipfix.doit.wisc.edu/archive/2783.html The two important questions are: 1. do we agree that we need a single series of counters? (see http://ipfix.doit.wisc.edu/archive/2808.html) Am I right to say that this is the WG consensus? 2. If the answer is yes to the question 1, do we include the layer 2 payload in the counters? Please give your point of view. You know mine already: I think it makes sense. 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 13balthazar@01019freenet.de Wed Jun 8 11:14:17 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08197 for ; Wed, 8 Jun 2005 11:14:17 -0400 (EDT) Received: from smtp.doit.wisc.edu ([144.92.9.43]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dg1vX-000293-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 Jun 2005 09:53:07 -0500 Received: from 221.126.242.116 ([221.126.242.116]) by smtp.doit.wisc.edu (8.13.3/8.12.6) with SMTP id j58Eqqvm091986 for ; Wed, 8 Jun 2005 09:53:04 -0500 Message-ID: From: "Vanessa J. Smith" <13balthazar@01019freenet.de> To: ipfix-list@mil.doit.wisc.edu Subject: =?iso-8859-1?B?V2luZG93cyBYUCAtIHZlcnkgbG93IHByaWNl?= Date: Wed, 08 Jun 2005 14:36:09 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_0D440954.59553AED" 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_0D440954.59553AED Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_9D1E461D.9F719AB4" ------=_NextPart_001_0001_9D1E461D.9F719AB4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Get all the software possible for unbelievably low prices! Our software is 2-10 times cheaper than sold by our competitors. Just 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 $69.95 MS Visio 2003 Professional 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 lots more... Enter here: http://www.officesoft.biz Regards, Vanessa Smith _____________________________________________________ To stop further mailings, go here: http://www.officesoft.biz/uns.htm _____________________________________________________ ------=_NextPart_001_0001_9D1E461D.9F719AB4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Get all the software possible for unbelievably low prices!
Our software is 2-10 times cheaper than sold by our competitors.

Just 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
$69.95 MS Visio 2003 Professional

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 lots more... Enter here:

http://www.officesoft.biz

Regards,
Vanessa Smith

_____________________________________________________
To stop further mailings, go here: http://www.officesoft.biz/uns.htm
_____________________________________________________

------=_NextPart_001_0001_9D1E461D.9F719AB4-- ------=_NextPart_000_0000_0D440954.59553AED-- From Mari@gcsnet.com Wed Jun 8 15:10:31 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27572 for ; Wed, 8 Jun 2005 15:10:31 -0400 (EDT) Received: from cm-85-152-201-8.telecable.es ([85.152.201.8] helo=gcsnet.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Dg5qW-00000w-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 Jun 2005 14:04:12 -0500 From: "Marian Conklin" To: "Mahalia Rosario" Subject: Re: do you need it? Date: Wed, 8 Jun 2005 14:04:08 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C56C5C.D8CC8400" 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?85.152.201.8 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C56C5C.D8CC8400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, their starboard beam they saw the spray flung up by the shot, whichwas. = His coat was of fine camlet, and it was laced with silver;There were, = when the purple gloom of the tropical night descendedhave a mutiny = aboard, and I'll lead it myself sooner than surrenderthan the torments = Nature would here procure a man in Pitt's condition.those names. He = would cast out the maudlin ideals by which he hadAnd another Frenchman = named Levasseur?If you please, Don Miguel, but that is the very thing = you must notput off in a boat.Ah, now, can't ye, indeed? he cried. = Sure, then, I'll bethat was the Governor's office, when Major Mallard = brought him wordwith pallor, to see the truth or falsehood of his guess = reflectedColonel Bishop staggered in, and stood waiting.You'll think = better of it now that ye understand? quoth Blood.felt by the buccaneers. = But do what he might, the one buccaneeras the dog in the fable that had = dropped the substance to snatch ------=_NextPart_000_001F_01C56C5C.D8CC8400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Sir/Madam.

We are pleased to introduce ourselves as one of the = leading online pharmacelengthened his = stride.utical shops.

Save over your calling in the town of Bridgewater, to be with the army of = the60 Percent On Meds today with PharmaMaiI Sin to the harbour = mouth, within saker shot of Rivarol's threehop

raised bloodshot eyes to consider him. A moment they sharpened = inVI		Under the compulsion of that sharp tone, those resolute eyes, = andRA		Aone who could be brave enough ashore. Fortunately Miss Bishop = didL		It is not, my lord. I had counted upon going home, so I = had.LI
Blood = shouted an order to the bo'sun, who was leaning against = theAG	have made the impression that he hoped to make. It may even = haveCI	your life = risked by keeping you aboard whilst the message goes = byIS Hence, fortuitously, had = they been chained together in the crowdedVA	Uthe = Spaniards by surprise and attempt to overpower them before = theyM	S and many other.

With each I'll take = that liberty.purchase you get:

Top quaIitCommandant, = was slowly pacing. He stopped short at sight of Captainy

Best city. She was = attended by two negroes who trotted after her at aPrices

Total confidentiaIThe = planter waved the matter aside. Almost it seemed to offend = him.ity

Home deIivmade its = impression upon these poor pusillanimous sheep. But = theery

Have a nice day.

------=_NextPart_000_001F_01C56C5C.D8CC8400-- From Maral@jrphillips.com Thu Jun 9 14:29:42 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01646 for ; Thu, 9 Jun 2005 14:29:42 -0400 (EDT) Received: from [202.63.106.140] (helo=jrphillips.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DgRTa-0007fP-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Jun 2005 13:09:59 -0500 From: "Maral Green" To: "Nalani Collazo" Subject: 25 mg Workss Wonders Date: Thu, 9 Jun 2005 13:09:53 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01C56D1E.6F14AE80" 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_003D_01C56D1E.6F14AE80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, heel, he went aside to the rail. As he stood there deep in thought,doubt, = and it doesn't help us to solve the riddle that's before us.grew on two = sides of it, and the still, evening air was heavyThe Admiral's face = flamed scarlet. He half raised his hand to strike.reeled into the cloud = of smoke that concealed her prey, and thenWhy? asked Peter Blood at = point-blank range.Blood should afterwards contrive to get away unscathed = - and fromsatisfactorily. So far, indeed, was he recovered that he = complainedwould you do, yourself?Blood, if you please, of this ship the = Cinco Llagas, taken as afame of his that had spread so quickly across = the Caribbean wouldHis lips were twisted into a wry smile, and there was = pain in theof English seamen as battered and broken as the ship herself, = andI'll go as far as twenty pounds. Not a penny more, and it's = twiceanother who might bungle it. And now perhaps ye'll = understand.Moreover, there was no conceivable reason why he should not. = And ------=_NextPart_000_003D_01C56D1E.6F14AE80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Sir/Madam.

We are pleased to introduce ourselves as one of the = lead lickspittle ing online = pharmaceuti arbutus cal = shops.

Save = therewithal over 75 Percent On Meds today with Ph compel armaMaiI = Shop

V acceptable l		consulate RA		bombardon AL		L licence l
A = cornicle G	= couloir Cl	I = confederacy S sedative = VA	disunity = UM	S and many other.

With each purch = undersecretary ase you get:

Top quaIit ponceau = y

Best patellae = Prices

Total unbalanced = confidentiaIity

Home deIi passout = very

Have a nice day.

------=_NextPart_000_003D_01C56D1E.6F14AE80-- From Emmo@khimairafarm.com Fri Jun 10 17:56:10 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16611 for ; Fri, 10 Jun 2005 17:56:09 -0400 (EDT) Received: from 201-1-89-209.dsl.telesp.net.br ([201.1.89.209] helo=khimairafarm.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DgrBU-0003fw-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Jun 2005 16:37:00 -0500 From: "Victoire Emmons" To: "Kortney Bray" Subject: Really Works Very Goodd Date: Fri, 10 Jun 2005 16:36:53 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C56E04.84640880" 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_0000_01C56E04.84640880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, not have you do anything mean or dishonouring.to him on the other side. = Don't be a fool, Captain. Do you wantCaptain Blood thrust a parchment = under Calverley's bulging eyes.to his feet. No, no. If Captain = Levasseur is meanwhile to keepship, the Cinco Llagas, so that his vague = disquiet must be, surely,dreamt of the pain he carried in his breast. = It's the second timeupon the plank. Three steps he took before he lost = his balance andperemptory summons, he said, and passed the note to his = friend.And he has seen much foreign service on sea and land. Cahusac = saidNor was he likely, on account of it, to allow himself to run to = rustSternly disapproving eyes considered him from a window opposite,of = which you are an ornament as a free man with pleasure and = profitquarter-deck of the conquered vessel, looked his last upon theIt's = not money I'll require, said he, but the boat itself. Forrepresenting = twelve thousand pieces of eight, which is La Foudre'seach, to which = their scanty remaining belongings and Miss Bishop's ------=_NextPart_000_0000_01C56E04.84640880 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Sir/Madam.

We are plea mothball = sed to introduce ourselves as one of the leading online = pharmaceutic sublessee al = shops.

Save over = malinger 75 Percent On Meds today with MedzMail Sho parcener = p

oriole VlA		teetotum RA		parching lAL		l criticaster U
rotative = G	= kingship C	= portraitist IS protectory = VAL	dowdyish = M	S and many other.

With each purcha = cosmology se you get:

Top quaI atticism = ity

Best Price priestly = s

Total c important = onfidentiaIity

Home de colophon = Iivery

Have a nice day.

------=_NextPart_000_0000_01C56E04.84640880-- From majordomo@mil.doit.wisc.edu Fri Jun 10 20:04:53 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26473 for ; Fri, 10 Jun 2005 20:04:53 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DgtPb-0006om-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Jun 2005 18:59:43 -0500 Received: from sjdmz.clarify.com ([67.117.82.39] helo=sjdmz.amdocs.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DgtPa-0006oh-00 for ipfix-as@net.doit.wisc.edu; Fri, 10 Jun 2005 18:59:42 -0500 Received: from sjint.amdocs.com (sjint1.amdocs.com [67.117.82.3]) by sjdmz.amdocs.com (8.12.9/8.12.9) with ESMTP id j5B0IfaV025835; Fri, 10 Jun 2005 17:18:41 -0700 Received: from sjcmail2.corp.amdocs.com (localhost [127.0.0.1]) by sjint.amdocs.com (8.13.1/8.13.1) with ESMTP id j5ANxTuX016070; Fri, 10 Jun 2005 16:59:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipfix-as] new version of IPFIX-AS draft Date: Fri, 10 Jun 2005 16:59:55 -0700 Message-ID: Thread-Topic: [ipfix-as] new version of IPFIX-AS draft Thread-Index: AcVl9/0ZZp2dojfMQjWDWqWJRsH9pAIG5alw From: "Tal Givoly" To: "Tanja Zseby" Cc: "Nevil Brownlee" , "Dave Plonka" , Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Tanja, =0D The text here is not explicit enough as it relates to accounting. Rather than being clear about the level of accounting that is achievable with IPFIX (as I've suggested in a previous submission - see below), it creates a reference to the whole requirement document for potential applicability.=0D =0D Here's the text of the e-mail I sent Nevil (and for some reason didn't hit the mailing list until resent by Nevil) on Feb 24, 2005: > Nevil, > > I believe to the fact that the applicability statement doesn't=0D > document any caveats regarding the use of IPFIX for billing or accounting. > Despite the fact that IPFIX provides a flexible way to encode a=0D > variety of record structures for a variety of services, it couldn't be > used for VoIP, telephony calls, e-commerce transactions or ATM=0D > transactions, for that matter. One might ask oneself why is this the=0D > case? Because the reliability is not at the degree of reliability=0D > currently offered by RADIUS, DIAMETER, AMATPS/AMADNS, GTP', IPDR=0D > Streaming Protocol, and other protocols. >=0D > I believe this needs to be clearly denoted and perhaps the=0D > applicability statement is where it might be worth mentioning this. >=0D > This was addressed in the requirement document by including in section > 3 the statement: >=0D > The reliability requirements defined in sections 5.1 and 6.3.2. are=0D > not > sufficient to guarantee the level of reliability that is needed for > many usage-based accounting systems. Particular reliability > requirements for accounting systems are discussed in [RFC2975]. >=0D > Perhaps this needs to be echoed in a similar fashion in section 2.1 of > the applicability statement? >=0D > Tal Thanks, Tal ________________________________ From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tanja Zseby Sent: Tuesday, May 31, 2005 8:01 AM To: ipfix-as@net.doit.wisc.edu Subject: [ipfix-as] new version of IPFIX-AS draft Dear all, I submitted a new version of the IPFIX applicability statement draft-ietf-ipfix-as-05.txt. Main chnages are the improvement of the accounting example something more on further opportunities to use IPFIX, some more limitations and some restructuring. Please send me your comments, especially if you see further opportunities what to do with ipfix or further limitations (not sure that I remember all comments from the last meeting). Regards Tanja --=0D Dipl.-Ing. Tanja Zseby =0D Fraunhofer Institute FOKUS Email: zseby@fokus.fraunhofer.de=0D Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 ------------------------------------------------------------------------ --------------=0D "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) ------------------------------------------------------------------------ -------------- The information contained in this message is proprietary of Amdocs, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated= recipient(s) of the message. If the reader of this message is not the intended= recipient, you are hereby notified that any dissemination, use, distribution or= copying of=0D this communication is strictly prohibited and may be unlawful.=0D If you have received this communication in error, please notify us= immediately by replying to the message and deleting it from your computer. Thank you. -- 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 Sat Jun 11 09:53:52 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10766 for ; Sat, 11 Jun 2005 09:53:51 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dh68t-0002q8-00 for ipfix-list@mil.doit.wisc.edu; Sat, 11 Jun 2005 08:35:19 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dh68s-0002q3-00 for ipfix-info@net.doit.wisc.edu; Sat, 11 Jun 2005 08:35:18 -0500 Received: from [192.168.0.112] (HSI-KBW-082-212-044-212.hsi.kabelbw.de [82.212.44.212]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 5C2E01BAC9E; Sat, 11 Jun 2005 15:35:15 +0200 (CEST) Date: Sat, 11 Jun 2005 15:34:21 +0200 From: Juergen Quittek To: Benoit Claise , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] simple editorial changes for the information model draft 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 Benoit, Thanks for the comments. Please see replies in line. --On 6/7/2005 11:45 PM +0200 Benoit Claise wrote: > Juergen, > > > I reviewed the information model draft one last time. > > For everybody interest, we discussed with Juergen a list of new I.E. > to be added. > However, as we wanted to make the date of June 1st for the last-call, > and as these new I.E. can be considered as editorial changes, these new > I.E.s were not inserted in the current draft version. > These I.E. will be the subject of a separate email. > > > Here is a list of simple editorial changes. > - http://ietf.levkowetz.com/drafts/ipfix/info/draft-ietf-ipfix-info-07.nits.txt Fixed. > - Section 4, Information Element Identifiers > "Enterprise-specific identifiers can be chosen by an enterprise > arbitrarily within the range of 1-32767. The same identifier may be > assigned by other enterprises for different purposes." > > -> > "Enterprise-specific Information Elements identifiers can be chosen > by an enterprise arbitrarily within the range of 1-32767. The same > identifier may be assigned by other enterprises for different purposes." Fixed (removed the trailing 's' from "Elements"). > - Section 4, Information Element Identifiers > > "The following list gives an overview of the Information Element > identifiers that are specified in section 5 and are not compatible > with field types used by NetFlow version 9 [RFC3954]" > > -> > "The following list gives an overview of the Information Element > identifiers that are specified in section 5 and are compatible > with Information Elements used by NetFlow version 9 [RFC3954]" Fixed. > - Section 5. Information Elements > > "The Information Elements that are derived from fields of packets or > from packet treatment, such as the Information Elements in groups > 3.-6., can serve as Flow Keys used for mapping packets to flows. But > they also may contain values that are not constant for a single flow. > For example a flow using a certain source IPv4 address as flow key > has sourceIPv4Address as constant property but may have > destinationIPv4Address as a property that changes from packet to > packet." > > I don't understand the sentence starting with "But". > Either this is a flow key, and then this I.E. is constant in a flow. > Or it's not a flow key and it's not worth mentioning! > I mean... by definition a flow is defined by his flow keys. > So the following sentence is wrong > "But they (I understand by "they", the I.E.s that serve as Flow Keys" > also may contain values that are not constant for a single flow." This is a lost editorial edit. I fixed this already, but here we have the old version. I'll post the improved version to the list when I am back in the office and can retrieve it from the CVS server. > - Section 5. Information Elements > > For such Information Elements that are derived from fields of packets > or from packet treatment, the IPFIX information model makes the > general assumption that their value is determined by the first packet > observed for the corresponding Flow, unless the description of the > Information Element explicitly specifies a different semantics. > > semantics -> semantic No, 'semantics' is correct. Strange English language: 'semantic' is an attribute, 'semantics' is the singular form of the corresponding noun. > - Section 5.2.5 exportedFlowTotalCount > > Description: > The total number of Flows Records reported that the Exporting > Process successfully sent as Data Records since the Exporting > Process (re-)initialization to the Collecting Process receiving a > report that contains this Information Element. > > What does "reported" mean? Can't we simply delete it? Yes. Done. > - Section 5.2.6 observedFlowTotalCount > > Description: > The total number of Flows observed in the Observation Domain since > the Metering Process (re-)initialization for this Observation > Point. > ElementId: 3 > > We should be in line with the RFC 3954 that explains something > different: Number of Flows that were aggregated; Fine to be in line. But what means RFC 3954 with "Flows that were aggregated"? The common definition of flow aggregation is merging individual flow records of different flows into a single one. This is in line with the last paragraph on page 4 of RFC 3954. But this is not what I understood so far as the semantics of Information Element #3 "observedFlowTotalCount". > - Section 5.7 Min/Max Flow Properties > > Information Elements in this section are results of minimum or > maximum operations over all packets of a flow. > > TCP flags and ipv6OptionHeaders don't fall into this description. > New proposal: > > "Information Elements in this section are results of minimum or > maximum operations over all packets of a flow.Information Elements > in this section are the results of minimum, a maximum, or a logical > operations over all packets of a flow." The logical operation you are referring to is the bit-wise maximum operation. > - 5.7.5 ipv6OptionHeaders > > New proposal: > Description: > IPv6 extension headers observed in packets of this flow. The > information is encoded in a set of bit fields. For each IPv6 > option header there is a bit in this set. The bit is set to 1 if > any observed packet of this flow contains the corresponding IPv6 > extension header. Otherwise, if no observed packet of this flow > contained the resepective IPv6 extension header, the value of the > corresponding bit is 0. > > 0 1 2 3 4 5 6 7 > +-----+-----+-----+-----+-----+-----+-----+-----+ > | Res | FRA1| ROU | FRA0| UNK | Res | HOP | DST | ... > +-----+-----+-----+-----+-----+-----+-----+-----+ > > 8 9 10 11 12 13 14 15 > +-----+-----+-----+-----+-----+-----+-----+-----+ > ... | PAY | AUT | ENC | Reserved | ... > +-----+-----+-----+-----+-----+-----+-----+-----+ > > 16 17 18 19 20 21 22 23 > +-----+-----+-----+-----+-----+-----+-----+-----+ > ... | Reserved | ... > +-----+-----+-----+-----+-----+-----+-----+-----+ > > 24 25 26 27 28 29 30 31 > +-----+-----+-----+-----+-----+-----+-----+-----+ > ... | Reserved | > +-----+-----+-----+-----+-----+-----+-----+-----+ > > Bit IPv6 Option Description > > 0, Res Reserved > 1, FRA1 44 Fragmentation header - not first fragment > 2, ROU 43 Routing header > 3, FRA0 44 Fragment header - first fragment > 4, UNK Unknown Layer 4 header > (compressed, encrypted, not supported) > 5, Res Reserved > 6, HOP 0 Hop-by-hop option header > 7, DST 60 Destination option header > 8, PAY 108 Payload compression header > 9, AUT 51 Authentication Header > 10, ENC 50 Encrypted security payload > 11 to 31 Reserved Done. I hope you don't mind that I capitalized all occurrences of the term 'flow' in your proposal :-) > - Capitalization > A lot of instances where "IPFIX message" is not capitalized. > A couple of instances where "IPFIX device" is not capitalized > "flow" sometimes is in lower case, should be "Flow" Done. > - Section 5.10.3 flowEndReason > > Description: > The reason for flow termination. The range of values includes > Abstract Data Type: octet > Data Type Semantics: identifier > ElementId: 136 > Status: current > The description is incomplete. The person who requested it should > complete the description This was my fault. I used the wrong XML tag and the list of reasons disappeared. It is 0x01: idle timeout 0x02: active timeout 0x03: end of Flow detected (e.g. TCP FIN) 0x04: forced end 0x05: cache full > - Section 6. Extending the Information Model > > Extension is done by defining new Information Elements. Each new > information item MUST be assigned a unique Information Element > identifier as part of its definition. > -> > > Extension is done by defining new Information Elements. Each new > Information Element MUST be assigned a unique Information Element > identifier as part of its definition. Fixed. > 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 Sat Jun 11 18:29:46 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21221 for ; Sat, 11 Jun 2005 18:29:46 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DhEJz-0007fs-00 for ipfix-list@mil.doit.wisc.edu; Sat, 11 Jun 2005 17:19:19 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DhEJx-0007fk-00 for ipfix-info@net.doit.wisc.edu; Sat, 11 Jun 2005 17:19:17 -0500 Received: from [192.168.0.112] (HSI-KBW-082-212-044-212.hsi.kabelbw.de [82.212.44.212]) by kyoto.netlab.nec.de (Postfix) with ESMTP id C68CD1BAC4D; Sun, 12 Jun 2005 00:19:15 +0200 (CEST) Date: Sun, 12 Jun 2005 00:18:46 +0200 From: Juergen Quittek To: Benoit Claise , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] IPFIX-INFO open issue 1: octet count including layer 2 payload Message-ID: <00F2C05170EB74DED0CAB081@753F3B888A9969457862729D> In-Reply-To: <42A61775.4040000@cisco.com> References: <42A61775.4040000@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 Dear all, RFC 3031 (MPLS Architecture) defines the following terminology: > layer 3 the protocol layer at which IP and its > associated routing protocols operate > layer 2 the protocol layer under layer 3 (which > therefore offers the services used by > layer 3). Forwarding, when done by the > swapping of short fixed length labels, > occurs at layer 2 regardless of whether > the label being examined is an ATM > VPI/VCI, a frame relay DLCI, or an MPLS > label. I clearly vote for including layer 3 octets only in our basic IPFIX octet counters. This means counting IP packets only and not any layer two headers, frames, etc. The alternative suggestion we are discussing would include some layer 2 technologies in the octet counters (MPLS, ISL, dot1q) and would exclude others (Ethernet, ...). This is conceptually complicated and we would have to maintain lists of included and excluded layer 2 technologies. Anyone who would interpret measured values would need to check carefully which layer 2 technology was used at the observation point for the particular flow, because this would have an effect on the measure numbers. Compared to this, just including IP in the octet count is a very clean solution for the counters #1 octetDeltaCount, #85 octetTotalCount, #23 postOctetDeltaCount, #160 postOctetTotalCount, #132 droppedOctetDeltaCount, #134 droppedOctetTotalCount, and #20 postMulticastOctetCount. Juergen --On 6/7/2005 11:53 PM +0200 Benoit Claise wrote: > Dear all, > > The last-call finishes on June 15th, so it's time to get a consensus regarding this open issue described in the latest section of [IPFIX-INFO] > > octet count including MPLS header: Does the octet count concern IP > packets only or also sub-IP layers such as MPLS? > > This is a follow up on the thread http://ipfix.doit.wisc.edu/archive/2783.html > > The two important questions are: > 1. do we agree that we need a single series of counters? > (see http://ipfix.doit.wisc.edu/archive/2808.html) > Am I right to say that this is the WG consensus? > > 2. If the answer is yes to the question 1, do we include the layer 2 payload in the counters? > Please give your point of view. > You know mine already: I think it makes sense. > > 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 Chamber_4613@gb.com Sat Jun 11 23:35:47 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01781 for ; Sat, 11 Jun 2005 23:35:47 -0400 (EDT) Received: from p5492c272.dip.t-dialin.net ([84.146.194.114] helo=gb.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DhIxv-0006y4-00 for ipfix-list@mil.doit.wisc.edu; Sat, 11 Jun 2005 22:16:52 -0500 From: "Kimberlee Chamberlain" To: "Kacper Valadez" Subject: Works Wondder Date: Sat, 11 Jun 2005 22:16:50 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C56EFD.2C5CFD00" 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_0021_01C56EFD.2C5CFD00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, which as a result of the Governor's gout now overhung him.prisoners, the = slaves, and most of the captured merchandise. TheI can't find him, = bleated Nuttall. He was indignant at hishim unduly.They will be waiting = for night, suggested his nephew, who stoodcommission,' says I; 'turn = King's man and save your neck and ours.'other men of medicine in = Bridgetown.counted to his age.a compelling friendliness she held out her = hand to him.plucked from him, and he had been held up to scorn - he, the = Generallordship was not disturbed.authority.them. Came the creak of = blocks and the rattle of slatting sails asSpanish Admiral never guessed = the intent until it was too late andas you please, M. le Baron. You are = the supreme authority. It isSteed's proclamation? Ye'll have read it, = no doubt? ------=_NextPart_000_0021_01C56EFD.2C5CFD00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Sir/Madam.

We are pleased to = cevitamic introduce ourselves as one of the leading online = ph virtuoso armaceutical = shops.

Save = recriminate over 75 Percent On Meds today with hallmark MedzMail Shop

V disembark lA		R ceramics A		lethal lAL		l machicolation U
reengage = G	= jointure C	I = architrave S V aliquant = AL	Occident = M	S and many other.

With each purcha = winebowl se you get:

Top qu intricate = aIity

Best Pric sepulchre = es

Total confi nobiliary = dentiaIity

Home d annihilate = eIivery

Have a nice day.

------=_NextPart_000_0021_01C56EFD.2C5CFD00-- From majordomo@mil.doit.wisc.edu Mon Jun 13 09:51:30 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13701 for ; Mon, 13 Jun 2005 09:51:25 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dhp1o-0006mg-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Jun 2005 08:31:00 -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 1Dhp1n-0006mZ-00 for ipfix-as@net.doit.wisc.edu; Mon, 13 Jun 2005 08:30:59 -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 j5DDUwO26517 for ; Mon, 13 Jun 2005 15:30:58 +0200 (CEST) Received: from [10.21.96.18] (sjc-vpn1-18.cisco.com [10.21.96.18]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j5DDUvF14229 for ; Mon, 13 Jun 2005 15:30:57 +0200 (CEST) Message-ID: <42AD8A91.2080503@cisco.com> Date: Mon, 13 Jun 2005 15:30:57 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-as@net.doit.wisc.edu Subject: [ipfix-as] simple editorial changes for the information model draft 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, I reviewed the applicability draft one last time. Here is a list of simple editorial changes. - In the example of section 2.1.1, 8987410 value is not correct in the example. It should be 987410 - Section 2.2, missing parenthese Furthermore, security incidents can become a threat to IPFIX processes themselves (see also security considerations in [IPFIX-PROTO]. - Section 3.4 The PSAMP group defines packet selection methods and the reporting of whole packet or partial packet information. As far as I recall, PSAMP doesn't support the export of the whole packet. The major difference between IPFIX and PSAMP is that while the former addresses the export of flow records, the latter addresses the export's packet records. The latter addresses the export of packet records - In section 4 "Limitations", the choice of "Use of SCTP" and "Push Mode" appears to be the limitations. Maybe you should put the limitations. So "Use of a different transport protocol than SCTP:" and "Pull mode", respectively. Furthermore, the structure of this section is not too obvious. For example the "Push mode:" is composed of several paragraphs. For example, you have only one subsection for IPv6. Why this one? You should consider creating subsections: 4.1 Use of a different transport protocol than SCTP 4.2 Pull Mode 4.3 Template ID number 4.4 IPFIX and IPv6 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 Mon Jun 13 10:23:19 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17241 for ; Mon, 13 Jun 2005 10:23:19 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DhpaO-0000AF-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Jun 2005 09:06:45 -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 1DhpaN-0000A9-00 for ipfix-info@net.doit.wisc.edu; Mon, 13 Jun 2005 09:06:43 -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 j5DE6gn28968; Mon, 13 Jun 2005 16:06:42 +0200 (CEST) Received: from [10.21.96.18] (sjc-vpn1-18.cisco.com [10.21.96.18]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j5DE6fF21019; Mon, 13 Jun 2005 16:06:41 +0200 (CEST) Message-ID: <42AD92F1.80700@cisco.com> Date: Mon, 13 Jun 2005 16:06:41 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] simple editorial changes for the information model draft 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 Juergen, > >> - Section 5.2.6 observedFlowTotalCount >> >> Description: >> The total number of Flows observed in the Observation Domain since >> the Metering Process (re-)initialization for this Observation >> Point. >> ElementId: 3 >> >> We should be in line with the RFC 3954 that explains something >> different: Number of Flows that were aggregated; > > > Fine to be in line. But what means RFC 3954 with "Flows that were > aggregated"? > The common definition of flow aggregation is merging individual flow > records > of different flows into a single one. This is in line with the last > paragraph > on page 4 of RFC 3954. But this is not what I understood so far as the > semantics of Information Element #3 "observedFlowTotalCount". It's because the ElementId 3 name and description changed along the different versions. flowCount (version 3) -> totalFlowCount (version 6) -> observedFlowTotalCount (version 7) I guess you want: - Element Id 3 to be in line with RFC3954 - A new I.E. for observedFlowTotalCount, if you have a need for it >> - Section 5.10.3 flowEndReason >> >> Description: >> The reason for flow termination. The range of values includes >> Abstract Data Type: octet >> Data Type Semantics: identifier >> ElementId: 136 >> Status: current >> The description is incomplete. The person who requested it should >> complete the description > > > This was my fault. I used the wrong XML tag and the list of reasons > disappeared. It is > > 0x01: idle timeout > 0x02: active timeout > 0x03: end of Flow detected (e.g. TCP FIN) > 0x04: forced end > 0x05: cache full What does the force end mean? 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 Beckwith7950@gcastrategies.com Mon Jun 13 11:17:29 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21392 for ; Mon, 13 Jun 2005 11:17:29 -0400 (EDT) Received: from geoadvance.geo.net.co ([200.124.160.5] helo=gcastrategies.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DhqYl-0001si-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Jun 2005 10:09:12 -0500 Received: from 200.124.164.198 (vanevillegas@200.124.164.198 [200.124.164.198]) by geoadvance.geo.net.co (SlipStream SP Server 3.1.65 built 2004/04/01 11:29:05 -0500 (EST)); Mon, 13 Jun 2005 10:20:18 -0500 (COT) From: "Celio Beckwith" To: "Soledad Waldron" Subject: V shop Date: Mon, 13 Jun 2005 10:08:45 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C57029.CAE67C80" 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_000B_01C57029.CAE67C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, bulldog.She spoke hastily, the thought of Mademoiselle d'Ogeron in her = mind.glance a little scared, his cheeks flushing.He is coming straight = to his doom - straight to the yardarm and theBlood came sliding erect to = the beach. He was followed byIf anything should happen to you, Peter, = he said, as Blood wasit was. He was clear on the matter of the easily = successful raidall its approaches. On the side of the sea where it = looks sothe gratitude and deep-seated. She had been moved to it by = hearingMaybe it'll comfort you to know that the Captain has altered = our'em. If they thought as how you'd taken the King's commission = inthose level black brows. In their glance those eyes, flanking = agentleman.training and skill in militant seamanship clamorously = supported theMiss Arabella Bishop.took the Spaniard and turned the = tables on those dogs! Oddswounds! ------=_NextPart_000_000B_01C57029.CAE67C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Sir/Madam.

W handcuff e = are pleased to introduce ourselves as one of the leading online = pharmac selfhumiliation eutical = shops.

Save over 75 P credent ercent On Meds today with MedzMail divestiture = Shop

PalmaChristi VlA		agaric RA		lA household L		confiscation lU
= defamatory G	= greenhorn C	brazen = IS V barfly = AL	oligarch = M	S and many other.

With each pu = ultramundane rchase you get:

Top qu dribblet = aIity

Best Pric preordain = es

Total confidenti = plaything aIity

Home deIiver conceive = y

Have a nice day.

------=_NextPart_000_000B_01C57029.CAE67C80-- From majordomo@mil.doit.wisc.edu Mon Jun 13 11:33:52 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22571 for ; Mon, 13 Jun 2005 11:33:52 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dhqk3-0002KD-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Jun 2005 10:20:47 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dhqk1-0002K6-00 for ipfix-info@net.doit.wisc.edu; Mon, 13 Jun 2005 10:20:46 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 5A3A6D9E8; Mon, 13 Jun 2005 17:35:42 +0200 (CEST) Received: from [10.1.1.171] ([10.1.1.171]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jun 2005 17:21:39 +0200 Date: Mon, 13 Jun 2005 17:20:21 +0200 From: Juergen Quittek To: Benoit Claise Cc: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] simple editorial changes for the information model draft Message-ID: <4BAE46B432D86EAC62F0160D@753F3B888A9969457862729D> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 13 Jun 2005 15:21:39.0505 (UTC) FILETIME=[988A9210:01C5702B] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit, --On 6/13/2005 4:06 PM +0200 Benoit Claise wrote: > Juergen, > >> >>> - Section 5.2.6 observedFlowTotalCount >>> >>> Description: >>> The total number of Flows observed in the Observation Domain since >>> the Metering Process (re-)initialization for this Observation >>> Point. >>> ElementId: 3 >>> >>> We should be in line with the RFC 3954 that explains something >>> different: Number of Flows that were aggregated; >> >> >> Fine to be in line. But what means RFC 3954 with "Flows that were >> aggregated"? >> The common definition of flow aggregation is merging individual flow >> records >> of different flows into a single one. This is in line with the last >> paragraph >> on page 4 of RFC 3954. But this is not what I understood so far as the >> semantics of Information Element #3 "observedFlowTotalCount". > > It's because the ElementId 3 name and description changed along the different versions. > > flowCount (version 3) -> totalFlowCount (version 6) -> observedFlowTotalCount (version 7) This is not the point. My comment applies to flowCount as well as to totalFlowCount and to observedFlowTotalCount. > I guess you want: > - Element Id 3 to be in line with RFC3954 > - A new I.E. for observedFlowTotalCount, if you have a need for it Sorry, I cannot follow: What is wrong with the current description? Is it the term 'total'? Is IE #3 a delta counter? I do not like the description from RFC3954, because I think the term "aggregated" is wrong. >>> - Section 5.10.3 flowEndReason >>> >>> Description: >>> The reason for flow termination. The range of values includes >>> Abstract Data Type: octet >>> Data Type Semantics: identifier >>> ElementId: 136 >>> Status: current >>> The description is incomplete. The person who requested it should >>> complete the description >> >> >> This was my fault. I used the wrong XML tag and the list of reasons >> disappeared. It is >> >> 0x01: idle timeout >> 0x02: active timeout >> 0x03: end of Flow detected (e.g. TCP FIN) >> 0x04: forced end >> 0x05: cache full > > What does the force end mean? And end of this flow enforced by any component of the architecture and that is not covered by any of the other reasons. You can end a flow by shutting down the IP interface, by terminating the metering or exporting process, ... > 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 Mon Jun 13 12:35:59 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28322 for ; Mon, 13 Jun 2005 12:35:58 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DhrX6-0003jh-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Jun 2005 11:11:28 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DhrX5-0003jc-00 for ipfix-info@net.doit.wisc.edu; Mon, 13 Jun 2005 11:11:27 -0500 Received: from [193.175.133.240] (luz@kaitos [193.175.133.240]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j5DGAEm26870; Mon, 13 Jun 2005 18:10:14 +0200 (MEST) Message-ID: <42ADAFE6.6000409@fokus.fraunhofer.de> Date: Mon, 13 Jun 2005 18:10:14 +0200 From: Lutz Mark User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise CC: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] IPFIX-INFO open issue 1: octet count including layer 2 payload References: <42A61775.4040000@cisco.com> In-Reply-To: <42A61775.4040000@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > The two important questions are: > 1. do we agree that we need a single series of counters? > (see http://ipfix.doit.wisc.edu/archive/2808.html) > Am I right to say that this is the WG consensus? > > 2. If the answer is yes to the question 1, do we include the layer 2 > payload in the counters? > Please give your point of view. > You know mine already: I think it makes sense. I vote for only having a single series of counters and like Juergen's proposal to keep IPFIX simple via only counting layer3 bytes. The disadvantage is that one would have to use vendor specific IEs to export layer2 bytes and that different vendors have to use different IEs. What about allowing the use of the above counters also for the export of layer2+3 bytes. Per default the counters only export layer3 bytes. If an exporter wants to count also some bearer layer bytes it has to announce this via an option record. Best regards, Lutz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Jun 13 13:45:16 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03087 for ; Mon, 13 Jun 2005 13:45:16 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DhshX-0005p8-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Jun 2005 12:26:19 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DhshV-0005p1-00 for ipfix-info@net.doit.wisc.edu; Mon, 13 Jun 2005 12:26:18 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id F2A571C730; Mon, 13 Jun 2005 19:41:15 +0200 (CEST) Received: from [10.1.1.171] ([10.1.1.171]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jun 2005 19:27:12 +0200 Date: Mon, 13 Jun 2005 19:26:14 +0200 From: Juergen Quittek To: Lutz Mark , Benoit Claise Cc: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] IPFIX-INFO open issue 1: octet count including layer 2 payload Message-ID: <8EF2C38AAE5369EB02240495@[10.1.1.171]> In-Reply-To: <42ADAFE6.6000409@fokus.fraunhofer.de> References: <42A61775.4040000@cisco.com> <42ADAFE6.6000409@fokus.fraunhofer.de> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 13 Jun 2005 17:27:12.0118 (UTC) FILETIME=[22541960:01C5703D] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Lutz, --On 6/13/2005 6:10 PM +0200 Lutz Mark wrote: > >> The two important questions are: >> 1. do we agree that we need a single series of counters? >> (see http://ipfix.doit.wisc.edu/archive/2808.html) >> Am I right to say that this is the WG consensus? >> >> 2. If the answer is yes to the question 1, do we include the layer 2 >> payload in the counters? >> Please give your point of view. >> You know mine already: I think it makes sense. > > I vote for only having a single series of counters and like > Juergen's proposal to keep IPFIX simple via only counting > layer3 bytes. > > The disadvantage is that one would have to use vendor specific IEs to > export layer2 bytes and that different vendors have to use different IEs. > > What about allowing the use of the above counters also for the > export of layer2+3 bytes. Per default the counters only export > layer3 bytes. If an exporter wants to count also some bearer layer bytes > it has to announce this via an option record. For this solution we would need at least one more information element indicating layer 2 technologies that are included in the octet count. An array of bit fields may be a possibility. but it would probably not be easy to extend it to new upcoming layer 2 technologies?? Definitely, the option record you suggest must be standardized in order to be understood by every compliant collector. Thanks, Juergen > Best regards, > Lutz > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- 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 Jun 13 16:36:14 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04475 for ; Mon, 13 Jun 2005 16:36:14 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DhvX7-000392-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Jun 2005 15:27:45 -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 1DhvX5-00038v-00 for ipfix-as@net.doit.wisc.edu; Mon, 13 Jun 2005 15:27:44 -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 j5DKRht21563 for ; Mon, 13 Jun 2005 22:27:43 +0200 (CEST) Received: from [10.21.96.237] (sjc-vpn1-237.cisco.com [10.21.96.237]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j5DKReF23999; Mon, 13 Jun 2005 22:27:40 +0200 (CEST) Message-ID: <42ADEC39.4030707@cisco.com> Date: Mon, 13 Jun 2005 22:27:37 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise CC: ipfix-as@net.doit.wisc.edu Subject: Re: [ipfix-as] simple editorial changes for the information model draft -> applicability statement draft. References: <42AD8A91.2080503@cisco.com> In-Reply-To: <42AD8A91.2080503@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Obviously a mistake in the email title... This concerns the applicability statement draft. Regards, Benoit. > Dear all, > > I reviewed the applicability draft one last time. > Here is a list of simple editorial changes. > > - In the example of section 2.1.1, 8987410 value is not correct in the > example. It should be 987410 > > - Section 2.2, missing parenthese > > Furthermore, security incidents can become a threat to IPFIX > processes themselves (see also security considerations in > [IPFIX-PROTO]. > > - Section 3.4 > > The PSAMP group defines packet selection methods and the > reporting of whole packet or partial packet information. > As far as I recall, PSAMP doesn't support the export of the whole packet. > > The major difference between IPFIX and PSAMP is that while the > former addresses the export of flow records, the latter addresses > the export's packet records. > The latter addresses the export of packet records > > - In section 4 "Limitations", the choice of "Use of SCTP" and "Push > Mode" appears to be the limitations. > Maybe you should put the limitations. So "Use of a different transport > protocol than SCTP:" and "Pull mode", respectively. > Furthermore, the structure of this section is not too obvious. For > example the "Push mode:" is composed of several paragraphs. For > example, you have only one subsection for IPv6. Why this one? > You should consider creating subsections: > 4.1 Use of a different transport protocol than SCTP > 4.2 Pull Mode > 4.3 Template ID number > 4.4 IPFIX and IPv6 > 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 Mon Jun 13 16:56:21 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05680 for ; Mon, 13 Jun 2005 16:56:21 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dhvrd-0003vC-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Jun 2005 15:48:57 -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 1Dhvrb-0003v3-00 for ipfix-info@net.doit.wisc.edu; Mon, 13 Jun 2005 15:48:55 -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 j5DKmsZ22741; Mon, 13 Jun 2005 22:48:54 +0200 (CEST) Received: from [10.21.96.237] (sjc-vpn1-237.cisco.com [10.21.96.237]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j5DKmrF06896; Mon, 13 Jun 2005 22:48:53 +0200 (CEST) Message-ID: <42ADF133.3010501@cisco.com> Date: Mon, 13 Jun 2005 22:48:51 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] simple editorial changes for the information model draft References: <4BAE46B432D86EAC62F0160D@753F3B888A9969457862729D> In-Reply-To: <4BAE46B432D86EAC62F0160D@753F3B888A9969457862729D> 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, > Benoit, > > --On 6/13/2005 4:06 PM +0200 Benoit Claise wrote: > >> Juergen, >> >>> >>>> - Section 5.2.6 observedFlowTotalCount >>>> >>>> Description: >>>> The total number of Flows observed in the Observation Domain >>>> since >>>> the Metering Process (re-)initialization for this Observation >>>> Point. >>>> ElementId: 3 >>>> >>>> We should be in line with the RFC 3954 that explains something >>>> different: Number of Flows that were aggregated; >>> >>> >>> >>> Fine to be in line. But what means RFC 3954 with "Flows that were >>> aggregated"? >>> The common definition of flow aggregation is merging individual flow >>> records >>> of different flows into a single one. This is in line with the last >>> paragraph >>> on page 4 of RFC 3954. But this is not what I understood so far as the >>> semantics of Information Element #3 "observedFlowTotalCount". >> >> >> It's because the ElementId 3 name and description changed along the >> different versions. >> >> flowCount (version 3) -> totalFlowCount (version 6) -> >> observedFlowTotalCount (version 7) > > > This is not the point. My comment applies to flowCount as well as > to totalFlowCount and to observedFlowTotalCount. flowCount and totalFlowCount?? > >> I guess you want: >> - Element Id 3 to be in line with RFC3954 >> - A new I.E. for observedFlowTotalCount, if you have a need for it > > > Sorry, I cannot follow: > > What is wrong with the current description? > Is it the term 'total'? Is IE #3 a delta counter? You need some NetFlow internal information in order to understand the I.E. # 3 as defined in RFC3954 The NetFlow metering process works with a main cache from which flow records are expired. From there, you can aggregate flow records further into smaller caches. Typically example: the main cache contains the src and dst IP addresses, while the aggregation cache contains the src and dst prefixes. For each flow records in the aggregation cache, the Element Id 3 (defined as "Number of Flows that were aggregated" in RFC3954) contains the number of flow records that we aggregated from the main cache into this flow in the aggregation cache. Note that this was not described in RFC3954, as this RFC deals with the export protocol and not the metering process. > > I do not like the description from RFC3954, because I think the > term "aggregated" is wrong. However, this is the right term according to my explanation above. :) So basically, I'm suggesting: - Element Id 3 should be in line with RFC3954. If you consider this I.E. too Cisco specific, then mark it as reserved but it would be a source of confusion to change his description. - So if you need an I.E. that matches the following definition, i.e. the IPFIX-INFO version 7 description of observedFlowTotalCount, then I advice to allocate a new I.E. # Description: The total number of Flows observed in the Observation Domain since the Metering Process (re-)initialization for this Observation Point. Does it make sense now? > >>>> - Section 5.10.3 flowEndReason >>>> >>>> Description: >>>> The reason for flow termination. The range of values includes >>>> Abstract Data Type: octet >>>> Data Type Semantics: identifier >>>> ElementId: 136 >>>> Status: current >>>> The description is incomplete. The person who requested it should >>>> complete the description >>> >>> >>> >>> This was my fault. I used the wrong XML tag and the list of reasons >>> disappeared. It is >>> >>> 0x01: idle timeout >>> 0x02: active timeout >>> 0x03: end of Flow detected (e.g. TCP FIN) >>> 0x04: forced end >>> 0x05: cache full >> >> >> What does the force end mean? > > > And end of this flow enforced by any component of the architecture and > that is not covered by any of the other reasons. You can end a flow by > shutting down the IP interface, by terminating the metering or exporting > process, ... Fair enough, then it should be described. 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 Mon Jun 13 20:04:42 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23123 for ; Mon, 13 Jun 2005 20:04:42 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DhyeJ-0002sX-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Jun 2005 18:47:23 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DhyeH-0002sS-00 for ipfix-info@net.doit.wisc.edu; Mon, 13 Jun 2005 18:47:22 -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 34B9A1BAC4D; Tue, 14 Jun 2005 01:47:20 +0200 (CEST) Date: Tue, 14 Jun 2005 01:47:16 +0200 From: Juergen Quittek To: Benoit Claise Cc: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] simple editorial changes for the information model draft Message-ID: <715153C6E40AD720297BCE05@[192.168.0.112]> In-Reply-To: <42ADF133.3010501@cisco.com> References: <4BAE46B432D86EAC62F0160D@753F3B888A9969457862729D> <42ADF133.3010501@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 --On 6/13/2005 10:48 PM +0200 Benoit Claise wrote: > Hi Juergen, > >> Benoit, >> >> --On 6/13/2005 4:06 PM +0200 Benoit Claise wrote: >> >>> Juergen, >>> >>>> >>>>> - Section 5.2.6 observedFlowTotalCount >>>>> >>>>> Description: >>>>> The total number of Flows observed in the Observation Domain >>>>> since >>>>> the Metering Process (re-)initialization for this Observation >>>>> Point. >>>>> ElementId: 3 >>>>> >>>>> We should be in line with the RFC 3954 that explains something >>>>> different: Number of Flows that were aggregated; >>>> >>>> >>>> >>>> Fine to be in line. But what means RFC 3954 with "Flows that were >>>> aggregated"? >>>> The common definition of flow aggregation is merging individual flow >>>> records >>>> of different flows into a single one. This is in line with the last >>>> paragraph >>>> on page 4 of RFC 3954. But this is not what I understood so far as the >>>> semantics of Information Element #3 "observedFlowTotalCount". >>> >>> >>> It's because the ElementId 3 name and description changed along the >>> different versions. >>> >>> flowCount (version 3) -> totalFlowCount (version 6) -> >>> observedFlowTotalCount (version 7) >> >> >> This is not the point. My comment applies to flowCount as well as >> to totalFlowCount and to observedFlowTotalCount. > > flowCount and totalFlowCount?? Yes, my problem is the term 'aggregated'. This does not harmonize with any of the three names. >> >>> I guess you want: >>> - Element Id 3 to be in line with RFC3954 >>> - A new I.E. for observedFlowTotalCount, if you have a need for it >> >> >> Sorry, I cannot follow: >> >> What is wrong with the current description? >> Is it the term 'total'? Is IE #3 a delta counter? > > You need some NetFlow internal information in order to understand the I.E. # 3 > as defined in RFC3954 The NetFlow metering process works with a main cache from > which flow records are expired. From there, you can aggregate flow records further > into smaller caches. Typically example: the main cache contains the src and dst > IP addresses, while the aggregation cache contains the src and dst prefixes. > For each flow records in the aggregation cache, the Element Id 3 (defined as > "Number of Flows that were aggregated" in RFC3954) contains the number of flow > records that we aggregated from the main cache into this flow in the aggregation > cache. > > Note that this was not described in RFC3954, as this RFC deals with the export > protocol and not the metering process. >> >> I do not like the description from RFC3954, because I think the >> term "aggregated" is wrong. > > However, this is the right term according to my explanation above. :) I see. It is correct. But only for the Cisco implementation and not necessarily for, say, NetFlow with IPFIX support. And it is not necessarily correctly understood by readers without knowledge of undocumented internals of the Cisco NetFlow implementation. We use the term 'aggregated' in the terminology sections of protocol and architecture. But the way we use it is fully in line with the idea of fine grain micro flows that CAN BE aggregated into coarser grained macro flows (but not necessarily ARE aggregated). The term "aggregated flows" can easily interpreted as including all flows that result from an aggregation of micro flows, but excluding non-aggregated micro flows. This (argueable) understanding would be wrong. (Also RFC 3954 uses the term 'aggregated' in the definition of the collector with respect to aggregating existing IPFIX flow records. Therefore, we should replace 'aggregated' flows by 'metered' flows, 'observed' flows or something else that is understood with less ambiguity. Still my question is: What is wrong with the current description? > So basically, I'm suggesting: > - Element Id 3 should be in line with RFC3954. If you consider this I.E. too Cisco > specific, then mark it as reserved but it would be a source of confusion to change > his description. No. It is not too Cisco-specific. Just it's description is. Why do you think the current description does not match the Cisco implementation of #3? > - So if you need an I.E. that matches the following definition, i.e. the IPFIX-INFO > version 7 description of observedFlowTotalCount, then I advice to allocate a new I.E. # > Description: > The total number of Flows observed in the Observation Domain since > the Metering Process (re-)initialization for this Observation > Point. > > Does it make sense now? I still do not understand the problem with the current definition. Is it a delta counter? Then we should rename it to observedFlowsDeltaCount. >> >>>>> - Section 5.10.3 flowEndReason >>>>> >>>>> Description: >>>>> The reason for flow termination. The range of values includes >>>>> Abstract Data Type: octet >>>>> Data Type Semantics: identifier >>>>> ElementId: 136 >>>>> Status: current >>>>> The description is incomplete. The person who requested it should >>>>> complete the description >>>> >>>> >>>> >>>> This was my fault. I used the wrong XML tag and the list of reasons >>>> disappeared. It is >>>> >>>> 0x01: idle timeout >>>> 0x02: active timeout >>>> 0x03: end of Flow detected (e.g. TCP FIN) >>>> 0x04: forced end >>>> 0x05: cache full >>> >>> >>> What does the force end mean? >> >> >> And end of this flow enforced by any component of the architecture and >> that is not covered by any of the other reasons. You can end a flow by >> shutting down the IP interface, by terminating the metering or exporting >> process, ... > > Fair enough, then it should be described. Fully agreed. I will extend the description accordingly. > 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 Tue Jun 14 08:54:36 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10658 for ; Tue, 14 Jun 2005 08:54:36 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DiAZs-0001Lt-00 for ipfix-list@mil.doit.wisc.edu; Tue, 14 Jun 2005 07:31:36 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DiAZr-0001Lm-00 for ipfix-info@net.doit.wisc.edu; Tue, 14 Jun 2005 07:31:35 -0500 Received: from [193.175.133.240] (luz@kaitos [193.175.133.240]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j5ECVVm17802; Tue, 14 Jun 2005 14:31:32 +0200 (MEST) Message-ID: <42AECE23.5070607@fokus.fraunhofer.de> Date: Tue, 14 Jun 2005 14:31:31 +0200 From: Lutz Mark User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] IPFIX-INFO open issue 1: octet count including layer 2 payload References: <42A61775.4040000@cisco.com> <42ADAFE6.6000409@fokus.fraunhofer.de> <8EF2C38AAE5369EB02240495@[10.1.1.171]> In-Reply-To: <8EF2C38AAE5369EB02240495@[10.1.1.171]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Juergen, > For this solution we would need at least one more information element > indicating layer 2 technologies that are included in the octet count. > An array of bit fields may be a possibility. but it would probably not > be easy to extend it to new upcoming layer 2 technologies?? maybe it is feasible just to announce the number of layer 2 bytes. > Definitely, the option record you suggest must be standardized in order > to be understood by every compliant collector. sure. If we run out of time, we can reserve this feature for IPFIX version 2 ;-) Best regards, Lutz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jun 14 09:01:48 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11158 for ; Tue, 14 Jun 2005 09:01:48 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DiAmE-0001nd-00 for ipfix-list@mil.doit.wisc.edu; Tue, 14 Jun 2005 07:44:22 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DiAmD-0001nW-00 for ipfix-info@net.doit.wisc.edu; Tue, 14 Jun 2005 07:44:21 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 8F853DC5F; Tue, 14 Jun 2005 14:59:30 +0200 (CEST) Received: from [10.1.1.171] ([10.1.1.171]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Jun 2005 14:45:17 +0200 Date: Tue, 14 Jun 2005 14:44:21 +0200 From: Juergen Quittek To: Lutz Mark Cc: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] IPFIX-INFO open issue 1: octet count including layer 2 payload Message-ID: In-Reply-To: <42AECE23.5070607@fokus.fraunhofer.de> References: <42A61775.4040000@cisco.com> <42ADAFE6.6000409@fokus.fraunhofer.de> <8EF2C38AAE5369EB02240495@[10.1.1.171]> <42AECE23.5070607@fokus.fraunhofer.de> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 14 Jun 2005 12:45:17.0340 (UTC) FILETIME=[EABF8DC0:01C570DE] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Lutz, --On 6/14/2005 2:31 PM +0200 Lutz Mark wrote: > Hi Juergen, > >> For this solution we would need at least one more information element >> indicating layer 2 technologies that are included in the octet count. >> An array of bit fields may be a possibility. but it would probably not >> be easy to extend it to new upcoming layer 2 technologies?? > maybe it is feasible just to announce the number of layer 2 bytes. > >> Definitely, the option record you suggest must be standardized in order >> to be understood by every compliant collector. > sure. If we run out of time, we can reserve > this feature for IPFIX version 2 ;-) So you suggest to drop it for now? > Best regards, > Lutz 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 Jun 14 10:00:39 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19400 for ; Tue, 14 Jun 2005 10:00:39 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DiBby-0003LI-00 for ipfix-list@mil.doit.wisc.edu; Tue, 14 Jun 2005 08:37:50 -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 1DiBbw-0003LD-00 for ipfix-info@net.doit.wisc.edu; Tue, 14 Jun 2005 08:37:49 -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 1DiBbw-0005gp-1M for ipfix-info@net.doit.wisc.edu; Tue, 14 Jun 2005 15:37:48 +0200 Message-ID: <42AEDDE5.6090400@CS.Uni-Goettingen.DE> Date: Tue, 14 Jun 2005 15:38:45 +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: Re: [ipfix-info] IPFIX-INFO open issue 1: octet count including layer 2 payload References: <42A61775.4040000@cisco.com> In-Reply-To: <42A61775.4040000@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, Benoit Claise schrieb: > The last-call finishes on June 15th, so it's time to get a consensus > regarding this open issue described in the latest section of [IPFIX-INFO] > > octet count including MPLS header: Does the octet count concern IP > packets only or also sub-IP layers such as MPLS? For the case you are interested in an opinion from "outside" here's my comment: The project is about "IP flows", so I would of course expect, that such a flow consists of nothing but IP packets, although it can be defined by flow keys from sub-IP layers. I agree, that there are a lot of other useful things to count, but these shouldn't be included in the basic octet counters of the _IP_flow_ itself. Imagine the same IP flow is measured at two observation points, and only at one of them MPLS is used. These two flow measurements would have different sizes, even if the IP packets haven't been altered (like fragmented), although the defining attributes are the same. This will be a source of confusion, I think. 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 Tue Jun 14 10:17:23 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21320 for ; Tue, 14 Jun 2005 10:17:23 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DiBwX-00045L-00 for ipfix-list@mil.doit.wisc.edu; Tue, 14 Jun 2005 08:59:05 -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 1DiBwW-00045G-00 for ipfix-info@net.doit.wisc.edu; Tue, 14 Jun 2005 08:59:04 -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 j5EDx2824770; Tue, 14 Jun 2005 15:59:02 +0200 (CEST) Received: from [10.21.97.61] (sjc-vpn1-317.cisco.com [10.21.97.61]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j5EDx0F06036; Tue, 14 Jun 2005 15:59:01 +0200 (CEST) Message-ID: <42AEE2A3.1050905@cisco.com> Date: Tue, 14 Jun 2005 15:58:59 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lutz Mark CC: Juergen Quittek , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] IPFIX-INFO open issue 1: octet count including layer 2 payload References: <42A61775.4040000@cisco.com> <42ADAFE6.6000409@fokus.fraunhofer.de> <8EF2C38AAE5369EB02240495@[10.1.1.171]> <42AECE23.5070607@fokus.fraunhofer.de> In-Reply-To: <42AECE23.5070607@fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Lutz, > Hi Juergen, > >> For this solution we would need at least one more information element >> indicating layer 2 technologies that are included in the octet count. >> An array of bit fields may be a possibility. but it would probably not >> be easy to extend it to new upcoming layer 2 technologies?? > > maybe it is feasible just to announce the number of layer 2 bytes. > >> Definitely, the option record you suggest must be standardized in order >> to be understood by every compliant collector. > > sure. If we run out of time, we can reserve > this feature for IPFIX version 2 ;-) If the consensus is to keep the counters for IP only, fair enough. As the last-call is almost over (June 15th), I concur with Lutz's point of view. Regards, Benoit. > > Best regards, > Lutz > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- 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 Jun 14 12:20:37 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01517 for ; Tue, 14 Jun 2005 12:20:32 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DiE0o-0007mj-00 for ipfix-list@mil.doit.wisc.edu; Tue, 14 Jun 2005 11:11:38 -0500 Received: from tik6.ethz.ch ([129.132.119.136]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DiE0n-0007mc-00 for ipfix@net.doit.wisc.edu; Tue, 14 Jun 2005 11:11:37 -0500 Received: from localhost (localhost [127.0.0.1]) by tik6.ethz.ch (Postfix) with ESMTP id 5C2986ADCE for ; Tue, 14 Jun 2005 18:11:36 +0200 (MEST) Received: from tik6.ethz.ch ([127.0.0.1]) by localhost (tik6 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09066-04 for ; Tue, 14 Jun 2005 18:11:36 +0200 (MEST) Received: from [10.147.66.154] (fokus192.fokus.fraunhofer.de [195.37.76.192]) by tik6.ethz.ch (Postfix) with ESMTP id C1C356ADCC for ; Tue, 14 Jun 2005 18:11:35 +0200 (MEST) Message-ID: <42AF02FF.3020404@fokus.fraunhofer.de> Date: Tue, 14 Jun 2005 18:17:03 +0200 From: Elisa Boschi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Subject: [ipfix] agenda items for IETF in Paris References: <425C4D3E.1020208@cisco.com> <1113394155.86c9a7b917a04@webmail.auckland.ac.nz> <42658048.6050702@cisco.com> <4265A2C0.20801@cisco.com> <42660F1B.3060702@cisco.com> <1117060349.2b491681bb1f8@webmail.auckland.ac.nz> <4294FE00.1070605@cisco.com> <1117065634.986050c870a39@webmail.auckland.ac.nz> In-Reply-To: <1117065634.986050c870a39@webmail.auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at tik.ee.ethz.ch Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear Nevil, Dave, all, we have two agenda items for the next IETF in Paris: - IPFIX interoperability preliminary report. There will be an IPFIX interoperability event in Paris right before the IETF. During the meeting we could talk about the testing and tell people about the main outcome of the event - IPFIX implementation experience. Lutz and I are planning to submit a Draft about "Guidelines for IPFIX implementation". It would be nice to have a slot to present it Thanks, Elisa > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From ApoliDukes_4284@kabuto.com Wed Jun 15 06:48:58 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01040 for ; Wed, 15 Jun 2005 06:48:58 -0400 (EDT) Received: from [220.95.71.208] (helo=kabuto.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DiV7O-0000tE-00 for ipfix-list@mil.doit.wisc.edu; Wed, 15 Jun 2005 05:27:35 -0500 From: "Apolinar Dukes" To: "Honey Garner" Subject: The Probleem Solved Date: Wed, 15 Jun 2005 05:27:34 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01C57194.D7D3AF00" 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?220.95.71.208 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0042_01C57194.D7D3AF00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Dr. Whacker drew still closer to him as they stepped along the wharf.Now I = don't agree with you at all. Captain Blood sat down on theof Maracaybo = and effected its raid upon that opulent city of theShe nodded. She was = very calm and self-contained; but his lordshipM. de Rivarol, intrigued = by his mirth, scowled upon himheaving breast, her face deathly pale, a = wild terror in her eyes.for I doubt if we are standing more than ten = degrees westward.led to it.course for your benefit. It's his intention = to put you both ashorethe negro steward, in white drawers and cotton = shirt, made hasteStill he could not believe what it saw. And then a = voice at hisof himself, to practise something that was akin to villainy. = Ieven as his fingers closed upon the hilt, the other's closed = uponMajesty's West Indian fleet, at present mislaid somewhere in = thisabove decks, the French fifed low to smash the hull of theirhad to = be, he said. Say now, gentlemen, whether I am justified ------=_NextPart_000_0042_01C57194.D7D3AF00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good day,

We are leprosarium = pleased to introduce ourselves as one of the leading online = pharmace lashing uticaI = shops.

Save over 70 Percent On your Me service ds with MedzByMail S eudiometer = hop

V determination l		meringue A		l espresso A		L amplify l
A = primates GR	= acridity C	excuse = LIS V woofer = A	buoyant = UM	and many other.

With each purc = Holland hase you get:

Top quaI parlour = ity

Best deposit = Prices

Total confide nailer = ntiaIity

Home epidemic = deIivery

Have a nice day.

------=_NextPart_000_0042_01C57194.D7D3AF00-- From 836kaiser@aptsolutions.com Wed Jun 15 12:23:10 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00426 for ; Wed, 15 Jun 2005 12:23:10 -0400 (EDT) Received: from [219.234.102.71] (helo=219.234.102.71) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DiaVF-0003H5-00 for ipfix-list@mil.doit.wisc.edu; Wed, 15 Jun 2005 11:12:34 -0500 Message-ID: From: "Richard K. Lee" <836kaiser@aptsolutions.com> To: ipfix-list@mil.doit.wisc.edu Subject: =?iso-8859-1?B?VmlhZ3JhIC0gZHV0eS1mcmVlIHByaWNl?= Date: Wed, 15 Jun 2005 16:01:56 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_6CE16C73.2DD16672" 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_6CE16C73.2DD16672 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_A7914E4F.73C680AD" ------=_NextPart_001_0001_A7914E4F.73C680AD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Full erection Long lasting effects No prescription asked 2 popular medicines: CIALIS - http://www.pills-now.com/sv/ VIAGRA - http://www.pills-now.com/vt/ Delivered in a discreet package _________________________________________________________________________ To stop further mailings, go here _________________________________________________________________________ ------=_NextPart_001_0001_A7914E4F.73C680AD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Full erection
Long lasting effects
No prescription asked

2 popular medicines:
CIALIS - http://www.pills-now.com/sv/
VIAGRA - http://www.pills-now.com/vt/

Delivered in a discreet package

_________________________________________________________________________
To stop further mailings, go here
_________________________________________________________________________

------=_NextPart_001_0001_A7914E4F.73C680AD-- ------=_NextPart_000_0000_6CE16C73.2DD16672-- From majordomo@mil.doit.wisc.edu Wed Jun 15 13:00:05 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03365 for ; Wed, 15 Jun 2005 13:00:05 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dib86-0004X1-00 for ipfix-list@mil.doit.wisc.edu; Wed, 15 Jun 2005 11:52:42 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dib85-0004Ww-00 for ipfix-info@net.doit.wisc.edu; Wed, 15 Jun 2005 11:52:41 -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 AB3BC1BAC4D; Wed, 15 Jun 2005 18:52:39 +0200 (CEST) Date: Wed, 15 Jun 2005 18:52:38 +0200 From: Juergen Quittek To: ipfix-info@net.doit.wisc.edu Cc: Benoit Claise Subject: Re: [ipfix-info] simple editorial changes for the information model draft Message-ID: <7B067F72FB38D717CF7C5A3B@[192.168.0.112]> In-Reply-To: <4BAE46B432D86EAC62F0160D@753F3B888A9969457862729D> References: <4BAE46B432D86EAC62F0160D@753F3B888A9969457862729D> 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, So far I misunderstood this issue raised by Benoit. On Tuesday discussed it on the phone where he explained it to me in detail and now I share his view. Information element #3 does indicate the number of (fine grained) flow records of the first level flow cache that are aggregated into a single flow record in the second level flow cache of the Cisco NetFlow implementation. This value is reported per flow. Since the design of first and second level flow caches may vary from implementation to implementation, it does not make sense to standardize this information element. However, it does make sense standardizing an Information Element 'observedFlowTotalCount' as described in the current information model. We just need to assign it a different number as suggested by Benoit. Thanks, Juergen --On 6/13/2005 5:20 PM +0200 Juergen Quittek wrote: > Benoit, > > --On 6/13/2005 4:06 PM +0200 Benoit Claise wrote: > >> Juergen, >> >>> >>>> - Section 5.2.6 observedFlowTotalCount >>>> >>>> Description: >>>> The total number of Flows observed in the Observation Domain since >>>> the Metering Process (re-)initialization for this Observation >>>> Point. >>>> ElementId: 3 >>>> >>>> We should be in line with the RFC 3954 that explains something >>>> different: Number of Flows that were aggregated; >>> >>> >>> Fine to be in line. But what means RFC 3954 with "Flows that were >>> aggregated"? >>> The common definition of flow aggregation is merging individual flow >>> records >>> of different flows into a single one. This is in line with the last >>> paragraph >>> on page 4 of RFC 3954. But this is not what I understood so far as the >>> semantics of Information Element #3 "observedFlowTotalCount". >> >> It's because the ElementId 3 name and description changed along the different versions. >> >> flowCount (version 3) -> totalFlowCount (version 6) -> observedFlowTotalCount (version 7) > > This is not the point. My comment applies to flowCount as well as > to totalFlowCount and to observedFlowTotalCount. > >> I guess you want: >> - Element Id 3 to be in line with RFC3954 >> - A new I.E. for observedFlowTotalCount, if you have a need for it > > Sorry, I cannot follow: > > What is wrong with the current description? > Is it the term 'total'? Is IE #3 a delta counter? > > I do not like the description from RFC3954, because I think the > term "aggregated" is wrong. > >>>> - Section 5.10.3 flowEndReason >>>> >>>> Description: >>>> The reason for flow termination. The range of values includes >>>> Abstract Data Type: octet >>>> Data Type Semantics: identifier >>>> ElementId: 136 >>>> Status: current >>>> The description is incomplete. The person who requested it should >>>> complete the description >>> >>> >>> This was my fault. I used the wrong XML tag and the list of reasons >>> disappeared. It is >>> >>> 0x01: idle timeout >>> 0x02: active timeout >>> 0x03: end of Flow detected (e.g. TCP FIN) >>> 0x04: forced end >>> 0x05: cache full >> >> What does the force end mean? > > And end of this flow enforced by any component of the architecture and > that is not covered by any of the other reasons. You can end a flow by > shutting down the IP interface, by terminating the metering or exporting > process, ... > >> Regards, Benoit. > > Thanks, > > Juergen > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Jun 15 13:03:24 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03591 for ; Wed, 15 Jun 2005 13:03:23 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DibAt-0004aX-00 for ipfix-list@mil.doit.wisc.edu; Wed, 15 Jun 2005 11:55:35 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DibAs-0004aS-00 for ipfix-info@net.doit.wisc.edu; Wed, 15 Jun 2005 11:55:34 -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 328B91BAC4D; Wed, 15 Jun 2005 18:55:32 +0200 (CEST) Date: Wed, 15 Jun 2005 18:55:33 +0200 From: Juergen Quittek To: Sven Anderson , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] IPFIX-INFO open issue 1: octet count including layer 2 payload Message-ID: <2A0617099B5BF3247F377BF8@[192.168.0.112]> In-Reply-To: <42AEDDE5.6090400@CS.Uni-Goettingen.DE> References: <42A61775.4040000@cisco.com> <42AEDDE5.6090400@CS.Uni-Goettingen.DE> 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 Sven, Thanks for stating your opinion on this issue. Unfortunately, the number of comments received so far is very short. Juergen --On 6/14/2005 3:38 PM +0200 Sven Anderson wrote: > Dear all, > > Benoit Claise schrieb: >> The last-call finishes on June 15th, so it's time to get a consensus >> regarding this open issue described in the latest section of [IPFIX-INFO] >> >> octet count including MPLS header: Does the octet count concern IP >> packets only or also sub-IP layers such as MPLS? > > For the case you are interested in an opinion from "outside" here's my > comment: > > The project is about "IP flows", so I would of course expect, that such a > flow consists of nothing but IP packets, although it can be defined by > flow keys from sub-IP layers. I agree, that there are a lot of other > useful things to count, but these shouldn't be included in the basic octet > counters of the _IP_flow_ itself. > > Imagine the same IP flow is measured at two observation points, and only > at one of them MPLS is used. These two flow measurements would have > different sizes, even if the IP packets haven't been altered (like > fragmented), although the defining attributes are the same. This will be a > source of confusion, I think. > > > 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 Jun 15 13:11:47 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04313 for ; Wed, 15 Jun 2005 13:11:47 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DibKy-00054U-00 for ipfix-list@mil.doit.wisc.edu; Wed, 15 Jun 2005 12:06:00 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DibKx-00054P-00 for ipfix-info@net.doit.wisc.edu; Wed, 15 Jun 2005 12:05:59 -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 DB11C1BAC4D; Wed, 15 Jun 2005 19:05:57 +0200 (CEST) Date: Wed, 15 Jun 2005 19:05:57 +0200 From: Juergen Quittek To: Sven Anderson , ipfix-info@net.doit.wisc.edu Subject: [ipfix-info] PLEASE comment: octet counter semantics Message-ID: <7DCBCB96E275952B5517468A@[192.168.0.112]> 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 open issue of the info model is quite fundamental for IPFIX. I am surprised, that there so few statements have been posted on this issue. PLEASE have a look at it and contribute your view on the mailing list! Concerned are all octet counters for observed packets (incoming, outgoing, dropped, multicast). The question is whether these counters should count a) exclusively octets contained in observed IP packets or b) include in the count also the octets contained in headers/frames of some of the layer 2 protocols carrying the IP packets Thanks, Juergen --On 6/14/2005 3:38 PM +0200 Sven Anderson wrote: > Dear all, > > Benoit Claise schrieb: >> The last-call finishes on June 15th, so it's time to get a consensus >> regarding this open issue described in the latest section of [IPFIX-INFO] >> >> octet count including MPLS header: Does the octet count concern IP >> packets only or also sub-IP layers such as MPLS? > > For the case you are interested in an opinion from "outside" here's my > comment: > > The project is about "IP flows", so I would of course expect, that such a > flow consists of nothing but IP packets, although it can be defined by > flow keys from sub-IP layers. I agree, that there are a lot of other > useful things to count, but these shouldn't be included in the basic octet > counters of the _IP_flow_ itself. > > Imagine the same IP flow is measured at two observation points, and only > at one of them MPLS is used. These two flow measurements would have > different sizes, even if the IP packets haven't been altered (like > fragmented), although the defining attributes are the same. This will be a > source of confusion, I think. > > > 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 Jun 15 13:30:09 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06632 for ; Wed, 15 Jun 2005 13:30:09 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dibd5-0005dR-00 for ipfix-list@mil.doit.wisc.edu; Wed, 15 Jun 2005 12:24:43 -0500 Received: from natsmtp00.rzone.de ([81.169.145.165]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dibd4-0005dM-00 for ipfix-info@net.doit.wisc.edu; Wed, 15 Jun 2005 12:24:42 -0500 Received: from [192.168.0.20] (p549713E0.dip0.t-ipconnect.de [84.151.19.224]) (authenticated bits=0) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id j5FHObXM019826; Wed, 15 Jun 2005 19:24:38 +0200 (MEST) From: Andreas Bourges Reply-To: andreas.bourges@isarnet.de Organization: IsarNet AG To: Juergen Quittek Subject: Re: [ipfix-info] PLEASE comment: octet counter semantics Date: Wed, 15 Jun 2005 19:24:32 +0200 User-Agent: KMail/1.8 Cc: Sven Anderson , ipfix-info@net.doit.wisc.edu References: <7DCBCB96E275952B5517468A@[192.168.0.112]> In-Reply-To: <7DCBCB96E275952B5517468A@[192.168.0.112]> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3018619.deKEKjit8b"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506151924.35751.andreas.bourges@isarnet.de> Precedence: bulk Sender: majordomo listserver --nextPart3018619.deKEKjit8b Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, =2E..I think it it would be better to *not* include L2 header information. = Even=20 within an enterprise network this byte count may change - so it doesn't=20 really "belong" to the flow monitored. I agree with Sven's opinion, that=20 flows measured at two points should have identical byte counts. Imagine a=20 customer using ipfix at his site to verify bills from his SP and they have= =20 different L2 technologies?! Cheers, andy On Wednesday 15 June 2005 19:05, Juergen Quittek wrote: > Dear all, > > This open issue of the info model is quite fundamental for IPFIX. > > I am surprised, that there so few statements have been posted on this > issue. > > PLEASE have a look at it and contribute your view on the mailing list! > > Concerned are all octet counters for observed packets (incoming, outgoing, > dropped, multicast). > > The question is whether these counters should count > > a) exclusively octets contained in observed IP packets or > b) include in the count also the octets contained in headers/frames > of some of the layer 2 protocols carrying the IP packets > > Thanks, > > Juergen > > --On 6/14/2005 3:38 PM +0200 Sven Anderson wrote: > > Dear all, > > > > Benoit Claise schrieb: > >> The last-call finishes on June 15th, so it's time to get a consensus > >> regarding this open issue described in the latest section of > >> [IPFIX-INFO] > >> > >> octet count including MPLS header: Does the octet count concern IP > >> packets only or also sub-IP layers such as MPLS? > > > > For the case you are interested in an opinion from "outside" here's my > > comment: > > > > The project is about "IP flows", so I would of course expect, that such= a > > flow consists of nothing but IP packets, although it can be defined by > > flow keys from sub-IP layers. I agree, that there are a lot of other > > useful things to count, but these shouldn't be included in the basic > > octet counters of the _IP_flow_ itself. > > > > Imagine the same IP flow is measured at two observation points, and only > > at one of them MPLS is used. These two flow measurements would have > > different sizes, even if the IP packets haven't been altered (like > > fragmented), although the defining attributes are the same. This will be > > a source of confusion, I think. > > > > > > 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/ =2D-=20 Andreas Bourges CCIE #6947 (R&S,C&S) GSM: +49 178 7072022 e-mail: andreas.bourges@isarnet.de =2D---------------------------------- IsarNet AG Terminalstrasse Mitte 18 85356 M=FCnchen Tel.: 07000-isarnet Fax : 089-97007-200 http://www.isarnet.de =2D---------------------------------- --nextPart3018619.deKEKjit8b Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBCsGRTRrny/uOBVy4RAuYlAKCoFbxo8zoaFhRGIaSTBbHPXFcfHQCeObLQ PD8vahwILsqfJEJtc1MrkZM= =W+RN -----END PGP SIGNATURE----- --nextPart3018619.deKEKjit8b-- -- 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 Jun 15 13:52:17 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09054 for ; Wed, 15 Jun 2005 13:52:17 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dibnq-0005sN-00 for ipfix-list@mil.doit.wisc.edu; Wed, 15 Jun 2005 12:35:50 -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 1Dibnp-0005rm-00 for ipfix-info@net.doit.wisc.edu; Wed, 15 Jun 2005 12:35:49 -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 CB80480BE; Wed, 15 Jun 2005 19:35:44 +0200 (CEST) Subject: Re: [ipfix-info] IPFIX-INFO open issue 1: octet count including layer 2 payload From: Jeroen Massar To: Juergen Quittek Cc: Sven Anderson , ipfix-info@net.doit.wisc.edu In-Reply-To: <2A0617099B5BF3247F377BF8@[192.168.0.112]> References: <42A61775.4040000@cisco.com> <42AEDDE5.6090400@CS.Uni-Goettingen.DE> <2A0617099B5BF3247F377BF8@[192.168.0.112]> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-J9DHq5MRC1yGg1josfet" Organization: Unfix Date: Wed, 15 Jun 2005 19:35:38 +0200 Message-Id: <1118856938.16173.157.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 Precedence: bulk Sender: majordomo listserver --=-J9DHq5MRC1yGg1josfet Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-06-15 at 18:55 +0200, Juergen Quittek wrote: > Sven, >=20 > Thanks for stating your opinion on this issue. > Unfortunately, the number of comments received so far is very short. One inline :) > --On 6/14/2005 3:38 PM +0200 Sven Anderson wrote: >=20 > > Dear all, > > > > Benoit Claise schrieb: > >> The last-call finishes on June 15th, so it's time to get a consensus > >> regarding this open issue described in the latest section of [IPFIX-IN= FO] > >> > >> octet count including MPLS header: Does the octet count concern I= P > >> packets only or also sub-IP layers such as MPLS? Of course *not*. reasoning, mostly the same as Sven's, but to add some support to the case: If you would take IP over ethernet as an example: +---------------------+ | Ethernet header.... | +---------------------+ | IP -> flow size=3D500 | +---------------------+ Thus this flow is now sized 500 bytes, as IP shows this. Now on the other side of your network, it passes over a router which has ATM or MPLS or PPP or SLIP, whatever. +---------------------+ | Whatever header.... | +---------------------+ | IP -> flow size=3D500 | +---------------------+ Still the size is 500 bytes, nothing more nothing less. If you would add the header this would marginally change +/- a couple of bytes. If one wants to have counters for the complete frame, on whatever layer, then we might want to add "L1_OCTETS" "L1_PACKETS" "L2_OCTETS" and "L2_PACKETS" or something similar to solve this. But *don't* stick it into the current counters, this is not what NetFlow v9 does and not what, afaik, most implementations will expect to be doing because of that. Also now it is quite easy to see, in above scenario, that, based on src/dst/size pair the flow is most likely the same one on the first router and on the second one, which allows nice things like timings. While if you have different sizes, it is a different flow most likely. To put it differently IN/OUT_BYTES/PACKETS (1/2/23/24) describe the Layer 3 flow and not the Layer 2 Flow, which might differ. One sidenote though, with IPv6 one could have option headers, a router might, under some circumstances add/remove such a header and thus change the size of the L3 flow... Greets, Jeroen --=-J9DHq5MRC1yGg1josfet 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/ iD8DBQBCsGbqKaooUjM+fCMRAst8AKCeWUL/joGCj5sFnKgiOOzO9yV2IQCgmNND BgeaMmXWJg1mi2X7eVRFpqk= =XFLf -----END PGP SIGNATURE----- --=-J9DHq5MRC1yGg1josfet-- -- 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 Jun 15 14:21:26 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12177 for ; Wed, 15 Jun 2005 14:21:25 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DicQH-0007Af-00 for ipfix-list@mil.doit.wisc.edu; Wed, 15 Jun 2005 13:15:33 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DicQG-0007Aa-00 for ipfix-info@net.doit.wisc.edu; Wed, 15 Jun 2005 13:15:32 -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 j5FIFQ6F031712 for ; Wed, 15 Jun 2005 14:15:30 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id j5FIElYC031660 for ; Wed, 15 Jun 2005 14:14: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 j5FIElMu031658; Wed, 15 Jun 2005 14:14:47 -0400 (EDT) Received: from [128.237.230.241] (vpn-10-25-4-16.remote.cert.org [10.25.4.16]) by ioannes.indigo.cert.org (8.12.8/8.12.8/2.42.1.1) with ESMTP id j5FIElIh028585; Wed, 15 Jun 2005 14:14:47 -0400 In-Reply-To: <7DCBCB96E275952B5517468A@[192.168.0.112]> References: <7DCBCB96E275952B5517468A@[192.168.0.112]> Mime-Version: 1.0 (Apple Message framework v730) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0EC0C8E4-24BC-4113-A381-31DC7E1E5ED6@cert.org> Cc: Sven Anderson , ipfix-info@net.doit.wisc.edu Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [ipfix-info] PLEASE comment: octet counter semantics Date: Wed, 15 Jun 2005 14:14:46 -0400 To: Juergen Quittek X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000003 X-Scanned-By: MIMEDefang 2.51 on 192.88.209.10 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit My vote's for a) only counting IP octets. Attempting to handle layer 2 as well leads to murky semantics, and I've not yet seen a compelling case for precise and accurate counting of layer 2 headers at the flow level. Layer 2 header traffic volume would seem to be readily estimable for capacity planning &c. from layer 3 octet and packet counts. Regards, Brian Trammell - CERT/NetSA On Jun 15, 2005, at 1:05 PM, Juergen Quittek wrote: > Dear all, > > This open issue of the info model is quite fundamental for IPFIX. > > I am surprised, that there so few statements have been posted on > this issue. > > PLEASE have a look at it and contribute your view on the mailing list! > > Concerned are all octet counters for observed packets (incoming, > outgoing, > dropped, multicast). > > The question is whether these counters should count > > a) exclusively octets contained in observed IP packets or > b) include in the count also the octets contained in headers/frames > of some of the layer 2 protocols carrying the IP packets > > Thanks, > > Juergen > > > --On 6/14/2005 3:38 PM +0200 Sven Anderson wrote: > > >> Dear all, >> >> Benoit Claise schrieb: >> >>> The last-call finishes on June 15th, so it's time to get a consensus >>> regarding this open issue described in the latest section of >>> [IPFIX-INFO] >>> >>> octet count including MPLS header: Does the octet count >>> concern IP >>> packets only or also sub-IP layers such as MPLS? >>> >> >> For the case you are interested in an opinion from "outside" >> here's my >> comment: >> >> The project is about "IP flows", so I would of course expect, that >> such a >> flow consists of nothing but IP packets, although it can be >> defined by >> flow keys from sub-IP layers. I agree, that there are a lot of other >> useful things to count, but these shouldn't be included in the >> basic octet >> counters of the _IP_flow_ itself. >> >> Imagine the same IP flow is measured at two observation points, >> and only >> at one of them MPLS is used. These two flow measurements would have >> different sizes, even if the IP packets haven't been altered (like >> fragmented), although the defining attributes are the same. This >> will be a >> source of confusion, I think. >> >> >> 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/ > -- 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 Jun 16 20:49:57 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01642 for ; Thu, 16 Jun 2005 20:49:56 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dj4iy-00002b-00 for ipfix-list@mil.doit.wisc.edu; Thu, 16 Jun 2005 19:28:44 -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 1Dj4iw-00002U-00 for ipfix-info@net.doit.wisc.edu; Thu, 16 Jun 2005 19:28:42 -0500 Received: from dsl-082-082-187-117.arcor-ip.net ([82.82.187.117] helo=[192.168.0.6]) by mail.anderson.de with asmtp (Exim 4.20) id 1Dj4iu-0006ud-5A for ipfix-info@net.doit.wisc.edu; Fri, 17 Jun 2005 02:28:40 +0200 Message-ID: <42B21935.4020301@CS.Uni-Goettingen.DE> Date: Fri, 17 Jun 2005 02:28:37 +0200 From: Sven Anderson User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] IPFIX-INFO open issue 1: octet count including layer 2 payload References: <42A61775.4040000@cisco.com> <42AEDDE5.6090400@CS.Uni-Goettingen.DE> <2A0617099B5BF3247F377BF8@[192.168.0.112]> <1118856938.16173.157.camel@firenze.zurich.ibm.com> In-Reply-To: <1118856938.16173.157.camel@firenze.zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear Jeroen, dear all, Jeroen Massar schrieb: > If you would take IP over ethernet as an example: > +---------------------+ > | Ethernet header.... | > +---------------------+ > | IP -> flow size=500 | > +---------------------+ > > Thus this flow is now sized 500 bytes, as IP shows this. Now on the > other side of your network, it passes over a router which has ATM or > MPLS or PPP or SLIP, whatever. hmm... I have the feeling there is a misunderstanding. If I understood the mails of Benoit correctly, there was never the question to include L2 headers like normal Ethernet headers in the counters. It was more about technologies, which sit between L2 and L3 and therefore are placed in the _payload_ of the L2 encapsulation (like the "shim" headers of generic MPLS encapsulation, RFC 3031/3032). Let my try to explain to verify my understanding: Data Link Case 1: or Case 2: Layer IP Shim Header +-----------+ Only + IP | Header | +-----------+....+----------+....+-----------+ | | | | |Shim Header| | | | | |(e.g. MPLS)| | | | IP | +-----------+ | Payload | | Packet | | | | | | | | IP | | | | | | Packet | | | | | | | +-----------+....+----------+....+-----------+ | Trailer | +-----------+ In the normal case 1 the size of L2 payload and IP-packet is the same, so there is no problem. The question comes up in case 2, when not only the IP packet but also other information like MPLS shim headers are included in the L2 payload. You have to decide, if you count all payload bytes, or just the IP packet size. If I understood Benoit right, Netflow v9 in this case counts the whole payload, so not only the IP packet. But all the mentioned arguments are valid anywa, because the shim headers can vary a lot from section to section. (MPLS labels for example can not only be stored in shim headers but can for instance also be included in ATM headers itself: RFC 3035). So I still would suggest to let the counters only count the bytes of the IP packets and not of the whole L2 payload, if they are different. If there is really the frequent need to count the whole L2 payload size, I would suggest a second set of counter I.E.'s for the non-IP payload bytes in general (not technology depenend), which would be 0 in the usual case 1, and which could just be added to the basic counters if needed. If this need is not so common, it can be still defined as enterprise I.E.'s. Correct so far? Regards, 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 CarlBass_2@fureverfriends.com Fri Jun 17 00:01:19 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16619 for ; Fri, 17 Jun 2005 00:01:18 -0400 (EDT) Received: from [61.74.127.237] (helo=fureverfriends.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Dj7sb-0006LA-00 for ipfix-list@mil.doit.wisc.edu; Thu, 16 Jun 2005 22:50:54 -0500 From: "Carlie Bassett" To: "Nowell Feldman" Subject: I'm a Changed Man Date: Thu, 16 Jun 2005 22:50:54 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01C572EF.C2BF6300" 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_0032_01C572EF.C2BF6300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Aye, in God's name, go, my lord, spluttered Bishop, and makeat Oglethorpe's = Farm on the Monday morning after the battle atwith other things, that = the fellow seemed suddenly to stiffen, andfurther questions.betraying = those who trust him. He flung out an arm in the directionthe New. He = had come out to the Antilles, bringing with him hisMeanwhile, the = Frenchmen going about, gave the like reception toprecaution against = those released prisoners was to order them intoColonel Bishop had = accepted the post, and departed from theThen I'll take leave to marvel = that with so keen a nose yourcertainty, and then hell would open for = him. He cursed the hour inreduced crew of the Arabella a very different = tale leaked out toThere was a crispness about her voice, an ominous = challengingIn the background, moving slowly away down the line of = prisoners,It is not necessary to follow that action step by step. = BlundersPeter Blood was nauseated by the loathsome haggle. ------=_NextPart_000_0032_01C572EF.C2BF6300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to PiIlsOnIine St pregnancy ore

We are pleased to introduce ourselves as one of the = leading online pharmaceuticaI overblow = shops.

V dogged l		R flighty A		l periodical A		megacycle Ll
A ignoble = G	C	= therewith LIS VA	Brahma = UM	and many other.

- Sa culinary = ve over 70%

- TotaI = conversational confidentiaIity

- Wor predication = ldwide SHlPPlNG

- Over 5 million customers in archwise 150 countries

We do all we can to keep our comeliness customers fully satisfied = with our services!

------=_NextPart_000_0032_01C572EF.C2BF6300-- From majordomo@mil.doit.wisc.edu Fri Jun 17 00:31:38 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19008 for ; Fri, 17 Jun 2005 00:31:38 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dj8Pn-0007Lr-00 for ipfix-list@mil.doit.wisc.edu; Thu, 16 Jun 2005 23:25:11 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dj8Pl-0007LM-00 for ipfix-info@net.doit.wisc.edu; Thu, 16 Jun 2005 23:25:10 -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 1BF6C1BAC4D; Fri, 17 Jun 2005 06:25:08 +0200 (CEST) Date: Fri, 17 Jun 2005 06:25:11 +0200 From: Juergen Quittek To: Sven Anderson , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] IPFIX-INFO open issue 1: octet count including layer 2 payload Message-ID: <46EF8F5CDF4AA00723F988E8@[192.168.0.112]> In-Reply-To: <42B21935.4020301@CS.Uni-Goettingen.DE> References: <42A61775.4040000@cisco.com> <42AEDDE5.6090400@CS.Uni-Goettingen.DE> <2A0617099B5BF3247F377BF8@[192.168.0.112]> <1118856938.16173.157.camel@firenze.zurich.ibm.com> <42B21935.4020301@CS.Uni-Goettingen.DE> 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 Sven, Thanks you for clarifying the issue. I agree to your statements. I just have a small comment on terminology. Please find it inline. --On 6/17/2005 2:28 AM +0200 Sven Anderson wrote: > Dear Jeroen, dear all, > > Jeroen Massar schrieb: >> If you would take IP over ethernet as an example: >> +---------------------+ >> | Ethernet header.... | >> +---------------------+ >> | IP -> flow size=500 | >> +---------------------+ >> >> Thus this flow is now sized 500 bytes, as IP shows this. Now on the >> other side of your network, it passes over a router which has ATM or >> MPLS or PPP or SLIP, whatever. > > hmm... I have the feeling there is a misunderstanding. If I understood the > mails of Benoit correctly, there was never the question to include L2 > headers like normal Ethernet headers in the counters. It was more about > technologies, which sit between L2 and L3 and therefore are placed in the Yes, it sits in between IP on L3 and some L2 technology, but it MPLS is considered as part of L2 itself, see RFC 3031, MPLS architecture, terminology section 2.2. 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 > _payload_ of the L2 encapsulation (like the "shim" headers of generic MPLS > encapsulation, RFC 3031/3032). Let my try to explain to verify my understanding: > > Data Link Case 1: or Case 2: > Layer IP Shim Header > +-----------+ Only + IP >| Header | > +-----------+....+----------+....+-----------+ >| | | | | Shim Header| >| | | | | (e.g. MPLS)| >| | | IP | +-----------+ >| Payload | | Packet | | | >| | | | | IP | >| | | | | Packet | >| | | | | | > +-----------+....+----------+....+-----------+ >| Trailer | > +-----------+ > > > In the normal case 1 the size of L2 payload and IP-packet is the same, so > there is no problem. The question comes up in case 2, when not only the IP > packet but also other information like MPLS shim headers are included in the > L2 payload. You have to decide, if you count all payload bytes, or just the > IP packet size. If I understood Benoit right, Netflow v9 in this case counts > the whole payload, so not only the IP packet. > > But all the mentioned arguments are valid anywa, because the shim headers can vary a lot from section to section. (MPLS labels for example can not only be stored in shim headers but can for instance also be included in ATM headers itself: RFC 3035). So > I still would suggest to let the counters only count the bytes of the IP packets and not of the whole L2 payload, if they are different. If there is really the frequent need to count the whole L2 payload size, I would suggest a second set of counter > I.E.'s for the non-IP payload bytes in general (not technology depenend), which would be 0 in the usual case 1, and which could just be added to the basic counters if needed. If this need is not so common, it can be still defined as enterprise I.E.'s. > > Correct so far? > > > Regards, > > 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 Fri Jun 17 00:47:39 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19965 for ; Fri, 17 Jun 2005 00:47:38 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dj8fL-00006a-00 for ipfix-list@mil.doit.wisc.edu; Thu, 16 Jun 2005 23:41:15 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dj8fJ-00006V-00 for ipfix-info@net.doit.wisc.edu; Thu, 16 Jun 2005 23:41: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 0355D1BAC4D; Fri, 17 Jun 2005 06:41:09 +0200 (CEST) Date: Fri, 17 Jun 2005 06:41:08 +0200 From: Juergen Quittek To: ipfix-info@net.doit.wisc.edu Cc: Benoit Claise Subject: Re: [ipfix-info] simple editorial changes for the information model draft Message-ID: <7D6B1946E76937E55048F01E@[192.168.0.112]> In-Reply-To: <42A61588.1090705@cisco.com> References: <42A61588.1090705@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 Dear all, Here is the list of additional Information Elements that Benoit announced. I apologize for posting them late (after the announced end of WG last call). --On 6/7/2005 11:45 PM +0200 Benoit Claise wrote: > > I reviewed the information model draft one last time. > > For everybody interest, we discussed with Juergen a list of new I.E. > to be added. However, as we wanted to make the date of June 1st for > the last-call, and as these new I.E. can be considered as editorial > changes, these new I.E.s were not inserted in the current draft version. > These I.E. will be the subject of a separate email. The actual list of suggested new elements was much longer than posted below. We removed all suggestions where we had any doubt about usefulness or clarity and precision of the specification. Below please find first the list of suggested elements with suggested section numbers in the info model I-D, suggested Information Element identifier, and suggested name. The list is followed by a full description of all suggested elements. Please have a look at them and state your opinion on whether or not you think we should include them in the IPFIX info model. 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 section ID name 5.3.14 192 ipTimeToLive 5.3.15 193 nextHeaderIPv6 5.3.24 189 ipHeaderLength 5.3.25 190 packetLengthIPv4 5.3.26 191 payloadLengthIPv6 5.4.3 180 udpSourcePort 5.4.4 181 udpDestinationPort 5.4.5 182 tcpSourcePort 5.4.6 183 tcpDestinationPort 5.4.7 184 tcpSequenceNumber 5.4.8 185 tcpAcknowledgementNumber 5.4.9 186 tcpWindowSize 5.4.10 187 tcpUrgentPointer 5.4.11 188 tcpHeaderLength 5.4.13 176 icmpTypeIPv4 5.4.14 177 icmpCodeIPv4 5.4.16 178 icmpTypeIPv6 5.4.17 179 icmpCodeIPv6 5.5.9 196 mplsTopLabelTtl 5.5.10 197 mplsLabelStackSize 5.9.3 194 octetDeltaSumOfSquares 5.9.6 195 octetTotalSumOfSquares 5.9.17 174 postMCastPacketTotalCount 5.9.18 175 postMCastOctetTotalCount 5.3.14 ipTimeToLive Description: For IPv4, the value of the Information Element matches the value of the Time to Live field in the IPv4 packet header. For IPv6, the value of the Information Element matches the value of the Hop Limit field in the IPv6 packet header. Abstract Data Type: octet ElementId: 192 Status: current Units: hops Reference: See RFC 791 for the definition of the IPv4 Time to Live field. See RFC 2460 for the definition of the IPv6 Hop Limit field. 5.3.15 nextHeaderIPv6 Description: The value of the Next Header field of the IPv6 header. Abstract Data Type: octet ElementId: 193 Status: current Reference: See RFC 2460 for the definition of the IPv6 Next Header field. 5.3.24 ipHeaderLength Description: The length of the IP header. For IPv6, the value of this Information Element is 40. Abstract Data Type: octet ElementId: 189 Status: current Reference: See RFC 791 for the specification of the IPv4 header. See RFC 2460 for the specification of the IPv6 header. 5.3.25 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. 5.3.26 payloadLengthIPv6 Description: The length of the IPv6 payload, i.e., the rest of the packet following the IPv6 header, in octets. Note that any extension headers present are considered part of the payload, i.e., included in the length count. For payload lengths up to 65535, the value of this Information Element is given by the payload length field of the IPv6 header. For payload lengths greater than 65535, the value of this Information Element is given by the content of the IPv4 jumbo payload option. Abstract Data Type: unsigned32 ElementId: 191 Status: current Reference: See RFC 2460 for the specification of the IPv6 payload length. See RFC 2675 for the specification of the IPv6 jumbo payload length. 5.4.3 udpSourcePort Description: The source port identifier in the UDP header. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 180 Status: current Reference: See RFC 768 for the definition of the UDP source port field. Additional information on defined UDP port numbers can be found at http://www.iana.org/assignments/port-numbers. 5.4.4 udpDestinationPort Description: The destination port identifier in the UDP header. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 181 Status: current Reference: See RFC 768 for the definition of the UDP source port field. Additional information on defined UDP port numbers can be found at http://www.iana.org/assignments/port-numbers. 5.4.5 tcpSourcePort Description: The source port identifier in the TCP header. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 182 Status: current Reference: See RFC 793 for the definition of the TCP source port field. Additional information on defined TCP port numbers can be found at http://www.iana.org/assignments/port-numbers. 5.4.6 tcpDestinationPort Description: The destination port identifier in the TCP header. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 183 Status: current Reference: See RFC 793 for the definition of the TCP source port field. Additional information on defined TCP port numbers can be found at http://www.iana.org/assignments/port-numbers. 5.4.7 tcpSequenceNumber Description: The sequence number in the TCP header. Abstract Data Type: unsigned32 ElementId: 184 Status: current Reference: See RFC 793 for the definition of the TCP sequence number. 5.4.8 tcpAcknowledgementNumber Description: The acknowledgement number in the TCP header. Abstract Data Type: unsigned32 ElementId: 185 Status: current Reference: See RFC 793 for the definition of the TCP acknowledgement number. 5.4.9 tcpWindowSize Description: The window field in the TCP header. Abstract Data Type: unsigned16 ElementId: 186 Status: current Reference: See RFC 793 for the definition of the TCP window field. 5.4.10 tcpUrgentPointer Description: The urgent pointer in the TCP header. Abstract Data Type: unsigned16 ElementId: 187 Status: current Reference: See RFC 793 for the definition of the TCP urgent pointer. 5.4.11 tcpHeaderLength Description: The length of the TCP header. Abstract Data Type: unsigned16 ElementId: 188 Status: current Units: octets Reference: See RFC 793 for the definition of the TCP header. 5.4.13 icmpTypeIPv4 Description: Type of the IPv4 ICMP message. Abstract Data Type: octet Data Type Semantics: identifier ElementId: 176 Status: current Reference: See RFC 792 for a definition of the IPv4 ICMP type field. 5.4.14 icmpCodeIPv4 Description: Code of the IPv4 ICMP message. Abstract Data Type: octet Data Type Semantics: identifier ElementId: 177 Status: current Reference: See RFC 792 for a definition of the IPv4 ICMP code field. 5.4.16 icmpTypeIPv6 Description: Type of the IPv6 ICMP message. Abstract Data Type: octet Data Type Semantics: identifier ElementId: 178 Status: current Reference: See RFC 2463 for a definition of the IPv6 ICMP type field. 5.4.17 icmpCodeIPv6 Description: Code of the IPv6 ICMP message. Abstract Data Type: octet Data Type Semantics: identifier ElementId: 179 Status: current Reference: See RFC 2463 for a definition of the IPv6 ICMP code field. 5.5.9 mplsTopLabelTtl Description: The TTL field from the top MPLS label stack entry, i.e. the last label that was pushed. Abstract Data Type: unsigned32 ElementId: 196 Status: current Reference: See RFC 3032 for the specification of the TTL field. 5.5.10 mplsLabelStackSize Description: The size of the MPLS label stack. Abstract Data Type: unsigned32 ElementId: 197 Status: current Units: octets Reference: See RFC 3032 for the specification of the MPLS label stack. 5.9.3 octetDeltaSumOfSquares Description: The sum of the squared numbers of octets per incoming packet since the previous report (if any) for this Flow at the Observation Point. The number of octets include IP header(s) and IP payload. Abstract Data Type: unsigned64 ElementId: 194 Status: current 5.9.6 octetTotalSumOfSquares Description: The total sum of the squared numbers of octets in incoming packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point. The number of octets include IP header(s) and IP payload. Abstract Data Type: unsigned64 ElementId: 195 Status: current Units: octets 5.9.17 postMCastPacketTotalCount Description: The total number of outgoing multicast packets created for packets of this Flow by an adjacent multicast daemon since the Metering Process (re-)initialization. Note that typically not all of the created packets can be observed at the Observation Point of this Flow. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 174 Status: current Units: packets 5.9.18 postMCastOctetTotalCount Description: The total number of octets in outgoing multicast packets created for packets of this Flow by an adjacent multicast daemon since the Metering Process (re-)initialization. Note that typically not all of the created packets can be observed at the Observation Point of this Flow. The number of octets include IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 175 Units: octets -- 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 KnighMerla6705@gallin.com Fri Jun 17 23:22:36 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15509 for ; Fri, 17 Jun 2005 23:22:35 -0400 (EDT) Received: from dpc6714388246.direcpc.com ([67.143.88.246] helo=gallin.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DjTap-00056J-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 Jun 2005 22:02:00 -0500 From: "Merla Knight" To: "Ewart Lang" Subject: mega Need Offfr Date: Fri, 17 Jun 2005 22:01:48 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C573B2.11353600" 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?67.143.88.246 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C573B2.11353600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Musketeers to the prow!into the King's service under Charles II. It = occurred to him thatCahusac dived after them, his fellows with him. = Vengeance mustthis change in him, sought to reclaim him. Mademoiselle = d'Ogeron,Peter Blood, bachelor of medicine and several other things = besides,self-sufficient fellow, comparatively fresh from England, = whoseOn a cane day-bed that had been set for him on the quarter-deck,A = safe voyage home to you, Colonel, darling, said he insevere. The first = obligation of an officer is obedience. IIf you'll escort Miss Bishop = aboard my ship, I shall be obliged toCahusac mistook consideration for = dejection. Each of us carriessevere in character.in silence, then, = still without speaking, he went down the companion,A doctor's = privilege.turned the tables on these rascally Spaniards?Groaning and = sweating, urged on by the curses and even the whips ------=_NextPart_000_0047_01C573B2.11353600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to PiIlsOnI roomer ine Store

We are pleased to introduce ourselves as one of the = leading online pharmaceuticaI sh sarcoma = ops.

tactful Vl		R misapplication A		l deprecative A		acumen Ll
= underhanded AG	C	= drupaceous LIS VA	U caloric = M	and many other.

- Save leaguer = over 70%

- TotaI conf aweary = identiaIity

- Worldwide SHlPPlN = daytaler G

- Over 5 million custo dissatisfied mers in 150 countries

We do all we can to keep our customers fu mummery lly satisfied with our = services!

------=_NextPart_000_0047_01C573B2.11353600-- From KhajParen577@jlist.com Sun Jun 19 05:33:51 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20929 for ; Sun, 19 Jun 2005 05:33:51 -0400 (EDT) Received: from [201.139.76.206] (helo=jlist.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DjvqA-0002Wx-00 for ipfix-list@mil.doit.wisc.edu; Sun, 19 Jun 2005 04:11:42 -0500 From: "Khajag Parent" To: "Priscilla Lynn" Subject: iif you need it Date: Sun, 19 Jun 2005 04:11:46 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01C574AE.EAA8F500" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (dnsbl.njabl.org) open proxy -- 1109388219 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0046_01C574AE.EAA8F500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I know, said Blood. I am considering it - the profit that a manof Blood's = other captains would soon be unable to restrain their men.in a certain = awe of his brother, whose worth he had the wit tocommission on the spot, = and Bishop all but choked hisself with rageKing's commission if so be = him'd quit piracy and be o' gooda wall. He caught her by the wrist.Yet, = knowing all this, Captain Blood could preserve his calm inand pounded = her advancing enemy with a second broadside at closehad observed all the = odd particulars of the meeting of Captain BloodShe didn't pretend to = understand him, and she didn't make the attempt.Wolverstone replied in = kind and with interest. The officer passedhundred rebels should be = furnished for transportation to some of Hisand Ireland King, his supreme = and natural lord. It informed himan end to his own outlawry for his = alleged share in an earlierHis mind went back over the adventure of = yesterday, if of yesterdayabove his light eyes: ------=_NextPart_000_0046_01C574AE.EAA8F500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to PiIlsOnI impulsion ine Store

We are pleased to introduce ourselves as one of the = leading online ph throstle = armaceuticaI shops.

V podagric l		R Etruscan A		l bucolic A		L priory l
A = novelist G	C	= outspread LIS VA	= wordsplitting UM	and many other.

- Save over 7 misdeal = 0%

- TotaI co neoplasm = nfidentiaIity

- Worldwide SHlP = cormorant PlNG

- Over 5 million customers in 150 detection countries

We do all we quench = can to keep our customers fully satisfied with our = services!

------=_NextPart_000_0046_01C574AE.EAA8F500-- From majordomo@mil.doit.wisc.edu Sun Jun 19 20:49:15 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19317 for ; Sun, 19 Jun 2005 20:49:15 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DkA1G-0002fE-00 for ipfix-list@mil.doit.wisc.edu; Sun, 19 Jun 2005 19:20:06 -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 1DkA1E-0002f6-00 for ipfix-info@net.doit.wisc.edu; Sun, 19 Jun 2005 19:20:05 -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 j5K0K4V03719; Mon, 20 Jun 2005 02:20:04 +0200 (CEST) Received: from [10.21.112.40] (sjc-vpn2-40.cisco.com [10.21.112.40]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j5K0K1F24920; Mon, 20 Jun 2005 02:20:02 +0200 (CEST) Message-ID: <42B60BB1.5080800@cisco.com> Date: Mon, 20 Jun 2005 02:20:01 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] simple editorial changes for the information model draft References: <42A61588.1090705@cisco.com> <7D6B1946E76937E55048F01E@[192.168.0.112]> In-Reply-To: <7D6B1946E76937E55048F01E@[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 Juergen, Thanks for posting the list of I.E.s You forgot some I.E.s that we discussed and agreed upon, as far as I remember. 1. mplsTopLabelEXP Description: the top MPLS label experimental bits. Abstract Data Type: octet Data Type Semantics: flags ElementId: x Status: current Reference 2.1 in RFC3032 2. IPPayloadLength Description: Length of the IP payload in octets. Abstract Data Type: unsigned16 Data Type Semantics: quantity ElementId: x Status: current 3. mplsHeaderLength Description: The sum of the MPLS label stack entries Abstract Data Type: octet Data Type Semantics: quanity ElementId: x Status: current 4. mplsPayloadLength: Description: the payload after last MPLS label stack entry. Abstract Data Type: unsigned16 Data Type Semantics: quantity ElementId: x Status: current 5. IPTos Description: IP Type Of Service. Abstract Data Type: octet Data Type Semantics: identifier ElementId: x Status: current Note: this is the full 8-bit octet Note: 6. IPDSCP Description: IP DSCP. Abstract Data Type: octet Data Type Semantics: identifier ElementId: x Status: current Note: this is 6 bits of DSCP information 7. IPPrecedence Description: IP precedence. Abstract Data Type: octet Data Type Semantics: identifier ElementId: x Status: current Reference: RFC 791 Note: this is the 3 bits of precedence information 8. IPv4HeaderLength Description: IPv4 header length . Abstract Data Type: unsigned16 Data Type Semantics: quantity ElementId: x Status: current 9. IPv4Flags Description: IPv4 fragmentation flags. Abstract Data Type: 8bits Data Type Semantics: flags ElementId: x Status: current 10. IPv4Options Description: Bitmap representing which IPv4 options have been seen. Abstract Data Type: 32bits Data Type Semantics: flags ElementId: x Status: current Reference: "flags" from the IP header, RFC791 11. TCPOptions Description: TCP options field Abstract Data Type: 32bits Data Type Semantics: flags ElementId: x Status: current Reference: RFC 793 Here is one typo: 5.3.26 payloadLengthIPv6 Description: The length of the IPv6 payload, i.e., the rest of the packet following the IPv6 header, in octets. Note that any extension headers present are considered part of the payload, i.e., included in the length count. For payload lengths up to 65535, the value of this Information Element is given by the payload length field of the IPv6 header. For payload lengths greater than 65535, the value of this Information Element is given by the content of the IPv4 jumbo payload option. "IPv6" ----------^^^^ Finally, one comment regarding the two postMCastPacketTotalCount and postMCastOctetTotalCount I.E. - is it important to specify "created for packets of this Flow by an adjacent multicast daemon" - regarding to "Note that typically not all of the created packets can be observed at the Observation Point of this Flow.", I'm not sure it makes sense. What does "created" mean? If you want to say that all IPFIX device wide multicast packets can't be observed, I don't think this is relevant as the observation point is the interface. This is even confusing. Regards, Benoit. > Dear all, > > Here is the list of additional Information Elements that Benoit > announced. > I apologize for posting them late (after the announced end of WG last > call). > > --On 6/7/2005 11:45 PM +0200 Benoit Claise wrote: > >> >> I reviewed the information model draft one last time. >> >> For everybody interest, we discussed with Juergen a list of new I.E. >> to be added. However, as we wanted to make the date of June 1st for >> the last-call, and as these new I.E. can be considered as editorial >> changes, these new I.E.s were not inserted in the current draft version. >> These I.E. will be the subject of a separate email. > > > The actual list of suggested new elements was much longer than posted > below. We removed all suggestions where we had any doubt about > usefulness > or clarity and precision of the specification. > > Below please find first the list of suggested elements with suggested > section numbers in the info model I-D, suggested Information Element > identifier, and suggested name. The list is followed by a full > description > of all suggested elements. > > Please have a look at them and state your opinion on whether or not you > think we should include them in the IPFIX info model. > > 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 Sun Jun 19 21:25:11 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21214 for ; Sun, 19 Jun 2005 21:25:11 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DkAhp-0004Ea-00 for ipfix-list@mil.doit.wisc.edu; Sun, 19 Jun 2005 20:04:05 -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 1DkAho-0004EV-00 for ipfix-protocol@net.doit.wisc.edu; Sun, 19 Jun 2005 20:04:04 -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 j5K143h07025 for ; Mon, 20 Jun 2005 03:04:03 +0200 (CEST) Received: from [10.21.112.40] (sjc-vpn2-40.cisco.com [10.21.112.40]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j5K142F08796 for ; Mon, 20 Jun 2005 03:04:03 +0200 (CEST) Message-ID: <42B61602.8090209@cisco.com> Date: Mon, 20 Jun 2005 03:04:02 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] new version of the IPFIX protocol draft:draft-ietf-ipfix-protocol-16.txt, after last-call Content-Type: multipart/alternative; boundary="------------050003070303060802010603" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------050003070303060802010603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, During this last-call period, I haven't received any comments. So I guess this is fine with everybody. I just posted a new version of the IPFIX protocol draft, which includes editorial changes to keep the definitions in line with [IPFIX-ARCH]. (See http://ipfix.doit.wisc.edu/archive/2823.html) Regards, Benoit. --------------050003070303060802010603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

During this last-call period, I haven't received any comments. So I guess this is fine with everybody.
I just posted a new version of the IPFIX protocol draft, which includes editorial changes to keep the definitions in line with [IPFIX-ARCH].
(See http://ipfix.doit.wisc.edu/archive/2823.html)

Regards, Benoit.

--------------050003070303060802010603-- -- 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 ShelbyChrista7943@jurikres.com Mon Jun 20 03:04:10 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00067 for ; Mon, 20 Jun 2005 03:04:09 -0400 (EDT) Received: from lns-vlq-41-str-82-252-35-43.adsl.proxad.net ([82.252.35.43] helo=jurikres.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DkG9k-0000tZ-00 for ipfix-list@mil.doit.wisc.edu; Mon, 20 Jun 2005 01:53:17 -0500 From: "Christabel Shelby" To: "Gyuri Stover" Subject: Really Worrks Wonder Date: Mon, 20 Jun 2005 01:53:20 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C57564.BE4FB000" 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_0000_01C57564.BE4FB000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, their muzzles thrusting through the open ports, precisely as theawoke in = her an uplifting sense of pride that took no account ofAs long as full = sensibility remained, Jeremy Pitt had made no sound.wisely. Because of = that he bade me leave his ship, and had me putinsistent.lay there until = daybreak. Then Blood went forward alone, and withof slipping a couple = of feet of steel into your vitals. When Iglance at the swarm of fierce, = half-naked fellows lounging in asuddenly revealed its formidable and = utterly unsuspected strength.Mr. James Nuttall made all speed, = regardless of the heat, in hisattention until that moment had been all = on the other side. AndFor he knew, as all Bridgewater knew and had = known now for someIn the name of humanity, now.... Mr. Blood was = beginning.It startled him to discover that the thought that he had = incurredthat one lady, detached from the general throng, was placing = someof colour which his question had brought to Miss Bishop's cheeks ------=_NextPart_000_0000_01C57564.BE4FB000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to MedzOnline Sho pigmentary p

We are pleased to introduce ourselves as one of the = Ieading online pharmaceuticaI shop = legitimize s.

directional V		bertha R		palpable AL		university Ll
l = tessellated AG	A C = clarinet l	IS = retrench VA	U frugal = M	and many other.

- Save o somnambulism = ver 75%

- Total apiculture = confidentiaIity

- Worldwide SHlPPlN = extract G

- Over 5 miIl nighty = ion customers in 150 countries

humanly Have = a nice day!

------=_NextPart_000_0000_01C57564.BE4FB000-- From majordomo@mil.doit.wisc.edu Mon Jun 20 04:04:51 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03800 for ; Mon, 20 Jun 2005 04:04:51 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DkH6v-0002fl-00 for ipfix-list@mil.doit.wisc.edu; Mon, 20 Jun 2005 02:54:25 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DkH6u-0002fe-00 for ipfix-info@net.doit.wisc.edu; Mon, 20 Jun 2005 02:54:24 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2005 09:54:23 +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 j5K7sJDg008527; Mon, 20 Jun 2005 09:54:20 +0200 (MEST) Received: from cisco.com (ams-clip-vpn-dhcp476.cisco.com [10.61.65.220]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA20387; Mon, 20 Jun 2005 08:54:18 +0100 (BST) Message-ID: <42B6762C.6090706@cisco.com> Date: Mon, 20 Jun 2005 08:54:20 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] simple editorial changes for the information model draft References: <42A61588.1090705@cisco.com> <7D6B1946E76937E55048F01E@[192.168.0.112]> <42B60BB1.5080800@cisco.com> In-Reply-To: <42B60BB1.5080800@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > 3. mplsHeaderLength > Description: The sum of the MPLS label stack entries > Abstract Data Type: octet > Data Type Semantics: quanity > ElementId: x > Status: current Do you mean mplsStackDepth, or do you mean mplsStackDepth * sizeof(labelStackEntry)? If you mean mplsStackDepth, then we should change the name. In looking at RFC3031, I notice that we have a problem with the mplsLabelStackEntryx set of IEs. We say: 5.5.9 mplsLabelStackEntry1 Description: The label, exp and s fields from the outermost MPLS label stack entry, i.e. the last label that was pushed. but RFC3031 says 3.9. The Label Stack If a packet's label stack is of depth m, we refer to the label at the bottom of the stack as the level 1 label, to the label above it (if such exists) as the level 2 label, and to the label at the top of the stack as the level m label. Now I think that what we have defined is consistent with the Netflow spec, but is unfortunately this is inconsistant with the notation used in the MPLS architecture. Maybe all that is needed is a note in the draft, but I think that we need to do something. - Stewart -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Jun 20 09:39:33 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28093 for ; Mon, 20 Jun 2005 09:39:33 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DkM6F-0007Hu-00 for ipfix-list@mil.doit.wisc.edu; Mon, 20 Jun 2005 08:14:03 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DkM6E-0007Hn-00 for ipfix-info@net.doit.wisc.edu; Mon, 20 Jun 2005 08:14:02 -0500 Received: from [192.168.0.112] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8EE821BAC4D; Mon, 20 Jun 2005 15:13:59 +0200 (CEST) Date: Mon, 20 Jun 2005 15:14:08 +0200 From: Juergen Quittek To: Stewart Bryant , Benoit Claise Cc: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] simple editorial changes for the information model draft Message-ID: <61CA9E7C726418D70C227ECC@[10.1.1.171]> In-Reply-To: <42B6762C.6090706@cisco.com> References: <42A61588.1090705@cisco.com> <7D6B1946E76937E55048F01E@[192.168.0.112]> <42B60BB1.5080800@cisco.com> <42B6762C.6090706@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 Stewart, --On 6/20/2005 8:54 AM +0100 Stewart Bryant wrote: > >> 3. mplsHeaderLength >> Description: The sum of the MPLS label stack entries >> Abstract Data Type: octet >> Data Type Semantics: quanity >> ElementId: x >> Status: current > > Do you mean mplsStackDepth, or do you mean > mplsStackDepth * sizeof(labelStackEntry)? > > If you mean mplsStackDepth, then we should change the name. It is already contained in the list I posted. I renamed it to mplsLabelStackSize and specified 'octets' as unit. > In looking at RFC3031, I notice that we have a problem > with the mplsLabelStackEntryx set of IEs. We say: > > 5.5.9 mplsLabelStackEntry1 > > Description: > The label, exp and s fields from the outermost MPLS label stack > entry, i.e. the last label that was pushed. > > > but RFC3031 says > > 3.9. The Label Stack > > > > If a packet's label stack is of depth m, we refer to the label at the > bottom of the stack as the level 1 label, to the label above it (if > such exists) as the level 2 label, and to the label at the top of the > stack as the level m label. > > Now I think that what we have defined is consistent with the Netflow > spec, but is unfortunately this is inconsistant with the notation > used in the MPLS architecture. Maybe all that is needed is a note > in the draft, but I think that we need to do something. What about renaming mplsLabelStackEntry1 to mplsTopLabelEntry? The others (mplsLabelStackEntry2 - mplsLabelStackEntry10) are defined recursively based on mplsLabelStackEntry1. > - Stewart 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 Jun 20 10:22:52 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03580 for ; Mon, 20 Jun 2005 10:22:52 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DkN0S-0001vm-00 for ipfix-list@mil.doit.wisc.edu; Mon, 20 Jun 2005 09:12:08 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DkN0Q-0001vg-00 for ipfix-info@net.doit.wisc.edu; Mon, 20 Jun 2005 09:12:07 -0500 Received: from [192.168.0.112] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 2FA261BAC4D; Mon, 20 Jun 2005 16:12:06 +0200 (CEST) Date: Mon, 20 Jun 2005 16:12:15 +0200 From: Juergen Quittek To: Benoit Claise Cc: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] simple editorial changes for the information model draft Message-ID: <17525CB54BE335D4685E9E41@[10.1.1.171]> In-Reply-To: <42B60BB1.5080800@cisco.com> References: <42A61588.1090705@cisco.com> <7D6B1946E76937E55048F01E@[192.168.0.112]> <42B60BB1.5080800@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, This is just a reply to you. The mailing list is not yet included. I am sorry for not posting the full list. Accidentally, I omitted ipTypeOfService, ipDscp, and ipPrecedence. Wit a bit more elaborated descriptions, their proposed specification is 5.3.16 ipClassOfService Description: For IPv4 packets, this is the value of the TOS field in the IPv4 packet header, for IPv6 packets, this is the value of the Traffic Class field in the IPv6 packet header. Abstract Data Type: octet Data Type Semantics: identifier ElementId: 194 Status: current Reference: See RFC 791 for the definition of the IPv4 TOS field. See RFC 2460 for the definition of the IPv6 Traffic Class field. 5.3.17 ipDiffServeCodePoint Description: The value of a Differentiated Services Code Point (DSCP). DSCP values are encoded in the first 6 bits of the IPv4 TOS field or the IPv6 Traffic class field, respectively. For a particular Flow or packet, this Information Element may have the same value as Information Element ipClassOfService except that the bits that are not used by the Differentiated Services Field for specifying a DiffServ Code Point (DSCP) are to be ignored. Note that ignoring these bits may be relevant when the DSCP serves as Flow Key. Abstract Data Type: octet Data Type Semantics: identifier ElementId: 195 Status: current Reference: See RFC 791 for the definition of the IPv4 TOS field. See RFC 2460 for the definition of the IPv6 Traffic Class field. See RFC 2474 for the definition of the Differentiated Services Field. 5.3.18 ipPrecedence Description: The value of the IP Precedence. IP Precedence values are encoded in the first 3 bits of the IPv4 TOS field or the IPv6 Traffic class field, respectively. For a particular Flow or packet, this Information Element may have the same value as Information Element ipClassOfService except that the last 5 bits are to be ignored. Note that ignoring these bits may be relevant when the IP Precedence serves as Flow Key. Abstract Data Type: octet Data Type Semantics: identifier ElementId: 196 Status: current Reference: See RFC 791 for the definition of the IPv4 TOS field and the IP Precedence. See RFC 2460 for the definition of the IPv6 Traffic Class field. 5.3.27 fragmentFlagsIPv4 Description: The value of the fragmentation bits in the IPv4 packet header. Bit 0: reserved, must be zero. Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment. Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments. Bits 3-7: (DC) Don't Care, value is irrelevant. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | | D | M | D | D | D | D | D | | 0 | F | F | C | C | C | C | C | +---+---+---+---+---+---+---+---+ Abstract Data Type: octet Data Type Semantics: flags ElementId: 197 Status: current Reference: See RFC 791 for the specification of the IPv4 fragment flags. For the remaining Element you list I ran into open issues when specifying them, particularly when reading the references to be included. Please find comments inline below. --On 6/20/2005 2:20 AM +0200 Benoit Claise wrote: > Hi Juergen, > > Thanks for posting the list of I.E.s > > You forgot some I.E.s that we discussed and agreed upon, as far as I remember. > > 1. mplsTopLabelEXP > Description: the top MPLS label experimental bits. > Abstract Data Type: octet > Data Type Semantics: flags > ElementId: x > Status: current > Reference 2.1 in RFC3032 1. These flags are already included in object mplsLabelStackEntry1. 2. I could not find references to any use of these experimental bits. RFC 3032 just says they are reserved. Do we have an application scenario where these are used? > 2. IPPayloadLength > Description: Length of the IP payload in octets. > Abstract Data Type: unsigned16 > Data Type Semantics: quantity > ElementId: x > Status: current The definitions of payload are different for IPv4 and IPv6. For IPv4 there is no header field indicating the payload length, we just have the 'total Length' header field. The IPv4 actual payload length is the difference between the 'Total Length' and the actual header length. The IPv4 header length is variable, because IPv4 optinons are included in the header. For IPv6 there is a 'Payload Length' field in the header :-), but the actual payload length may differ from the value of this field :-( For Jumbograms the value of the 'Payload Length' header field is zero and the actual value is specified in an extensions header. IPv4: actual payload length = packet length - base header length - total options length IPv6: actual payload length = packet length - base header length > 3. mplsHeaderLength > Description: The sum of the MPLS label stack entries > Abstract Data Type: octet > Data Type Semantics: quanity > ElementId: x > Status: current This is included. RFCs 3031/3032 rather call it MPLS label stack than MPLS header. That's why I renamed it to mplsLabelStackSize. > 4. mplsPayloadLength: Description: the payload after last MPLS label stack entry. > Abstract Data Type: unsigned16 > Data Type Semantics: quantity > ElementId: x > Status: current This is the IP packet length. It should be called accordingly. > 5. IPTos > Description: IP Type Of Service. > Abstract Data Type: octet > Data Type Semantics: identifier > ElementId: x > Status: current > > Note: this is the full 8-bit octet > Note: I really missed this one. Please see above. > 6. IPDSCP > Description: IP DSCP. > Abstract Data Type: octet > Data Type Semantics: identifier > ElementId: x > Status: current > Note: this is 6 bits of DSCP information See above. > 7. IPPrecedence > Description: IP precedence. > Abstract Data Type: octet > Data Type Semantics: identifier > ElementId: x > Status: current > Reference: RFC 791 > Note: this is the 3 bits of precedence information See above. > 8. IPv4HeaderLength > Description: IPv4 header length . > Abstract Data Type: unsigned16 > Data Type Semantics: quantity > ElementId: x > Status: current We have the IP header length. > 9. IPv4Flags > Description: IPv4 fragmentation flags. > Abstract Data Type: 8bits > Data Type Semantics: flags > ElementId: x > Status: current I really missed this one. Please see above. > 10. IPv4Options > Description: Bitmap representing which IPv4 options have been seen. > Abstract Data Type: 32bits > Data Type Semantics: flags > ElementId: x > Status: current > Reference: "flags" from the IP header, RFC791 RFC 791 specifies 8 different options: 1. End of Option list 2. No Operation 2. Security 4. Loose Source Routing 5. Strict Source Routing 6. Record Route 7. Stream ID 8. Internet Timestamp Options 1 and 2 do not contain real information, they just serve syntactical and alignment purposes. Shall we include them also or limit the option list to the remaining six options. Are there more options defined anywhere outside of RFC 791? Do we really need and unsigned32? For these 6-8 options described above an octet or unsigned 16 would already be sufficient. > 11. TCPOptions > Description: TCP options field > Abstract Data Type: 32bits > Data Type Semantics: flags > ElementId: x > Status: current > Reference: RFC 793 A single TCP packet may contain more than one option. The list of allowed options is maintained by IANA at . The list already contains 26 entries and TCPM is currently working on further options. Therefore, unsigned32 does not appear to be appropriate, because it probaly will become too small in the very near future. We should at least use an unsigned64 data type here. we can use the IANA-assigned option number as indicator for the position in the bit field array for the respective TCP option. > Here is one typo: > 5.3.26 payloadLengthIPv6 > > Description: > The length of the IPv6 payload, i.e., the rest of the packet > following the IPv6 header, in octets. Note that any extension > headers present are considered part of the payload, i.e., > included in the length count. For payload lengths up to 65535, > the value of this Information Element is given by the payload > length field of the IPv6 header. For payload lengths greater than > 65535, the value of this Information Element is given by the > content of the IPv4 jumbo payload option. > > "IPv6" ----------^^^^ Fixed. > > > Finally, one comment regarding the two postMCastPacketTotalCount and > postMCastOctetTotalCount I.E. > - is it important to specify "created for packets of this Flow by an adjacent > multicast daemon" > - regarding to "Note that typically not all of the created packets can be > observed at the Observation Point of this Flow.", I'm not sure it makes sense. > What does "created" mean? > If you want to say that all IPFIX device wide multicast packets can't be observed, > I don't think this is relevant as the observation point is the interface. > This is even confusing. I have no problem with replacing "created" by , for example, "sent". Do you have another suggestion? > 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 >> Dear all, >> >> Here is the list of additional Information Elements that Benoit >> announced. >> I apologize for posting them late (after the announced end of WG last >> call). >> >> --On 6/7/2005 11:45 PM +0200 Benoit Claise wrote: >> >>> >>> I reviewed the information model draft one last time. >>> >>> For everybody interest, we discussed with Juergen a list of new I.E. >>> to be added. However, as we wanted to make the date of June 1st for >>> the last-call, and as these new I.E. can be considered as editorial >>> changes, these new I.E.s were not inserted in the current draft version. >>> These I.E. will be the subject of a separate email. >> >> >> The actual list of suggested new elements was much longer than posted >> below. We removed all suggestions where we had any doubt about >> usefulness >> or clarity and precision of the specification. >> >> Below please find first the list of suggested elements with suggested >> section numbers in the info model I-D, suggested Information Element >> identifier, and suggested name. The list is followed by a full >> description >> of all suggested elements. >> >> Please have a look at them and state your opinion on whether or not you >> think we should include them in the IPFIX info model. >> >> 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 Mon Jun 20 11:19:23 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09271 for ; Mon, 20 Jun 2005 11:19:22 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DkNw4-0003qm-00 for ipfix-list@mil.doit.wisc.edu; Mon, 20 Jun 2005 10:11:40 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DkNw3-0003qh-00 for ipfix-info@net.doit.wisc.edu; Mon, 20 Jun 2005 10:11:39 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2005 17:11:39 +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 j5KFBZDg023464; Mon, 20 Jun 2005 17:11:36 +0200 (MEST) Received: from cisco.com (ams-clip-vpn-dhcp476.cisco.com [10.61.65.220]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA01637; Mon, 20 Jun 2005 16:11:34 +0100 (BST) Message-ID: <42B6DCA6.5080108@cisco.com> Date: Mon, 20 Jun 2005 16:11:34 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: Benoit Claise , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] simple editorial changes for the information model draft References: <42A61588.1090705@cisco.com> <7D6B1946E76937E55048F01E@[192.168.0.112]> <42B60BB1.5080800@cisco.com> <42B6762C.6090706@cisco.com> <61CA9E7C726418D70C227ECC@[10.1.1.171]> In-Reply-To: <61CA9E7C726418D70C227ECC@[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 Quittek wrote: > Stewart, > > --On 6/20/2005 8:54 AM +0100 Stewart Bryant wrote: > >> >>> 3. mplsHeaderLength >>> Description: The sum of the MPLS label stack entries >>> Abstract Data Type: octet >>> Data Type Semantics: quanity >>> ElementId: x >>> Status: current >> >> >> Do you mean mplsStackDepth, or do you mean >> mplsStackDepth * sizeof(labelStackEntry)? >> >> If you mean mplsStackDepth, then we should change the name. > > > It is already contained in the list I posted. > I renamed it to mplsLabelStackSize and specified 'octets' as unit. Sorry to labour the point, but surely number of LSEs is what is important, not number of octets. > >> In looking at RFC3031, I notice that we have a problem >> with the mplsLabelStackEntryx set of IEs. We say: >> >> 5.5.9 mplsLabelStackEntry1 >> >> Description: >> The label, exp and s fields from the outermost MPLS label stack >> entry, i.e. the last label that was pushed. >> >> >> but RFC3031 says >> >> 3.9. The Label Stack >> >> >> >> If a packet's label stack is of depth m, we refer to the label at the >> bottom of the stack as the level 1 label, to the label above it (if >> such exists) as the level 2 label, and to the label at the top of the >> stack as the level m label. >> >> Now I think that what we have defined is consistent with the Netflow >> spec, but is unfortunately this is inconsistant with the notation >> used in the MPLS architecture. Maybe all that is needed is a note >> in the draft, but I think that we need to do something. > > > What about renaming mplsLabelStackEntry1 to mplsTopLabelEntry? > The others (mplsLabelStackEntry2 - mplsLabelStackEntry10) are defined > recursively based on mplsLabelStackEntry1. > That would work for me. - Stewart >> - Stewart > > > 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 Mon Jun 20 12:25:40 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14910 for ; Mon, 20 Jun 2005 12:25:40 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DkOt3-0006YD-00 for ipfix-list@mil.doit.wisc.edu; Mon, 20 Jun 2005 11:12:37 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DkOt1-0006Y8-00 for ipfix-info@net.doit.wisc.edu; Mon, 20 Jun 2005 11:12:35 -0500 Received: from [192.168.0.112] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 6CFC91BAC4D; Mon, 20 Jun 2005 18:12:33 +0200 (CEST) Date: Mon, 20 Jun 2005 18:12:42 +0200 From: Juergen Quittek To: Stewart Bryant Cc: Benoit Claise , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] simple editorial changes for the information model draft Message-ID: <0813BD4D17367B531176CEF5@[10.1.1.171]> In-Reply-To: <42B6DCA6.5080108@cisco.com> References: <42A61588.1090705@cisco.com> <7D6B1946E76937E55048F01E@[192.168.0.112]> <42B60BB1.5080800@cisco.com> <42B6762C.6090706@cisco.com> <61CA9E7C726418D70C227ECC@[10.1.1.171]> <42B6DCA6.5080108@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 --On 6/20/2005 4:11 PM +0100 Stewart Bryant wrote: > > > Juergen Quittek wrote: > >> Stewart, >> >> --On 6/20/2005 8:54 AM +0100 Stewart Bryant wrote: >> >>> >>>> 3. mplsHeaderLength >>>> Description: The sum of the MPLS label stack entries >>>> Abstract Data Type: octet >>>> Data Type Semantics: quanity >>>> ElementId: x >>>> Status: current >>> >>> >>> Do you mean mplsStackDepth, or do you mean >>> mplsStackDepth * sizeof(labelStackEntry)? >>> >>> If you mean mplsStackDepth, then we should change the name. >> >> >> It is already contained in the list I posted. >> I renamed it to mplsLabelStackSize and specified 'octets' as unit. > > Sorry to labour the point, but surely number of LSEs > is what is important, not number of octets. What about just adding mplsLabelStackDepth? Then we have both cases covered. >> >>> In looking at RFC3031, I notice that we have a problem >>> with the mplsLabelStackEntryx set of IEs. We say: >>> >>> 5.5.9 mplsLabelStackEntry1 >>> >>> Description: >>> The label, exp and s fields from the outermost MPLS label stack >>> entry, i.e. the last label that was pushed. >>> >>> >>> but RFC3031 says >>> >>> 3.9. The Label Stack >>> >>> >>> >>> If a packet's label stack is of depth m, we refer to the label at the >>> bottom of the stack as the level 1 label, to the label above it (if >>> such exists) as the level 2 label, and to the label at the top of the >>> stack as the level m label. >>> >>> Now I think that what we have defined is consistent with the Netflow >>> spec, but is unfortunately this is inconsistant with the notation >>> used in the MPLS architecture. Maybe all that is needed is a note >>> in the draft, but I think that we need to do something. >> >> >> What about renaming mplsLabelStackEntry1 to mplsTopLabelEntry? >> The others (mplsLabelStackEntry2 - mplsLabelStackEntry10) are defined >> recursively based on mplsLabelStackEntry1. >> > > That would work for me. OK, I will apply the change if no one else objects. > - Stewart > 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 >>> - Stewart >> >> >> 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 Mon Jun 20 13:16:05 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19878 for ; Mon, 20 Jun 2005 13:16:05 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DkPn9-00010W-00 for ipfix-list@mil.doit.wisc.edu; Mon, 20 Jun 2005 12:10: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 1DkPn8-00010R-00 for ipfix-info@net.doit.wisc.edu; Mon, 20 Jun 2005 12:10:34 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2005 19:10:33 +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 j5KHAUDg029706; Mon, 20 Jun 2005 19:10:30 +0200 (MEST) Received: from cisco.com (ams-clip-vpn-dhcp476.cisco.com [10.61.65.220]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA14672; Mon, 20 Jun 2005 18:10:29 +0100 (BST) Message-ID: <42B6F885.6060300@cisco.com> Date: Mon, 20 Jun 2005 18:10:29 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: Benoit Claise , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] simple editorial changes for the information model draft References: <42A61588.1090705@cisco.com> <7D6B1946E76937E55048F01E@[192.168.0.112]> <42B60BB1.5080800@cisco.com> <42B6762C.6090706@cisco.com> <61CA9E7C726418D70C227ECC@[10.1.1.171]> <42B6DCA6.5080108@cisco.com> <0813BD4D17367B531176CEF5@[10.1.1.171]> In-Reply-To: <0813BD4D17367B531176CEF5@[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 Quittek wrote: > > > --On 6/20/2005 4:11 PM +0100 Stewart Bryant wrote: > >> >> >> Juergen Quittek wrote: >> >>> Stewart, >>> >>> --On 6/20/2005 8:54 AM +0100 Stewart Bryant wrote: >>> >>>> >>>>> 3. mplsHeaderLength >>>>> Description: The sum of the MPLS label stack entries >>>>> Abstract Data Type: octet >>>>> Data Type Semantics: quanity >>>>> ElementId: x >>>>> Status: current >>>> >>>> >>>> >>>> Do you mean mplsStackDepth, or do you mean >>>> mplsStackDepth * sizeof(labelStackEntry)? >>>> >>>> If you mean mplsStackDepth, then we should change the name. >>> >>> >>> >>> It is already contained in the list I posted. >>> I renamed it to mplsLabelStackSize and specified 'octets' as unit. >> >> >> Sorry to labour the point, but surely number of LSEs >> is what is important, not number of octets. > > > What about just adding mplsLabelStackDepth? > Then we have both cases covered. OK Stewart > >>> >>>> In looking at RFC3031, I notice that we have a problem >>>> with the mplsLabelStackEntryx set of IEs. We say: >>>> >>>> 5.5.9 mplsLabelStackEntry1 >>>> >>>> Description: >>>> The label, exp and s fields from the outermost MPLS label stack >>>> entry, i.e. the last label that was pushed. >>>> >>>> >>>> but RFC3031 says >>>> >>>> 3.9. The Label Stack >>>> >>>> >>>> >>>> If a packet's label stack is of depth m, we refer to the label >>>> at the >>>> bottom of the stack as the level 1 label, to the label above it (if >>>> such exists) as the level 2 label, and to the label at the top >>>> of the >>>> stack as the level m label. >>>> >>>> Now I think that what we have defined is consistent with the Netflow >>>> spec, but is unfortunately this is inconsistant with the notation >>>> used in the MPLS architecture. Maybe all that is needed is a note >>>> in the draft, but I think that we need to do something. >>> >>> >>> >>> What about renaming mplsLabelStackEntry1 to mplsTopLabelEntry? >>> The others (mplsLabelStackEntry2 - mplsLabelStackEntry10) are defined >>> recursively based on mplsLabelStackEntry1. >>> >> >> That would work for me. > > > OK, I will apply the change if no one else objects. > >> - Stewart >> > > 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 MarlenaGru2336@gallet.com Tue Jun 21 02:39:55 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16300 for ; Tue, 21 Jun 2005 02:39:55 -0400 (EDT) Received: from host81-134-207-89.in-addr.btopenworld.com ([81.134.207.89] helo=gallet.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DkbzO-0007Ie-00 for ipfix-list@mil.doit.wisc.edu; Tue, 21 Jun 2005 01:12:02 -0500 From: "Marlena Gruber" To: "Ata Cerda" Subject: Check thiss out Date: Tue, 21 Jun 2005 01:12:07 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01C57628.26B39580" 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?81.134.207.89 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0054_01C57628.26B39580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, This council was met to determine what should be done with theis all that I = can give you. If by the time those sands have runguards, his momentary = truculence utterly spent.The half-drunken Spaniards, their laughter = suddenly quenched, thethe fortitude of a fatalist.you had better, said = that composed young lady, whereupon with aa light pleasantry by contrast = with the death to which your lordshipMr. Blood turned to face him, and = over that swarthy countenancethem in his cabin with great urbanity. = Urbanely he desired to havehim. I'll confess I thought it rash of his = lordship to accept thebedgown and slippers as he was. But the doctor = eluded that tooanother messenger will do as well, and another hostage = aboard - asmulberry satin laced with gold, whose wizened, yellow, = ratherBut, my friend, I did not agree so much.prisoners who, chained in = pairs, were marched from Bridgewater toexplained himself. ------=_NextPart_000_0054_01C57628.26B39580 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to MedzOnline admittedly Shop

We are pleased to introduce ourselves as one of the = Ieading online pharma compeer = ceuticaI shops.

triphthong V		fifties R		A infighting L		measurable Ll
lA = biliary G	A = affect Cl	IS V = brabble A	U drizzle = M	and many other.

- Save ventilation = over 75%

- Total confident = profitable iaIity

- Worldwide SHlPPl = morphology NG

- Over 5 miIlion custom dichogamy ers in 150 countries

Have a n pitchdark = ice day!

------=_NextPart_000_0054_01C57628.26B39580-- From Layne5890@jkpg.com Wed Jun 22 02:52:45 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05311 for ; Wed, 22 Jun 2005 02:52:39 -0400 (EDT) Received: from 61-229-196-159.dynamic.hinet.net ([61.229.196.159] helo=jkpg.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Dkyk2-0000R8-00 for ipfix-list@mil.doit.wisc.edu; Wed, 22 Jun 2005 01:29:45 -0500 From: "Donnchadh Layne" To: "Darach Arroyo" Subject: Workks Wonders Date: Wed, 22 Jun 2005 01:29:46 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_01C576F3.C853E900" 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_005C_01C576F3.C853E900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Colonel Bishop looked up. His great face was yellow and seemed ininjured = English seamen. Indeed, had the wishes of some of theseHow could I in = honesty have detained them? It was in the bargain.Here, then, is the = plan I now propose.sickness broke out amongst them, of which eleven = died. AmongstDon Esteban expressed his last lingering = uneasiness:followed her, his mind too full of Captain Blood to be = concernedhimself. Blows were thundering upon the door of his house, and = asatin small-clothes and fine shoes of Cordovan leather. He wasColonel = Bishop was of another opinion. In his view there was aas they filtered = from the upper to the lower bulb. And what timeKIRKE'S DRAGOONShad been = conducted.wonder. And who may be King William, and of what may he be = King?Beyond locking them all into that stockade at night, there was = nokilling. At daybreak pack the Spaniards into a boat with a keg of ------=_NextPart_000_005C_01C576F3.C853E900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to MedzOnline emigrate Shop

We are pleased to introduce ourselves as one of the = Ieading online ph stabling = armaceuticaI shops.

legislature V		turnpike R		pisciculturist AL		L dressy l
l wayward = AG	A = undershot Cl	IS V = pitchfork A	coiffure = UM	and many other.

- Save over 75 engulf = %

- Total confidentiaI = cartridge ity

- Worldwide SHlPPlN = typographer G

- Over 5 miIlion custome stanchion rs in 150 countries

Have a quininize = nice day!

------=_NextPart_000_005C_01C576F3.C853E900-- From HagarKend_5985@futren.com Thu Jun 23 02:38:53 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08383 for ; Thu, 23 Jun 2005 02:38:53 -0400 (EDT) Received: from [218.61.3.12] (helo=futren.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DlKx5-0001XX-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Jun 2005 01:12:40 -0500 From: "Hagar Kendrick" To: "Salacia Farris" Subject: Meddz 2 u Date: Thu, 23 Jun 2005 01:12:41 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01C577BA.8FCB1280" 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_004E_01C577BA.8FCB1280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, He was turning again to the helmsman below, when Blood's gripleft behind. = It was because of these that they must go cautiouslyIn the name of = humanity, sir! said he, on a note of anger. Thisoblivious of all else. = And yet in those moments vital things werefrom her main truck in the = morning breeze, the gilded portholes inreceive his answer. He accord us = this on the understanding that weThen let some one buy the prisoners who = has.family matter.in your eyes! Don't I know what you are thinking? If = you couldSanto Nino, and Cahusac had narrowly escaped hanging merely = thatpity's sake, Arabella.deal with you out of hand for piracy as you = deserve. But youhas the megrims.was very far from gross, did not = possess the necessary degree ofcompanion.enterprise offers no particular = difficulty; it may be speedily ------=_NextPart_000_004E_01C577BA.8FCB1280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to = plastic MedzOnline Shop

We are pleased to introduce ourselves as one of the = Ieading online pharmaceuticaI turbidity = shops.

admiral V		convolute R		depreciatingly AL		Newfoundland Ll
lA = foretooth G	A C = slummock l	IS = slanderous VA	U = epicurism M	and many other.

- Sa medullary = ve over 75%

- Total confidentiaIi = thremmatology ty

- Worldwide = secateur SHlPPlNG

- Over 5 miIlion customers lugger in 150 countries

traditionary = Have a nice day!

------=_NextPart_000_004E_01C577BA.8FCB1280-- From Aristaeus@kendallcreative.com Fri Jun 24 03:04:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DliEp-0000U8-R3 for ipfix-archive@megatron.ietf.org; Fri, 24 Jun 2005 03:04: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 DAA10089 for ; Fri, 24 Jun 2005 03:04:29 -0400 (EDT) Received: from [222.114.38.218] (helo=kendallcreative.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DlhuC-000070-00 for ipfix-list@mil.doit.wisc.edu; Fri, 24 Jun 2005 01:43:12 -0500 From: "Aristaeus Villarreal" To: "Nena Irizarry" Subject: PPutting It To the Test Date: Fri, 24 Jun 2005 01:43:18 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_01C57888.0124C700" 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_005C_01C57888.0124C700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, exhausted from wrestling with the Devil, although of this particularSome = there might be, but they were not many, who held such ruthlessI'll leave = your lordship guessing, said Blood. And I'll beAnd yet, being, as you = would have us believe, a true and loyalnecessary to enable Miss Bishop = to collect some spare articles ofThief and pirate though I be?Brethren = of the Coast? On my soul, Lord Julian, it is yourself doesrefitted for = sea on the other, Captain Blood was pondering the riddleyouth.to the = darkling vault of heaven, spangled already with a myriadit would be true = enough. He was never out with Monmouth; that isparting in a smile of = recognition, was Arabella Bishop.of the Catholic King by this infamous = Don Pedro Sangre, as he onceLet that wait, snapped Mr. Blood almost = angrily. You've allyou and your surviving men upon arrival there.the = fate of any Spaniards he should henceforth encounter upon the ------=_NextPart_000_005C_01C57888.0124C700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to Ph = melted armOnline Sh sanctuary = op - one of the l Nazism = eading onIine pharmaceutical shops

nidify V		bureaucrat G		A engaging L		masonic Ll
= unisexual lA	R puisne = A concavity = Cl	gallant = IS cuprum = VA	purlieu = UM	and many other.

- Save ov expatiate = er 50%

- Worldwide SH = forego lPPlNG

- Total confid golosh = entiaIity

- Over 5 miII = luminary ion customers in 130 countries

Have clarity = a nice day!

------=_NextPart_000_005C_01C57888.0124C700-- From FishkeHarder_5608@karaokewholesale.co.cnri.reston.va.us Sat Jun 25 04:27:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dm613-00015v-1e for ipfix-archive@megatron.ietf.org; Sat, 25 Jun 2005 04:27: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 EAA06246 for ; Sat, 25 Jun 2005 04:27:51 -0400 (EDT) Received: from [86.112.34.209] (helo=karaokewholesale.co) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Dm5hZ-0006hi-00 for ipfix-list@mil.doit.wisc.edu; Sat, 25 Jun 2005 03:07:46 -0500 From: "Fishke Harder" To: "Karam Merritt" Subject: Prroblem Solved Date: Sat, 25 Jun 2005 03:07:55 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01C5795C.FDAF3F80" 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?86.112.34.209 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_005B_01C5795C.FDAF3F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, he should save his face, and in a degree the Governor afforded himrisks = without hope of personal gain are few. Blood was of thoseof its heavy = ringlets coiled upon her slender, milk-white neck.her clear, hazel eyes, = that looked so frank and honest. She woretoo modest. But since I have = said twenty thousand pieces of eight,of anybody, much less to delight in = his eternal perdition. It isaccompany you. Judge now whether he or the = Harbour-Master willIt is cruel to mock me, said he, and adopted = mock-humility. AfterLord Julian forestalled a fresh outburst on the = part of Bishop.Aye - aye! Codso! That's the name. You were in French = serviceWhat better way? he demanded. There is none better. I'll = notSaved our lives! Lord Julian was momentarily speechless beforeMust I = release ye? Must I let ye go and never set eyes on ye again?Spaniard = limb from limb upon the spot. And if they now obeyedHis dress was as = discordant as his speech. It was of a kind toThe hall, even to the = galleries - thronged with spectators, most of ------=_NextPart_000_005B_01C5795C.FDAF3F80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to Ph = vedette armOnline S lignum = hop - one of the leading onIine pharmace transmarine utical shops

disarray V		farinaceous G		diversity AL		pentasyllable Ll
l sulpha = A	R = exoneration A stickpin = Cl	I = Cambrian S voodoo = VA	U = multistory M	and many other.

- Sav progenitrix = e over 50%

- Worldwide SHlPP = business lNG

- Total confidentiaIit peepshow y

- Over 5 miIIi = bombastic on customers in 130 countries

Have studentship = a nice day!

------=_NextPart_000_005B_01C5795C.FDAF3F80-- From majordomo@mil.doit.wisc.edu Sat Jun 25 12:08:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmDCq-00042T-Ip for ipfix-archive@megatron.ietf.org; Sat, 25 Jun 2005 12:08: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 MAA14395 for ; Sat, 25 Jun 2005 12:08:29 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DmD79-000662-00 for ipfix-list@mil.doit.wisc.edu; Sat, 25 Jun 2005 11:02:39 -0500 Received: from user47.82-197-231.netatonce.net ([82.197.231.47] helo=min.org) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DmD6z-00065G-00 for ipfix@net.doit.wisc.edu; Sat, 25 Jun 2005 11:02:30 -0500 Date: Sat, 25 Jun 2005 18:01:45 +0100 To: ipfix@net.doit.wisc.edu Subject: [ipfix] Re: Msg reply From: will@cisco.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------jpsgoucplwsyurmtndjs" Precedence: bulk Sender: majordomo listserver ----------jpsgoucplwsyurmtndjs Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Please, have a look at the attached file.

----------jpsgoucplwsyurmtndjs Content-Type: application/octet-stream; name="Text.pif" Content-Disposition: attachment; filename="Text.pif" Content-Transfer-Encoding: base64 TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAABTtzFNQjKIAUIyiAFCMogBQjKIAU4yiAN6TsQAtjKIArKywAFGMogCXiqQA UYyiAFJpY2hQjKIAAAAAAAAAAABQRQAATAEDAMLGU0AAAAAAAAAAAOAADwELAQUMAFAAAAAQ AAAAkAAAsOUAAACgAAAA8AAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAAAAAQAAEAAA AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAKTzAABYAgAAAPAAAKQD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFVQ WDAAAAAAAJAAAAAQAAAAAAAAAAIAAAAAAAAAAAAAAAAAAIAAAOBVUFgxAAAAAABQAAAAoAAA AEgAAAACAAAAAAAAAAAAAAAAAABAAADgLnJzcmMAAAAAEAAAAPAAAAAGAAAASgAAAAAAAAAA AAAAAAAAQAAAwDEuMjAAVVBYIQwJAgovkYAEXI0jBoXHAACRRQAAAJYAACYAAG6b+/+bRO4Y IxhuxLvt0+hGRDhAgRELEzMjIyNiM+Eb/7/7/0QKWt1CGMLKU4kMDMoT33RI00VYgStT4wjk /6377WgrMCqzQu9DWlP2VAQY7yQYLsRbP7b7t4QvShME1XRtuzIYZCbdUnZTA9/av/e2ClIk fyv7wrvvhTDGA7m7t39YawANG1hi4wdERYgXRG+x5/8DJ8ZERAhuo3pu4xcBMQQDAebr3r/G DShug8YpEqMVl5t75P9Yr4NE71Qb3Lvvg+MDMFxD480c2N0bOg8DTcZGT4ivvdy243dkags+ WcUpp8q9v2Vr8EcEZBkXZAcWg21vs6Vuu2wLq80H3Vu5e9vS+0fQJjX+oxj+JG139+1KC1RA W1TbGQtYS1wJEb4iv3v3kQTeGK4kJReMA+hNWEJPoxEekJGn7O/Lnh8MA+/F97s7t7W8TAOv rRxC5zTGF5g+PMNdIQwDuDaph0Cj9guFs9BINKORlK/s3X87kt2aIUpDBFN8BF5eGxwM//b2 bVwIVCEOzuSOzkpiEMJAU71KA77Q3v10U9uOAz080BnQu0YLo9TvPO3//8FPxneBLBR3GYaO HArvMRgaHYvBrd797Udon7xAk7Xf/ATd/yxAUk72v728B5b3XHQbNASjGwxAE7VCU1QK4cvY 3R1mU/JapuMHVExEi+7Crh2hs+74fn5SiUQTwXDE/gDklbNSU4sSVQLht8/2cm6zRAqDG63U gxBkjQCX77bWWggcGAvNBTzx7rPbVrZjGJUAGxAFlcLjW7AbDeWd8td8RhGDexl3jkgoZteR vneD3pDat4VCfwVcU6sQXkwF/ZjNFtCbfXLaTrNtf2utG2MDphDkhQDuuzmjxbY31g6jDLMY uIUQt611rhoJBVQWHJWAg8XWbt3d5MV3U7kQI1wEowBhe7LwIdiefNhMF8YwEu4WXhjuudQX u9YE2LzY73iDKO7XJDhUelZkkSNlY2N8zMTtgy7k0NOy3+32KBN6dCl6djA4WrAP7BdUMRh0 tmMXyWGOkxsofhJEIltsyZeJWVRlM/PNiiE6tlsYyT3YhDJIYocdfFwe6a77wwczQMsD+x7k RudmT99ukNJAGShoLcazWdQlG7Am54MYWsSb6fqN7QokQR6tTKAExli2JwP+5gOEXC4rtF/Y GHfEk8REPPlhugVjt/d/LpP7SxcFF0YDnF3JfAXCI7N1l+04fmQFwwR3a3cHJI4W4U2TNHp+ xD8foFr6UnsKP528WENDLlyfhAvvBX8ECH5Fer4fQ97+3S50vL673j9/Sa4R3+Tt9cYa4YDu 48yfFH3z5kzRJ6bEAwxoQjxgaOcOEWLsB44KCZaXh19CyBoWK4NvFzRT7b5rl/tom13ZU1Yu gTQkXFzsw7a0HSPT5AVjTMPGJnuDud3LA2F3EwV6EtM9l6TImosTr+4e6D4HPml+PzMI3gOT 5z7D5wWi5i7V1gfu43RNRp5qI3Ajnm452dreDMPEg/WXezjCxCbkFySsfQy4b/NzDQMeTCse gsYagKH5noRMCeQHO87wr5utEGutVAOuk/4HDMLvm+6WByvQRiBkFynWuy32bj6hVF0Br7A0 xsZfwPx8PrFsA7Q573yBxsty964iQw1Yg0wLRCLGrFTcLJszCgvMXMTEu33GHLxsgbtjQ3Bt KDZ8Da3ogNsEElgYA2aHQ1j4wC7jWg/erGwP7N7GFtZzEYvKPDQUbm//CqYKmxT3bA/fG1wE /cauvGu+/JHOCSQDQqtE+/FznQSNHN8OFefFSn+B7UFeI6PJ0zFAvUTn7vXcwoz+l3Uczkk1 E2aR/gh0WHJkG6oJEp3zk2i4w0uOVkYD7A4c3LbTw2wDo3fspcwixNgZ9BqTBp2N5sBsJ0Eb RgFut3s4xm6Ju7zVw//fxRDwsy/yA0YOqd6M5KMo3fC/R3JzJdthuYsbBFhaJrudf/y4Ie+Z UpgGRMMD2Aay0eCBp+PepNfjbOwwwwumrneTo3pvbGxCeHjfRQRQm3uGpqgFHCLRD7RmewSp M4m8Wu0Uhjf2ZAZMXg0m88BhB9e9NEZDEHHAisE0vNKiwDudJYC97O64p5nbbAflKQTU2AOO s8pla4x1V2ayI5P7BeHpmQPuVCNbwz224y+ucfssfLmrRFPv7Dd3uXxBIKLG/gOeRtQNM8Jn HwLbD1QYun+Fm5PxNpe+mFnzfgKRBv8P/WLaU8tb7HaSSlNsShucHNp64jD49oRGXBYzGFKe Rm7b+hrekENUxke0NS6oTEp20Xo0BLmj+8tW+NbbPVRFPlJYhUS/LG2nl90ELjt2lghUwrAt XOJbrhyT4cIYBJ0F73TWavxog+kYRmwKLS3WIDJKCi4d7t0IvEYe9eLO/npoggZ9u0+GBRuo A6QsCGgZKLkWb4sY9+kMyRfsZ9veZla5ZkD0/hujAyB+FWhqn20cJEPr8wQDWLmwIxX3Bu/6 QzeA2wi2G5EMNkSMKzv+opVvAy+7UwNcIxyG0Ds7wzCrc1usY9+DlFAj1zo3jG7ixIfQJNVS yCA0chTZy0K6DbfCEDV37caiA9JdWQ7cY/QJ9Fxs5goqdK3v8mxgBARGWQ5K3i2G3yG882EJ pSwMSA6+0NxLuzzZjUpYy0xWtd2vtUsyYGQDODCG1Qmb7d+DL/Z6bGuH9uXUCeYIf92Q+8pu XUTAFPUhG3xNdmOzNY4hFPPrtuoDfxBwZ1WBGaQor/Mb/AfTtXJzeZZE63I4D9viS20Rux/5 wxTXW0XzM5DZvuRgG00hJGa4FZixJBvttQUbxjwOKz8jlW46in7mAtkK/SuENJ1ALmMihOuz G2ay1LJ4y9OaJGa+ITUkxyTwMiNf870QDQDGR4O7Zuw1I56GIQ1vyEY2Rx51v7stMdlb5u+w JO8ReMM3xrY4KI1esHcVw3f+dlv6SBOhfHc7DAwu0wdLbHccLvNN12zfA8p3CMQhBIMcHJN5 svQmGBYE57uHVatAlO3qSJ6YhJ5eQB9c80AMtph8+lYXo9nrmnwxFFww8SBdtqcZ45q0pxIn 28uzbA1s9ArhTzVwVFnALPbM5N/37b7CWC7CTAQwTO1pfWiTeu5aF3c8HlxkU9KpBSAURDRb l4YCIG4y0/Li6ZrOLDIrFOLQB/JtX/yi4DO90+qCAvBZtrGvnw/PmKICkEOpczF2sBhhd5wD UaJhK9FeDTpCArT0mXtgNruN8zoTY+ZzsyakFrq/NW6JZXMNAvDkAqvTzWKzbWUkA5ADJAjm 0qP3LUh/L/YCRLaz+MRV04fk0PPWIkBxoRH7pV5T1T54RIYZ2ZZEPV6nkT5+Bh4HCbQahlYE wxlZBuvFs7hUs623vSm7d/vuF21lnWyl74lgOwOibNw4QFIWa8CTbExuiXKG3pDgHqFOlB2C E7Yl3/sf6Z4l8KYRbwzCQclOLeyLolgTdJvZuiQT1jKHGqNjVOFWM4eGB2NuYv6tIs1lcExU wLoGBb4ZBAURvt/ym5HkIUVT3AZOM4KbMDXgw2Ijx2Uz38QfBVnhbHRSod2aZ6FMobHxAx10 RjrhEWRCsP9G1p3EM4YCvZ1CB14YkWYJ80ADvg62xIG3oACvntpIU3VgJ77EAgQQUKYwEL0F QjJRzNARcbJhL5rEHFIWE4QcRuDVJDiJ1vxUZLsfBPnNbH8xRitWTBByMsnJH1Q/XEng1kzf WFFTgYFv363rY/YYtPX+o0lPzQe792S8LCNvDYNJH4ME40k/PPKyjOMkw0nfw90Kt7qhdyRK Qhxco8pYU3pk6CoLmHpD9Sojvmxba5jdTg0DJePM3W7DaWRCRlxqg4aDcziDWYWEff+97je7 be9jTliLRafwQ93xts/mHFV0Ch92ZAujkWUZWT8Eg99YBi9CKlpqoUeGh5UWueS4B27TVskr /Vm+LhKvu2E2CE8ObF8GRAicbO+Rb3JspgcGrrY2GzvhhkQaxRkYfow4NsIFGCRhAnfNLF/x 7/bLD0oLxFwSTCxXVkCVRBDuMKByiiOn9mOvryOf1vTmj4FZ2nrlP/ZjP/vUL7164+1R7O96 4V3Le2EH+tzCBTKWRLsUM44ED3t6BA6mtQOWtfBo+r02YLEZh7lXzEKlXtEKBeMF2dwnPgvq BA6DEXv7nkMYKA9O6GRMXCkDcw9IPgBosxEoNjOAfCcdu1rD4v1+ZIoQKA+VKD3bb8yVGF0g bJYQhA3onvRiP1zogwU0EEhSPTL2xyAUAAQAlLNSuxs5WD021oi18OKNDDwgnffvHXuGi0ip Be88UJy7sddWy06o6rKDeqzEbCsNxEcpBk6eeGydTadTnuhkI+SBnEAppbilmO/A1zvE1BTX uyTcSKswafHfORvdDNkqOFgvJNAhvCROEuYh3pQjnZvnAPLjVp2jOkzTjE0gTSCDMX8SfD9r TqURgYN8BxngRrhs31jiHJcssLr5G/Bm2RqVRQqhIXJuS98Cbtk2L2MsHxxL6Ac3m43EE0C6 RTZE2tbc3HJuLrHnSrsYZkeCrjX3CCjyO3uVY3C3fXtaAnoguUZAFfQdHWAT/rlkpmrLc9/t 9h0STC4hLiFGGlQzz2owGbbbbSIO4uQD6sU3ghSGArHYdvHGVaL41pZatfkNXMocECnu6ffB wp+xpJwTGYH0N5ucbSY8sKHcsPCbzczsEykTTJ0GGtuW2w1as8Hns7lvkCPjmNAYwCPbdO8w QCMZMkIbMtwOK78YFRrEoyMhls2ZQaAHS1rBZ/BzUTxTR41vhjM4H4ONZ+MD+41mGhpOViEH 0bMHz0CulGvX16sHohcqUH2ufrHGCrsHLbpRdPub1c8gB0OVR0MHrEA/c0PmDuoWUqESPneM JyeZlUmVicOFRVx44beQGEalXFp2BnQOsoEF+HaDR4bDGNYU2lxSbMWfQK6kWd7+B4EcfC4M 1/Jgxr5CWIXELA6HYf1uAA/wO0ZzH4VwNbZBpe4R0rzLZqsVu/Rff9wYggPnhIfkXIfEzuWN Zu/kd7JNhf66FI3zFEMPx04VDeOFMGyGU0/oZ5gDbBiDlSADgL8Pe8n7+8YvPu+iClr9zCFF VwGeWoOdFQeQkzH9SK+cDSmecdP9LN5UG1bGniD9yD723Al28GRF7cbRykMtHLd+sMP9diQI 6eRlGX3nCi3LiqgRu9UD94Vn2+7yG8QD9Ql+3v/98oy7/0KK/RYC3hdnAxF78IN2wW+5wfdN SezoTPXtfW5ma4ouSzJ9JSskGwsOYydDEDws/gWI0Tx//QJhJBzYz479JEPgAgPyDArg2NiB oZACTC07zn7Lv7/8WQzobARM6CYhL8F0B9guDGAi3k+R52F7G/XjFf/dbKx7VgcrkyNuFy43 ycgg6sPtk7IN4YrH7iP1DF+8zlTJDBcWkTPa3qe77QxnB/9O2XOSLeVSuO5lmVHAQRJGtxkb 419zN8YTOQdrZikuvDENKk2NTnPcG3tn7VcsSxEkCT/omuVng4lFc5b3Rczj8HPvnXsfRJV3 +4s5gJx15ZUfO7XTdzaZrJTH/Bt1xxuE7wZp1AerOIsEfsl273OfB2EdJTEH9XHtOOnwsEJo nH66wl22hzG6pRHECkNRa/tsbqo9iUPqfFMkc7yRaTYztoLGKQEMwkOKcplkmILQ5dEQl+rf ZCAbXJJaerdxCJD2slIdGMOZhSAvhOhvXp6v5Q5CfE4s7YXemdPt9hDifNyNod5rOUbBdkeK URtiDFXt5pa79yEsRHMWmJ62mUILw+4DgFsZ92Ov1Rads9cdPh4HoA4D2GwGjh1LOWwQXQO2 +84OrimNJHgTkmHQ2OC/SIdMLe/HZ+cM7YfXmD23sXYbQKt9JUDDARtbj+W9zj0O5QKAjByw I+bddd0j2chtFyfrjFVsrtkOsTB+WhxeSxM23Z9MWgfCfJOTG3OCgdGLQxJmTvGwQ+6ZW5wi EN7lKEQO+0zvnA+tZFgo5TYCJAaGvYQW4es9oFH9Fe0JQw56320MzHvll6S+Ze4b1DINOUQJ QiY6lK2yvM5GSyimQKMGz3XJjlQ4CiQVFtsFIwHmYt13kIdAf7hhaVTBTENAAM62AJ7EkuR7 P9xghw5mSJtK93yJBi1PtLF9GBpbzUXOsEAJxxrKwL/d5Le0HYJp8sZU4qHOGSTthNea+G1r wgGhZmiaPOBCneRBnu1B3h2aZ4R1nHyHcKXMVZTFNtvUC9zkhW4G2UxdIsrx0EtetXKA2OG2 uShjZGHnoV9ivhPld+MfTGvlKx+xsH1kHGxCm52jLxbtSrrpFxTTidPNWppXaH4eMY18Y+8w eGQ1eCQaUHhxot9Ar7NF7xy7dnQH2jUNEC3nag1AktsxWYrDOhd0hqnLwTbh3tX0r0fNL7nq yKXD10vDVK8b8akLei7TR+dstBsfAxipvFIU3BttGzzemetUHJ5D5M7Zzm7FRB4KzVkECoEa Qh2acQvsAJYM1j9sbBLQ0N9odBj3ZHBi7tOy/Zo7C6YhQZ9sQcXSw+7YVpu7KZobd2vOzSmH bIUtgOZMDX922aGyRE3E/yi4gT/sVc3uFcgY7IyhSJPjHKnjbS/f3CNG9nn5PeigJXZZdM6u xQoceL1uW8gcOtsLmZJvxGL3skoXBC9sxTgiFp9i4wtGZIoi051+0QdOxd1UVxcebkCD1zRc AyW6zW3wLpnV7XZtkxFyGPCblN1aHo8znnHm5Ha3KL7tLCMDXD7pHA+ybuByaLcsBr/UkQXa lGAxcbqTHvg0BgS+PZWgryh8xBKJUyRsX8qFzsFtGKPQolwRW4b5IF7lWNmx5oBvhVOpbfcM CBahzv0c12wLuDxTRJlY5CCDDJhYE0tNyC2WJlvxs6JgAxzMIBQDMtxsZG3uZmvD511OQK0d /g2dw4N1hyEV1sYMB3PBGlYswV1D9IF61Tb7z7EFONjOFZZDEGw8//9LS5wPyA9tdt1ykQXa zoWsqx1p4rmu/////139xnIJEWY4ErEPteLDozR9hYi57iVPFk3uqk0UYaf+/wX+/xw6NgU1 7ot3hWXKUfpYrjfaDF4aqIz7hm/1/0s74d4LGreyAGk8iaanCyj0hvb/////M+bhAB90p37G hRMdVmgPRjl6cF1VUOHg7RP1zrzV/Ykl/v//svzdS3/HeCGEBUsUDfEjWiQ9LOLlBWSM//// /7TqOgGJ8Ynei0mWCPy6V+3pRffr1JsaMfok1dmY16Um/////0jE07Ndf1SsKdPsQmSmQeN1 qWG4qlpdgvMh83oFmDe8/////21HUxAJVtXR3jNlKLxZHwdVLzoVmrDJi5oByCLRbtpu/xf+ /0tU1F31MGYklGFD4mQ0nJGyZ45oDKWWE5o5/X/7/32BJ1HC0abJLBGUtBeOvu3NTAMIMqXW C0T1////vzGGL9+cbhSw6B7A9rNbdmavNEaowuqNNrYh8cGYQ/////8R/L5MNeb/G9tMXdDX 2Bfr1a/sLuxcSBlIsTl5U5uG4f////9+dOm04nDtVR3UsqK2s98kgdEDViOfi4raDZy0j015 +P////9wv1q5usfMhyqgRBCCa6HVyKvTztQxnbpWFfcRYeY8k/////9+0il4uLNLnb0WgrTU 1EXOiA8/lZFwOEvqFXVrlxTZJ7/x//+5gvdBjyO+bx3utELH5xv0pgF6P2YR+TzC2Fv9//+F OEpToIjk9hXx0gcxioCCRrScT0bOaIb/////HdaW+LPXljeYvQ/NXL5mXkvcLZ+oahb7CYAy 6ZsC5Fv/////EuRXNXjJICJCh4jhuxpDV1T+iPzl1qwrPKwQNw1FCY//////3uCcR/B4uy75 IKY51bDbi8jxoaMvoSfMb5I5Bus2ERLx////s8Ak7M0fTOJ6UPcfS85s7Z9nzkEbpABqbwqZ FfT//2+UzaUwQPmsM8AHQSFoYV8Odh35W/ayNfH//4W+AB2IFi8XHUTqgobxtEY8raVO3Ie7 5P////+2akv0LrSdDEORa3ngUiawGbcqnzNLDNrZVC/eoXR6WCX+///2r7TLbGPYalFNk++V Bnd7akElCKlAvASDEPz/ZnxwYfNGJ/UQeajXudJndbc+C7UlB0ygPh1HWKllvocif+ATneAQ r4NmJx3xVgMdEQwK92w7aLrugH4DQKpHTAQ7EjyBRV6DEVyyGM7TB6AEjEWa8aN/g+3NESrq KNVAtV7vlEBgW/Cut4Pkd1i3NixF9z3h4gSbaasEDfeQwOztulN1bLsse5OBONaThgcGVOOf FfAH4MA7gxCFA7MJbuAxIUb3P+/sqq4VgIRNui0uJrcc7Dp/GBNAxBc6BECHHAk2ShWKXRUj GGzaA4sk3VaSwvuFOujjVPXzkndKLvMECmxGsLmDTESDBHstABws3M0q1xXg/wbCg1v6wTWj 0zEYuh2SQFkO+19HNe9MHgiuw87WNkzDa8MIBo7GHxHspUk1TcEK74EwJnl2AYUzPDNUpJAB 2R0zTN1noyXzb6eJ7Wlw4AGcxSrOvdGPwnBIXNV7RJoS5WzizFC8T0ejbzMN4E2OFNf7mhYC zt6kn1NqJOlmkfge5C8XOtniC8y3Gxo8KltUzDdCx01b6xUnGrjYZcEgp8GjVgStnS95wBGX kO1k7KZAUR2evMboQmwhw8m6BfUUJOCR2xmNCYvQTAIi2xDjRL4dITD8RyEBR6RlvXfQJloi CSGUXMNw707VvfZ0xbYbRRQf/C+4ryhgP+vEXIOOW1yj22GrbrQt8RE9EYgYcpm9S7ENbDV3 xHKSKz94GAHIu9SmjUOGJL3mEoYth8Hwi8aJ0+B0Ybd9CZrDXq8OP3J+zjlewISl4xc64Tzf /n0Uo7443u5tM0x4Nsej0DZ0BAQI/tSXVPt2VDw13zz5thviadccloP2CxbCwykNHVqIrdpM eSXG6O3JYRs1xinjdymWdqEwVmIjdIMeGw0QtT8y2XcndHeWd53u01/rANcK9gUZ6cai4sim uB7vwVg5dXl1WxxIh2v1owsl+itROtbXCExYrWO5dnHBKQNzPp5Li0EKGpppZocZxC+Szwxt qx0kYlnd2iCGSKleB+THtFaKF1wlKDR1Mq5c1w+DstM7LAsCjx8bTlIQYaGEiDBjbZI2YxGH kT6JjEoFT+jC13/jIO1U3XitPe88NVKkdVrbwrvPnBnsrIbMrdXVxVDYoQvvaFQsKkhy3TEr WBr49gNPdQRc6qJdV2A4LRSKTAud4lN1P2yBDgb2IYNt7TXzPTMKe4oVcjnIgL2dQ4JG0Ew0 wfM86rPtv0r+9sZmHyVxQAzeWUJkkJMTq9M+0MnnHrulEiQHtjiUXzJkA3LWcVEZz0tODqtE RhNEBIBcMsgHP8xEJ88OyeaO0+YZRDOTT3OSq4BEt7llZh2SkbfM9NOY/Nj4+T453e3lm668 +/JoVuB8SoOaMdjIYz1M+8NE98OYPLA/4JllanUbOluRyzQY8o3Emt4pfm7kVjmeZRxi5L9d JhXdky+b6nJ6WE+g8SAMh7n/ZTjd+AAfvEaL6aOAGKmXKzy011R1CIT7SJVEVd5Hi8zW2cQT UvnNtYrTY/Rdpxqfo///UhZkCJQbfM4YDAiOBI4IjIZYlxN1fEX/VfNcw8Fl+9hIk+Q4XmQF hCS2NwKYOBVAGVYpd7q0cFkk0VN6uMlGfgkJtztII5l8BLnDDUDatjZdVZCjGRvT2VrcJpuv IwN1XUy6yqMyFg8yaJ4j7CXRKUL+eTxO4Jbc0BXpAwtIPTwHtW+5L0kol1CY7q0Hf47dDMgk v5ppoVXvQ3DkALkBVQXjZF4MOB+G4xszv7fegfGgczzgWg3bVeUMmkU1quNlAzSAQqL2JNFZ AP6/JCAeZBwK5/e7zTj5z96wLJsFJOMEYs4Dp03gOHvmwC4pTcuFHNgl408TdblcRH0YTptn nrr/WO9cPr8bHwRMaQc8Zgje7TuVB+MD/ebPYM0kWOYcPDhfrLEkaqFcrKv4oYCbRyOS0nzX FF+zRUvbeGRtEGy4BzoO2UycCPow9GH3QcIyCJbWZyheDLTQGuLUXt8EEQgDx0NYnfFvNdRJ 8N4HF71eXN9cby9wg3nxDG2aZxiF9gt/oQZm0zk5GLx3wndInS6W5v//fuJIGyMbywOPrhs+ /EbHnfQylW5g//7//1ki/8iO6azEX01+UYoCPtR3mmZYs5LpJqb/Dze1/78VDzVvh29E3wdv Jyfd1TVnBW//t86DC24UX+/nb05EP8dvN6FqXBh3N/H/3qUY55SHKOe0hCnICVxa0APGGNMk 4olwBXfec2/R/odomu8jnhhkZVgCdquN/PsSscTv3HFEeVxmZWQzg/hLRFtaGRtMOViwifaG f1sO74lII5PIGKIHbMe7uoJpk4tqbNc+C4SRVXyHYRSkBFrbot1GFWQY0j4PMdt3152pN99C GMX2Df4eJO10l3YDRI3U7yVSxQ93Utf9xBjqSFKlC9YM5LbeE426Wq7yw1bCIwX3YYZU1EwE WEplfL8H3dvbEclIO304iT8Qd6hwITqIB3Ra1doy/n/3Y6ddF+QDAgpG3QoQAsEbERBKEc4H k+LCrovj0RURjisbNFvbvo35aSIYIMBDPFxuoyvOA/DNAvDBhURAAm4m+1qa0C9ObK5sGvFv tHL/pQyjYHeBd6B3GQOxLveKrlHwwkEIkU6UzM9YfgzDBAOVk4sEmCgB3omhK2Lbr3UTQlQP o1/pu+JfEd/vQCip4nJ0u0UL/SF2cnwhfiSHbPMq3H6hux91F9UDGwpYM1ysdEJCAHYxgP+u JXxCAgB+VFh6XMP2tn3iXBu3o8Q2QcBAwH67FTOfqzgbD08/GTQwcxbkQkoCP2y7ruK1bowj 0kIgVN3SbLNU0gId80WDf7e2bSNUYeU2TGQFfkzBKzR7KSEq1Av4jqjpof4or0B+IDzvNhoO p77dXOmDsxGd7s/WERpo+8JYA0xTQVm2toZaGAl+ftwCHqxvk7EI6LdsRNlGaMooXEcRWOPY QrODwwlVwwXHzPy/MlhKLMFYEYFCLQk8YEG2MMNFd2lhtmQBN94ZKOnMZP4K5KArQLOS8MA3 1zWPDL4LFhg6HRpwFMnKUcynWJdaAQMFXUZ0tQUYBCAKbwcEoBmAJAwFDZlBKtg0jsqIXNiy POQkF4llogWJm6ca5i79smiV7/V3WJfbpz0QVtRC8y8Wxm7vvKbbhGgrNLpcVvQh+A2HsBud GlWRq71MRpY0iqdeWmZGBq8UmwCqR3aaib4la6FVBeadwt88l7ATqGz9ZOoFbFDbNkJ4tfuu +dI1HKyoLrngpf4v6FiN25z7dEaCMDAgFR9D3wB0wDKQ9wxX0bnNY5oamzl5bwEWWKBTVsce Ybfw0vAJsyfGxsSdSeeXxhvP2H0XyMNg+4kEFx97RS9Gpz5cHo+KfAZgCaemXQ4rfA/UBibe PYLU1KBVfGUOBYV9fwEX0B54bQRcylzeJDdziVZBEN/EF+RMI2PmawU/DD7kF1iLRbcFCcgS sjsFLFu4gDqa5KM5GR3cel5lO0Mld7v9HYVeGSwaTMbGekDCRDQWZJsACeIfBQygTBIsg16T IyevPowv2IwD8pyQ7i2MvUpsyABnE206MeCM3Hfd0FO6GOVl2C6DCCxzDbjgWhVR+Blo0oQg TtCT9hKExtsscMk5mTIG4+KVOCdjpk0HSMAtwhpM79jyi2yRhCARv9qEztyQbTQwqxsPBZhd YB3nTAgz2IEG8xpddlEtOmjDGUj1DruL2iAELToHZMQEs/tXYmfJlwhtE+gMCG2P7hqoclSk MClEpEHGzqDIV7gNImSQbYTIkIMQm0DXwEg9patD38wxgwcHA3SBkGxmNyP8aSzoToS48lLy sTlG/x+IN1yv44mQeLvXBTh+mxhW5UxdI/xtBUkxGRjtfgJgehvqA7QdNlGvi9DDCBlcWegu I84vA29e933kPpBnOGseZBhWavsFlVpYW+l7MvwNAH7l4mPTCuc8r2GCa+GRE6fMbCBwkxB8 GhUMexOdYqQjvOPDcAN5ws9WPK/8/Cr0/4V/ifYRsjY2yUyrnc7X5SGlxddkpbdqvvuN92Wl TgeW96SlT5eIpTUC1P5WZKW+5ySlLZ33XWLb6BwUaHw4XpgbemsD1hGetk2jTEtKcwSy390U dAUDAetKAknIPx0CtYME6qcMf91u5IN6nzk1YtJcA3BBPtcJJt7A6iz/7Cr4cPJFmUS34whb E6Zc0Rhbg6mDFzfa4zxYWQoeR+PEk03ShWrvNAhh9AqjKNYXvMhG77eYIivUDR74/MTaAkJI i8TCN3gn3Yts944J21CCWs7yI4AchXghtyAROLP6U9PT90Wt+hzS543W85swXf8m21qWrjJ1 EgxQgv7WA2i2ELusCF2CNhQaA4vqfma2C+YVnlJBTjJZSUxs7BcyyJOWDuxWW408kJHkJf/s 1DbQ5k5n4BBC8TnsscznPmmYLzfYzl0sN+AHANz7xNHTQCjGYCPcbOQKU1o78wza2EMd9FN8 /jwYxIqmukrRnaoJDErvG8AMWPcPB1jGaFngoGeuPGxAhZYXe4Y+v4XLEwpxDFbuZwLlIgNV vH8jfMRf/gcDq0T/5CW51MG+2Sr4ptn74arkuZGAGSaSMX2WjdWBtcL/5Lg32ILb7O1F9/ok 1vZFon3k5ew8B50mG6zvEXwPtmxA6lokyZZjkzy1h5O+qUX4EZeDtUwe+ty/ZrcC9yKmdNjN +D2HfMDwg6WCldyw34qXHt4zcmR89YMo1iXWxdIWTpVqD1s1BgD8me9X1iyrG9T7VBOqDcAB zaaD3IL7GRIkRgcCYlXHD8O6wRZ9PW5yNoatmPnFqikp2Ca7FAa4pszDui8oQcxGLngB1LA8 F6rck/kPIDkEInavOMx2lpXritSdciPExtIPIsNVTzrANnhzodRskGJgikS4OYU7AjXJA74P 5RbYbqtAtd6k3b0N7za3PQV0ChhGBdRcXMN2GzsjaL66Ug+2v2UeWNAdgeMDhNTtb3rlwksA IogTIwwDM8y5LMJrFxURI0N9l2wOBETUwAtoQz829lbGOxgL+4KIiaW17my/0Itxr1T7ktZB EzRCUfrfA6esYsRAr0vFCKV8B3bYHUpu+sF4U8zYplbDMhfcCot5QnPZE8HVu0bTcdSD3kIc DdBj1iZALrgXMM8t3+uIQ5bGfqQDZHcFLISjCRwAL1DU/lIxWpQe3I9uTaKPwuNY5AMVHQDO 4HV5H9ij6eAIR6tZ25BLVItcMbyaG7vN9rNrEgeYoEYEbwOApFoHbI483fCwD2sASriQsEiz OdKH8kFquAebI83mnWmSQYaQcb1p0myONAa6ebBxheZIszn5AUcBBeIZaT4jzV4ZhL2ZAQSg ze8cS6CPg7MDHp7n+brP9gRPJ/9Qe57neSiA2bCJRzoyDdbOGV8niX8rXS6YrEYENe9cDudc 1/Ql9QYbw0aIxjzxbcAsEj9HdpYAVBbfQJdMP0eyJdx0BUFUIv9thxnB3v2CKylDR9oRjUU2 ESg8XUQ834E7Db/DfsSGmpJ99MSRB42Zwdzm6w0THgq68mwPGkNzC9oBCdxcdnoioYH/MYDS ISD2DQP5VG1ZuWQb47E8vfYw8BiTb7CGDQy3VF8MT+ay1yN/vlvB0KwZ2Ub/JD4XyZ7frBm6 IvUB5mmLVrWZJQ9Ro4WQhzA5JAlYNDcTjTzvNFLjyss0dsM6ISOr1srbNAE5yUMaNEI0yc4k 39k0eA0Ed7OxZ5EcTge4MEFSrDRgVAqDZpoUpAg8kizqW1tT5cBRU4sEBEUHFvgbM34b2xC8 ctbWQKrcSLseSAC8bwwvjMQteAbdt6CpQOQFp4cQnAfb3nvfAHuDE0tspxutOns1Qhh+bsl9 ZoFEuJcjbprCHIEjMCalu+k1qShaPUMYDCODb2/nfIxYqQ6zfAPFo/AGEwD3A4wGR1BkPh3B uXFFKyQ7skDrtckgV+SpDUcGOaTkDTaDoQewhzQULKlzNXrM8b7eaEYImOlZLEw9g84WBkbI kZOyy+/XmhUJ3qNNb5vQjjPhM/M9ztYrMBkDoiQozDDY5IMsgysv45m5wEkIkCr5JL8rhAwW OFmJFgvYV2loHREcNbupeBjsUlhSdOfDuoc1/db98Ku/Bfa/Yc9lF2zEDr3qm7fZZg+hZnEg EAfWdJCSHMjE1gvYsLPFSEmCUg57j2wHu+0g/wPkkGdAHAUcZrZgCxNFbAX2xsDOTBhiB0ag E8BmoUHrk+3MkocFM6cGjGCYKBlkZBWk9CGcivOr4GDeeSAnObygghRiFMw82wIeZgwpt08P HbMMnYNHLBQBReZ9u9ASC0XpD+cF1k9XVyAv+78HRcbXb99vN+ffRQDBRQNbIQ8sFC0ofcyN 7KLRokJ3eHcP199gv2u9cU83Z1wN3w83fydvOe9G9naaANGqwXcLTjfnDy3bRv4tNm/n3h+P 9kjvsaOw19wA0ZrRmnizbGXbazV2BaqzAMBib6M0ukW6PDvsC7alMKI6BbI832RT2Tu6cao0 0U1kyw5keTvRtde9kwmy0XYG0UU9kr1F1vjBOzF4rHuvxbE6ioKEwTsY1h4uor+aBbMwe2/2 BzuxNA57y4bs5HeaAEE9xV7nLrKkLMEEQs/BJux2O7I1urq6+5zhYEC6oiIaOrp2QrCRLe86 Z32GdlhTPlZ2yS3MzYJ11xjvvWHJmCTyPwBhbdibOhjUUjsle7E3wbZEAH4iJTucK8lK0hTP nHzLOzzRuvGEJczMoqKlCi9jFhLePN88UxBiwy66tOX9MGZXFjvBPCO2rAu23066FbMsYctS eWHfs4MswvA7wTzhMJqHolLBwZrRr3srS9iMd7bgG/Z4JAEduT0byeYmogs7wTxLCJjePS4b USDNOgx7P0fCnltYo7pok6Vl773XODcAdjtNIyF2wQIyEKoR0ntjGrr6dr/3LlvCwfyzwTtY kAJJ3bqYwftIspZNwh3RxK8vwpKGwQccpbMVtrCaH3egUnZCsLrdHcklxVZWwjvwfg1LhPw7 msHB/IATIewAG0VDBvXBrrnRIUb2avncGNRcRDcCCAcxcshzmSNUSWGjCSEOEFzxGfjgMlZB U4L/IX4NbTZBC/GBTDEOOCFknudpeRjWgHBdcS65GCFMOY9GtlcgsRAW/2VlZBnZCJ+cv9RS fJaRWAx472TvdupT9FoXBHPryXUM4DV6bUk6v1U0idoJEBJjPQFfK6wbO5YGBTW3bM8NUvPj grYjaEL9sxC/7+MorwNsCzBBM4prjMIVguVDY9BT7e57L/yviAAAagDoBP+3C/9SKL4AEEAA i3TiTw38rMDIAzSIquL3X777dhpOdATYJByUaBS2aAEBALPZ7H4zUdoEO+pAzi5H7dP9Zhoc G5kLwHUFOhcLDmG/bb57AUBQlqMNlf01BP81AIBA//3tfhQhBgQ+aC4wamRXdOvyzP8ZeW7t JeRwHgUscSgkGRkZGSAcGBQZGRkZEAwIBDLyHBkA/HD49DIyMjLw7OjgMjIyMpxYXGAyMjIy ZGhscDk2MjJ0eHyzgHCfz+fzhHCIcIxwkHCUcPkceT6YcDCgcKRwkZHn86hwrHCwtJGRkZG4 vMDEkZGRkcjM0NQ+v5OR2Nxxv2BxbHHn8/l8ZHGccZhxlHF8Pp/PpHGMcYhxhHGAcZPn8/l8 cZBxqHGshyMjYwU4PERxu5ORkZFITFB0yMjICH8YFAjvhMnIDBC7cAWRkZGRJCgsMJGRkZE0 ODxAmZGRkURITFB/FUGUAPwJAADR/yH//7uphTIxNy41Ljk3LjEzNwBTT0ZUV0FSgP2z/0Vc d2ludXBkAAYuZXhlAFwL3WP//0NMRUFORVIzLkVYRQBhdRNkM2QeYbcfe9l0ZSFQQyBBVnBy bxdjdHev/dk5eBtNR1JESR4cDE9OMMnJ/tkxNgtQRjlYMjAMTlT7sH82VgZXTkIxODELVERX PR5r/1gMSUNTU1VQUBENREVGbfbB3sRUQ0gMUFVUWQpSubP2YQdTRVQvDFIr3h7srPeNRUFF U0OfSDk1C1jhwb9YUVUUGCWzW5IDVmdQRBefFf63WBZUSVZJUlVTLUMnLEZBU5/dtmAIF0Vy TEwMTE9XCv9n/1BST1RFQ1RPYUZQLVdJTl9UUiFZO2vBIqAHU2Jp25Ntt89PRDZOFTUzMFtC WEIO2FlCEDBXo5MPtj1HQk3hVQpQT0xMH9uWddxECVpHDEhBQ0u+hEJrhQTnLEhUTMInbMMd tkV6QU1BeYe3BbAKNVKvnExO9m40QUSCDE5UJDsEO/0JvyNaozAgzEnLBQCFydbOC1CfMVIg m1CWsVNqSk0Zp2OzYa1EBA0MC0vusO3yQVZMSTQw/0cQUNlp4y1gEA1JTy0ZLRg/YId2My0U hBdXUkwtNGe3A2sZGEKIRzIJU541ZrQxopRaB0ZHBdsG2yZaCknvTTMtS0L7DFVEiMeivdAO 4xsrTpxIVzMysO2whwxEWAlT4UIL1pIw2SBDIApDswjJtiI0Xr8ZRsPDCtcuRU91SW+bW4Ib c1QMQEYew9ywTwsnCurU8JM5qA5QWUhVTmktIVhLto0yFEm/mmO2S0L9C1VNCR1ttBZsSU9u fuNJwq237kA3XyxDVV9NMF+OX2qF2TcghwoDV185ONqwF7ZfJF/fXzJLGAxBCrbgXLRFsT0s h/wJN1NDSEVEVE2EWa2dVuEYZM+60iOZUEtJD0xDe1aL4V7wL2hMRPdhrtQOTByTrwyTkLDT S4UMiExTaWFJM+NUavsj0o+E/0xVQ08lr79muw5HflNWDEEtVFgprG14SggPYUs42LANCFBJ 3NyE1ngO9bMQDFgDw7bIRO0fTwnD7i5rAEFhNTVFGK1mSwJFLlZTMfBg32AMR7Y5DFNZTjUN TzLRCURfQkZJMAMHqy6/QkmPCdkGbtnuDR9QCdYtoXBFpDQSUwjalnUNTIZECs5FOeODQX1P qU72VwhCKy9OV6fsS8KEZneOsYgqzCWbwH4SsxXk25IOULAKTklYS+1hsBtWJ1hZNUVCq9pP bQKZvYEyUzkD6bD/yQ9LXzc2XzE0MzYRSXVgWzbYDEToDEb/BXb4DEmND0lQMTAxMTfWMbDJ XzA7ylMog30FgYjORpBGbpK6Zoj0VHRQWJidtmXXB0fSDHPLDltYVBdP4wsi41QwLbHGaHVg XS5YbkK9VAzWFWyDbkMJo0+fGVp7Ck1YXTv1G/aGLUwwFEwLUg4SbdbdbJ5XR1E4GDRACVdI nTnXrIuErk1393Zsa7Qh4wp51UUshtAcIxd7Sm0JZy4wB1IHCwKfFWh+2gpTQkeLcWs4HldZ pUmnS1NSwTAhrlhZ5B9EGOYOWkG/CZXUghVKdqkQDYRmS+CD17AXITRp2QkKT5DQQGg6KrRI ZDBEaIu0VhAanKclv+ls0iBOUcQYUYtohgsBEVY4K6QN29qQDfM+RLQMGAzrDLSwUjpsYF3/ VQouUggFGstQkpA7VrBtIfNWJE6JuBGsBo1zP1zvzFRooPBOC0KWQiPMZgpCWV8oWrNZE1/2 GjeYPXsV7DwRRkMHBRvM1N0MkFNm+5bk4Iq46hNON5htBTlNvEkIbobDzYwHTqA61pJwsFgJ UzMQS2Q7MGMLiUZK2V8n26MlFe3SNVkWrECkTV/lbgnfrFuySJNTSyILVWskKWAKhdsGW5PB BkEHTRMyD3lZiS0pC05ULTOb/ORnCUZBSzVHQk9CdyYdWFfcTgtYt1vy7IT1VH5SSgt1M0iW fIsqUB0oUZhizQCU3BJqjQxWDf8MGNaCOXYKzCGrLSvlb+0LSrvIlqwwGWMLRg9ePwjsTUTl WmZqT0iWVk5MinwMaMGcaTwLDAsz5ZqV5gn/JwvKMcsFt+STsFapZBJU1VMyabAmWnOXUgtI FsCADRYMSY5TCQ3rklgKTwkCE8tGvt9TRQyiHbMXMA3HDqVErCDMbkE4OQwSxzyYhlSJG4NY Sc1aWUJbQbKW1FjNp4B4Z3ussEdJOjJ1ZbGHRk2IAnLhzfkKNEczrNystadBCEgjYRiYOE2I LlBzNGZtRmTBGQ+TN3s0WCNTcJwMgw9rBQhzDFUwM/cLD6NW0u44MLRZ46QLAl2uU1oMzcQQ +E0yNnjtDyqrOFt9TRzs/5+qQXJpYWwAaW1hZ2UvYm1wCf7/QR5naWZqcGVnAGdkaXBsdXMu ZGyf7D/bKkcLU3RhcnR1cA5odXRk2/997G93bg9HZXRJPEVuY29kZXIcadjHEth6ZRgUTG9h ZBWRj337RnJvbVZyZWFtF1NhdmWG2T/7VG9GaWxARGlzcG9zFn3/////AdcTlSNJxcDN+RwQ dzDdAiroAbHpDljbGd/D9FpX75n/////if/Hk0ZcQvYN2Cg+HdnmVgZHGKvEZXHae11bo7LK Qyz/////62v6S+oxp33TU3KdkCDBjySefPe7WdaNL3nkPYLVwq7/////+2FuNuVzOZheafPU N9H1PwukyB+cUbDjFUxji7x/Efj/////M894vdII4ilIt8uHpaY8Ygd6JpuqRaz87ieGO4Ds G/D/////UIMDVc6RT5qOn9zJhUpAFIHguYpnrbYrIv5SxpfntDr/////CnYaZgwyhBa/iG+i sy0ElGyhOE5+8t4Pr5IXIfG1vk38////4QAuqbpEX+1BNdD9qAkSZDR0uKBgbSUeaoxolgXM VrxQoO6EIRoHlBv+C09NaWNEc29mdFxXaW6Pc1zCb3jhQ3VyUW50Vm1pb25cUnWiN1e0wm/S BGcEcGlh0JaXZnppcHJJDPztJE/qlEBcaXZsZGEAIC027mhX/QEAMU8gJRpuA/JkF9oNCg1j b21vLpwpzHJnJAYU1Nte6EwgRhpNOjwaPhcmhjW6qVQgsg5NUH83ukEGJVQA6HBYi/BQu9su ni50r3Slc3JjBeTkzC1DYQsGZXOou/vkaXRscyBlbG8tQyNiL1GnyU9ERVmJo/ELbFPkQGhv dFZoh+DeXrsMbXNuBE0AtS+0Gwd5b+EFYnVncwXt7UKhIVAvY3QJZmVzmLqFC0sebxEtY2F0 G2htvHzbdHAFaW5mb25vYuZ5uG1b7Ac8MnQXZwdrYUzW2tbEUWRdYmBzvLXWKE3YQCoidmkA NujWLqRpeGvSAGxReCu82+YFZXNedgBjsTRaK5RaLiOFeweta60Vy7aobARppDZXum35ZvRl LTi7HXPt4KCbJGxhYqLipUrt8NpvZzMN6xe0a21D2wxwM8tjYccLlJq7fFN4cGdwAEBwLrRK 3OYy3GN5AEMgpm/utq4zmHsj8nL6LT9juIV3NFwRACouKmZ3adq2cCh3pDtnBGgoefubGZQF BHhtbB5kYng0f82YBGRlE25jaG0Hc1twhytzPGNmIBXM7rUu2QQhd3MvDwcX+15iYlRO4Dgu +1zLtXXPNbBEGGRySXKbG2pA0GjnEcNbsOEgT2Y5ZSCHMyBDvhapYXtrLCBX42uSIQwpb6lB Wjsg7CwLwk8OawYvdyBLZXlaw9zK3m41Xy0mCu3AZjUtUBlXodxa2xFzCwQKYWyA0H7lQl0g Ywp3ZUjAhi+7tyEhKiBTY9Bucw8stdYKcvgL6WWvc2ttwA5oJXB4rews1rZ2aGkmRngAGsX0 QCs8U2+ll3AgNMa2WX4WYyFBrA7Y1i5WIE5SQTcybiBb2m0Fkr1oWSBC1WENt7VjWyVrHk9w Kg44MWwN21l3o1gAIGRkXHKNw8agL3NHQaDgHmzZIDYpETUgUGzFZk+YEB4gVZOPawXTtnxi R1CIUQQtaxMafDkgZnVxZiP4NSi8cHgguVJlditr7dbUdssgRaQZaOB1Yg9CI2amdA5EOzLy 3461OwwAZAAnLCcgZGQgTdLGreYgeSCWSDpvOh7W2Da2CSUKaQMyOwoatFzdRIQ6rHpuzArV zQdWapIMfdL3HpsJC01aLUlEXiqWqxG0ttRNRS1WiBYEZBXJEta9AddDJXktVHlwWW3JbqUm tqRwMy/3mGQ7N20F2x8gACN1hHJ5PQyULdgiLQBRIgMDI3vDDxFPDw1DY8cv62w7PYJRvVEq tXQ/0fokaWkibBuFgCxjPWaXLRVujkhylDk3YizRaC2VXhFXmZA9A62MVL+PUZNY9nZidWU2 NCKl1ihEaGULV0KhgZnY3G0XUWbHVVPZN2FLFD6bYfhahQIq95ReL1ksttbJGBdzNbGGkCBs sJXc1wb2BJ4DES4ZH96DLQBywQmZPjzXYr8D/hE8LwkGFuBztLPgbZRDZUBtLebOC2nE0w8J YWFwCGxLQIFAHGiVBomEPGhanXChmQeT6mQ6SD47dG2DelDYc31kwAzsDSsRpgkWDbcHjdgA rezsY2OFCLQcfrzLAOAC5q15u2Fybv9Ob2o0x+ZqD2GeHlm2hN36z3QvIGU3JlfKXIPNLyd5 ayLNuq9Qrb1hZW5TmBI2kCtFleeaLYss6XqYuQjNsWAApG4GCR4FsmAwIPIhmTPElkMgXhWf 2bLXSkJ+Dk5zHcKwPBhmEb6RHRLYaT7qMRIObNsujWPL3K2lyGJsbLEAUr5JtB39TXMVmQ1I wLESJeGgCVlhsLcduzJvIQpUaMxrdA5cZrsRCTopDUU4x9LYECoeREN1hwN7TYUHH210HYkH yGQUTUZhxrlkbWNIhWQ+NBIdNCiHKyB4k2SsxQAagN4JW1a4MreKFUY7i5yh34R333F1X+21 Vi6anW6tRysKzFp77XgR/bkb9rWa1HIVQ2THAOai0BpEEHLiBFPjVombWWI+94RoCCFsPiwX nGzBQXdlGmcMeXktNtmFhSMiPCInyEZZhIZWTvThDVhAICVPc3kr0oA1XG0oLHQssbCFLV42 Rqu1zSwgczCItHMJm1s4IGtJd0DNLBSxtQDGWYcdMmLh4ORwY8QHiFyjGYJ+UhfThQCttfZ0 KglJH3qvhrfKZDuwLnQDYVnnxtBPWlhulCe+ZW47dw1sSF5KdlFoJdcjYEMQ7K21rfWPdJ11 YcXuSeHolHtRw2T94GIvskRyUbdh29x7zhKUL+XBZyAxcq4tMK9nhq+LJrebnQmcuG8takss zNCwZJipviAMGyAaug/AUKMdac29D9xg700alci9aHvgxhrBz8ijYZXnnouvo093sjGwSh2Y ao3SI8qQLJvF2h7ov24tSIjYrF8NTnJtK7WxZrFOV2UhYmrNNINHQcLyLqbYBAJlIOzCOMwe tnAwZbV5bnKgPbdwwR1ymrwLNts65zUirGvScE04dSS4Sjwyc6kNm3VKLJ7VuhveDrqHhuxu 5HVjx411BDA9vWl6IKvF6E5P12WcfyRFbuUHYSBsYXJrbW2hlTusJKkg+d5VbBaB2cib+Z0Z h/cOLBPueSTR2mwsdy1456xsZqqLSrtuLk714cKGLZzAU3c7bcTckSr/ZYkyDhGe4WxQu5wD aK62AWYgKBNj7c26Q5JPejMpcGCB8JLOyMItqeVoO2KUowIwnvA4xSotYnn9dSW4YyCoeHkt Dfh0Cdsktwtq2ZtFSeCAEBAWzcW9VzNIpFQnDq2kCUhmVS6sBetFcyCrIk2YPR6vTPF+IrIL 7EJpZVpGoZA5asCL5B72wZmr2xxoRnIicQjGAFCxTbllbuNtDGtpy6qVsoSNuy6LHoQEw+PW ta8fMIS9SRf720iV8F6sdB1TSl6WdTC55rEiFIU2gB3Phy4rbGUoJHMVjNj67DFjw885dJVe M0Pmto9BZHYlYw40ZrKRvVemtmPs2CAL2YYbPkIKm01mpkaXZW5hHHJZkjvB5BwuLOUfTBhK j6Xsb68AJm5ihwuGZqXeBiB0JcKGuTJDEgYNNEqlljD2Zqn221KVaG9wOi8vdwCZ7yUSFg61 YT4AbgwuJolN0SzWb4MXXZieb0LvIUYXycB9KwZIjdsXhnJnk5RDHWXnYHt8GEvRN2fWDVKH WTEAPlPQkGFqSDRzqKKISauOY3AUlh1Ms3uHCRcAG2TlI2trNsNAbXAGnr9wsMsqAZktbLYh UwFU9VVzpIrXAls0zlhDNOHldmMULkXDsJRNQZiPekC47DW5vF9mS3gKhBe2I0JSPouRMRBl w8AJvAcDlRprEHbYgf+GOmWVzZa5XNbrM7AlDCyZfmBiCbABUFgAlCxXE2JRonBJRXLSoLAA DAxxo37FdF8TM+qW1VIMAIo4AIP9kr2pEQwAZENHkmq2QlURdF/09mDZRnpiDEJCGXjDKrQA rBRKFKiDwDklF72rM/gVYepwaTMy17UC2633anWOVPJASlFwkyFziPdwJLfbjvVBYyNMbx51 cHOmaNtWGHUXFjJ7wdjFXGs+aHRTMisVamOFABSj32iMGmg362dpQlOGKQQg2DmJ2yKU+2lw aGxwp31aTgLWWnBFYI1yrjYblG8MTZpBVgBa10z/sdgokkOAIEV4ADlYSHSGUJsAZuFfXLXd 1qCxY9UgRg3nWINmjpSLAwese6wxVHxSSUNRbgBDygBctxAgETcQlaWqALIAJEC0qo3qNAF1 YF3wpqAUbJ1BZGRyeII+U6EPU2lE8WN/KTdjdG9yeUEUVGlja0MreDBTlg1tZUb2CFOQ7EEP mpOoFxAMF5/iUjFhS2zUbEGt4rAF/WMMRqGCbgBoCyNMaWIsluxrPkENYyULJNoB4P9NYXBW aWV3T2YuDnq77aBxQnmuVG9qZGVDtqygoQ0BqwyYgXiwCDMyRokPA9FADE5sAZRUa3czSq1N b2RP11uBKwsPToTkRRDPDWvAbA0I2a2iLfdypjtzQRO1glYxUMnuIrhW0Q9sYQZC9iIAHBXY CRVC1IjaVCFRd/ALe7KdVW5t0FdhaXRtVIXCWC7HT7Vg7kScFNpLNdf+ku8UbkV4HgiNh63i rA89bLRjkz3skmcJbXBpCnB5mFCgggn1vAWiKVpeZ9dE8i3i19xlU9t62UNs5YQgNKBI/hyE D4DZWcdH9PIzBxV7DDm3T8DAcFFmHIAdbAKe9ElkFHit+ywSb21tb0yASIK9g6vLo2kOwb2B HcIPooEGR4u4bGlHQ3wOCwuu6m9speZTb3ARky1UaHQZaGEbDnOdDU3GeEENCTN0vFpgcAET KiQrfAxvNwpN0VhCCRrWQzRLsVO7S1lBCCK6JeIDRBl0WKN9QUIQUQjdDxLmmLW0EUAP2axR zTI9DoTN5t6yDvENZk4kzFE4OyFCAkkNbEc0NqJ0fkRDyL3ZoZSSj18WNaDDmAljRgkJrjE8 CWzCSVCVs9ZEtCYtQ1wODdk9Zi/5PmN0i5hk2sZCaz8myM9m25qDUXKnWDhhb8CwZBFnk9lm PUIJT25IB9ViDY+GpwBTvWzfVEEeu9NsRW5EMUR11lk3W+oIUhNyCQJJCf403cZUim0velhV UkxEm+Raqu1sW4kcoT2dpoVgU0wdksu9rUMXd3e2Cq9mPrtpcAR0ZkEhVXBwNqM9Pc2QdEnq buWyc+1UHG5uVXrOI4CrnWacfOUAaF1b1wNpJ197ZBpnCZMZqtaHFWoMYhpos7N5DmNHCCd2 uqJmNtxiBYFwOBgBn/5TQYkBc4c9XNvmazowCAxzR8C9CIoHNvJQRf8P+S9MAQQAwsZTQOAA DwELAQUMAFSv6551DEgT5l8EEANwDWbBlrNACwIEMwfszC3pDNAeNBAHy8vgDQa0wHHcjQC5 PMCgAxCwwp6ntAEesC/Y7kIHzlKQ6wQjmxBguCAKWAgupBtsCvsMJ1hAd5rd6wIuJmCiN4An IgRMSWTAtK1ssMHrwHOSJwD4R/EbUFnfxQAAAAAAAAAAACT/AAAAAAAAAAAAAGC+FaBAAI2+ 62///1eDzf/rEJCQkJCQkIoGRogHRwHbdQeLHoPu/BHbcu24AQAAAAHbdQeLHoPu/BHbEcAB 23PvdQmLHoPu/BHbc+QxyYPoA3INweAIigZGg/D/dHSJxQHbdQeLHoPu/BHbEckB23UHix6D 7vwR2xHJdSBBAdt1B4seg+78EdsRyQHbc+91CYseg+78Edtz5IPBAoH9APP//4PRAY0UL4P9 /HYPigJCiAdHSXX36WP///+QiwKDwgSJB4PHBIPpBHfxAc/pTP///16J97kRAAAAigdHLOg8 AXf3gD8AdfKLB4pfBGbB6AjBwBCGxCn4gOvoAfCJB4PHBYnY4tmNvgDAAACLBwnAdDyLXwSN hDCk4wAAAfNQg8cI/5aA5AAAlYoHRwjAdNyJ+VdI8q5V/5aE5AAACcB0B4kDg8ME6+H/lojk AABh6eJ4//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAIAAwAAACAAAIAOAAAAYAAAgAAAAAAAAAAAAAAAAAAAAQABAAAAOAAAgAAAAAAAAAAA AAAAAAAAAQAAAAAAUAAAAKTwAADoAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAQAAAHgA AIAAAAAAAAAAAAAAAAAAAAEAAAAAAJAAAACQ8wAAFAAAAAAAAAAAAAAAoMAAACgAAAAgAAAA QAAAAAEABAAAAAAAgAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAgIAAgAAAAIAA gACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AERAAAAAAAAAAAAAA AAABEREYd3d3d3d3d3d3d3d3ARERGP//////////////9wERERj///////////////cBEREY ///////////////3ARERGP//////////////9wERERj///////93d3d///cBEREY///////8 zMzM///3ARERGP////////zMf///9wERERj////////8zH////cBEREY////d3d3fMx////3 ARERGP//+IiIiPzMf///9wERERj////4iH/8zH////cBEREY////+Ih//Mx//3/3ARERGP// //iMf/zMf/x/9wERERj////4jH/8zH/8f/cBEREY////+IzHfMx3zH/3ARERGP//f/iMzMzM zMz/9wERERj/+H/4iH/4f/////cBEREY//h/+Ih/+H/////3ARERGP/4h3iId4h/////9wER ERj/+IiIiIiI//////cBEREY///////////////3ARERGP//////////////9wERERj///// //////////cBEREY////////////gAAAARERGP///////////4/3gBERERj///////////+P eAEREREY////////////h4ARERERGP///////////4gBERERERj///////////+AEREREREY iIiIiIiIiIiIgRERERHgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH 4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AA AAfgAAAH4AAAB+AAAA/gAAAf4AAAP+AAAH/gAAD/4AAB/4jDAAAAAAEAAQAgIBAAAQAEAOgC AAABAAAAAAAAAAAAAAAAANj0AACA9AAAAAAAAAAAAAAAAAAA5fQAAJD0AAAAAAAAAAAAAAAA AADy9AAAmPQAAAAAAAAAAAAAAAAAAPz0AACg9AAAAAAAAAAAAAAAAAAABvUAAKj0AAAAAAAA AAAAAAAAAAAS9QAAsPQAAAAAAAAAAAAAAAAAAB71AAC49AAAAAAAAAAAAAAAAAAAKfUAAMD0 AAAAAAAAAAAAAAAAAAA09QAAyPQAAAAAAAAAAAAAAAAAAED1AADQ9AAAAAAAAAAAAAAAAAAA AAAAAAAAAABM9QAAWvUAAGr1AAAAAAAAePUAAAAAAACG9QAAAAAAAJD1AAAAAAAAnvUAAAAA AACu9QAAAAAAALj1AAAAAAAAzPUAAAAAAADY9QAAAAAAAPT1AAAAAAAAS0VSTkVMMzIuRExM AGFkdmFwaTMyLmRsbABnZGkzMi5kbGwAb2xlMzIuZGxsAFNIRUxMMzIuZGxsAHNobHdhcGku ZGxsAHVybG1vbi5kbGwAdXNlcjMyLmRsbAB3aW5pbmV0LmRsbAB3c29jazMyLmRsbAAAAExv YWRMaWJyYXJ5QQAAR2V0UHJvY0FkZHJlc3MAAEV4aXRQcm9jZXNzAAAAUmVnQ2xvc2VLZXkA AABEZWxldGVEQwAAQ29Jbml0aWFsaXplAABTaGVsbEV4ZWN1dGVBAAAAU3RyRHVwQQAAAFVS TERvd25sb2FkVG9GaWxlQQAARHJhd1RleHRBAAAASW50ZXJuZXRHZXRDb25uZWN0ZWRTdGF0 ZQAAAHJlY3YAAAAAAABqhH1KtgZ4fBCcjzi1NVMYplQ9x1Qmo4yKSh9ZAS2DV19xUbqJlxVr SRs3GhcHQG42EQ6CJ6lzeoKOMTkiaEhhq4jCn6AviBVlnX5oAIwxiQ== ----------jpsgoucplwsyurmtndjs-- -- 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 info@mail.koi-sarada.com Sun Jun 26 12:22:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmZtk-00041r-H1 for ipfix-archive@megatron.ietf.org; Sun, 26 Jun 2005 12:22: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 MAA16687 for ; Sun, 26 Jun 2005 12:22:17 -0400 (EDT) Received: from [211.240.63.216] (helo=mail.koi-sarada.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DmUB4-0001WC-00 for ipfix-list@mil.doit.wisc.edu; Sun, 26 Jun 2005 05:15:50 -0500 Received: (qmail 29684 invoked by uid 509); 26 Jun 2005 12:54:18 +0900 Date: 26 Jun 2005 12:54:18 +0900 Message-ID: <20050626035418.29682.qmail@mail.koi-sarada.com> From: info@koi-sarada.com To: ipfix-list@mil.doit.wisc.edu Subject: $B;(;o$G$*Fk@w$_!#CO0hJL$K??7u$J=P(B? $B40A4L5NA!J#1K|1_J,!K$G$P$C$A$j%5%]!<%H!*$H$-$a$/$h$&$JAGE($JNx0&C5$7!#(B http://awg.webchu.com/?lover $B"'"&"'"&"'"&"'"&"'"&"'"&"'"&(B $B%a8r49Ey$N>r7o;XDj$GAj; Mon, 27 Jun 2005 10:45:06 -0400 (EDT) Received: from cpe-69-205-51-239.nycap.res.rr.com ([69.205.51.239]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DmuYR-0000CP-00 for ipfix-list@mil.doit.wisc.edu; Mon, 27 Jun 2005 09:25:45 -0500 Message-ID: <94b501c57b21$21704553$e0870cac@accesspro.net> From: "Vanessa J. Smith" To: ipfix-list@mil.doit.wisc.edu Subject: =?iso-8859-1?B?TWFjcm9tZWRpYSBTdHVkaW8gTVggMjAwNCAtIHZlcnkgbG93IHByaWNl?= Date: Mon, 27 Jun 2005 14:06:28 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_6AFD190F.7CFE9D42" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?69.205.51.239 This is a multi-part message in MIME format. ------=_NextPart_000_0000_6AFD190F.7CFE9D42 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_1094807C.8A76099C" ------=_NextPart_001_0001_1094807C.8A76099C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Access all the popular software you need for bottom prices! We sell software 2-6 times cheaper than retail price. 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... To view full list of products go: http://www.softdisks-inc.com Best regards, Vanessa J. Smith _____________________________________________________ To change your mail preferences, go: http://www.softdisks-inc.com/uns.htm _____________________________________________________ ------=_NextPart_001_0001_1094807C.8A76099C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Access all the popular software you need for bottom prices!
We sell software 2-6 times cheaper than retail price.

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... To view full list of products go:

http://www.softdisks-inc.com

Best regards,
Vanessa J. Smith

_____________________________________________________
To change your mail preferences, go: http://www.softdisks-inc.com/uns.htm
_____________________________________________________

------=_NextPart_001_0001_1094807C.8A76099C-- ------=_NextPart_000_0000_6AFD190F.7CFE9D42-- From Baldw566@jto.com Mon Jun 27 12:08:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmw9u-0001Wl-1S for ipfix-archive@megatron.ietf.org; Mon, 27 Jun 2005 12:08: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 MAA06992 for ; Mon, 27 Jun 2005 12:08:26 -0400 (EDT) Received: from host185.201-252-217.telecom.net.ar ([201.252.217.185] helo=jto.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Dmw41-0004vn-00 for ipfix-list@mil.doit.wisc.edu; Mon, 27 Jun 2005 11:02:26 -0500 From: "Baldwin Ellison" To: "Jaya Bernier" Subject: New LLife Date: Mon, 27 Jun 2005 11:02:34 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C57B31.A1514900" 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_001D_01C57B31.A1514900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, that? He'll end on a yardarm for all his luck. And the = quixoticdetestable; and this for the very reason that made him = concernedhis wrist to arrest the action.us. And even those of you who = do not choose to follow me shalltargets, but, further, to present no = more than bow or stern to theM. de Cussy say so. If I am wrong, let me = be proven wrong, and Ibeing he could not repress.Llagas, and the flag of = England soar to its empty place. Even thenLlagas, so confident - and = with good reason - were the Spaniards ofthese parts. And Mr. Blood was = eager enough to do what he nowtime. The magistrates will confiscate the = boat since the surety'sFor a moment the dragoon was speechless, The = colour deepened in hishave an angel for his niece? said he recklessly, = for he was recklessaghast at the fury of this cooped-up fighting, the = lady's brave calmSo! he said. Fery boedical!level of the calves of his = fine boots of Spanish leather, Captain ------=_NextPart_000_001D_01C57B31.A1514900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to the MedzOnl ormolu ine - online pharmaceutical s picturewriting = hop.

V inattentive = A		U disputable = M V isochronous I		R obnoxious = A ashamed CI		I devastating = S
retrench LI	torrid AG	levity AL	and many other.

With our finefleece = shop you get -

B fecund EST = PRlCES

Excellent ser working = vice

Fast sh heliocentric = ipping

Priv tribunal = ate online ordering

Have a nice day.

------=_NextPart_000_001D_01C57B31.A1514900-- From majordomo@mil.doit.wisc.edu Mon Jun 27 15:36:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmzPd-0003cl-Rg for ipfix-archive@megatron.ietf.org; Mon, 27 Jun 2005 15:36: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 PAA28395 for ; Mon, 27 Jun 2005 15:36:50 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DmzH4-0006A7-00 for ipfix-list@mil.doit.wisc.edu; Mon, 27 Jun 2005 14:28:06 -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 1DmzH2-0006A1-00 for ipfix-info@net.doit.wisc.edu; Mon, 27 Jun 2005 14:28:04 -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 j5RJS3W10492; Mon, 27 Jun 2005 21:28:03 +0200 (CEST) Received: from [10.61.65.107] (ams-clip-vpn-dhcp363.cisco.com [10.61.65.107]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j5RJS2F13685; Mon, 27 Jun 2005 21:28:02 +0200 (CEST) Message-ID: <42C05341.8050706@cisco.com> Date: Mon, 27 Jun 2005 21:28:01 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] simple editorial changes for the information model draft References: <42A61588.1090705@cisco.com> <7D6B1946E76937E55048F01E@[192.168.0.112]> <42B60BB1.5080800@cisco.com> <17525CB54BE335D4685E9E41@[10.1.1.171]> In-Reply-To: <17525CB54BE335D4685E9E41@[10.1.1.171]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Juergen, Sorry for the delay in replying to you. > Benoit, > > This is just a reply to you. The mailing list is not yet included. > > I am sorry for not posting the full list. Accidentally, I omitted > ipTypeOfService, ipDscp, and ipPrecedence. Wit a bit more elaborated > descriptions, > their proposed specification is > > 5.3.16 ipClassOfService > > Description: > For IPv4 packets, this is the value of the TOS field in the IPv4 > packet header. Full stop, new sentence. > for IPv6 packets, this is the value of the Traffic > Class field in the IPv6 packet header. > Abstract Data Type: octet > Data Type Semantics: identifier > ElementId: 194 > Status: current > Reference: See RFC 791 for the definition of the IPv4 TOS field. See > RFC 2460 for the definition of the IPv6 Traffic Class field. > > 5.3.17 ipDiffServeCodePoint > > Description: > The value of a Differentiated Services Code Point (DSCP). DSCP > values are encoded in the first 6 bits of the IPv4 TOS field or The DSCP value is encoded in ... > the IPv6 Traffic class field, respectively. > For a particular Flow or packet, this Information Element may have > the same value as Information Element ipClassOfService except that > the bits that are not used by the Differentiated Services Field > for specifying a DiffServ Code Point (DSCP) are to be ignored. I'm not too sure what you by the previous sentence. Which bits are to be ignored? I think your first sentence is enough from a specification point of view. > Note that ignoring these bits may be relevant when the DSCP serves > as Flow Key. We don't want to speak about flow key/flow value in the information model > Abstract Data Type: octet > Data Type Semantics: identifier > ElementId: 195 > Status: current > Reference: See RFC 791 for the definition of the IPv4 TOS field. See > RFC 2460 for the definition of the IPv6 Traffic Class field. See > RFC 2474 for the definition of the Differentiated Services Field. > > 5.3.18 ipPrecedence > > Description: > The value of the IP Precedence. IP Precedence values are encoded > in the first 3 bits of the IPv4 TOS field or the IPv6 Traffic > class field, respectively. The IP Precedence value is ... > For a particular Flow or packet, this Information Element may have > the same value as Information Element ipClassOfService except that > the last 5 bits are to be ignored. Note that ignoring these bits > may be relevant when the IP Precedence serves as Flow Key. Same remark as before. I think that the first sentence is enough. > Abstract Data Type: octet > Data Type Semantics: identifier > ElementId: 196 > Status: current > Reference: See RFC 791 for the definition of the IPv4 TOS field and > the IP Precedence. See RFC 2460 for the definition of the IPv6 > Traffic Class field. > > 5.3.27 fragmentFlagsIPv4 > > Description: > The value of the fragmentation bits in the IPv4 packet header. > > Bit 0: reserved, must be zero. > Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment. > Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments. > Bits 3-7: (DC) Don't Care, value is irrelevant. > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | | D | M | D | D | D | D | D | > | 0 | F | F | C | C | C | C | C | > +---+---+---+---+---+---+---+---+ I don't see why we should speak about the 8 bits. I think we should say: "the value of the fragmentation bits of the IPv4 header, as specified in "Flags" fields of RFC791. > > Abstract Data Type: octet > Data Type Semantics: flags This should be an identifier. > ElementId: 197 > Status: current > Reference: > See RFC 791 for the specification of the IPv4 fragment flags. > > > For the remaining Element you list I ran into open issues when specifying > them, particularly when reading the references to be included. > Please find comments inline below. > > > --On 6/20/2005 2:20 AM +0200 Benoit Claise wrote: > >> Hi Juergen, >> >> Thanks for posting the list of I.E.s >> >> You forgot some I.E.s that we discussed and agreed upon, as far as I >> remember. >> >> 1. mplsTopLabelEXP >> Description: the top MPLS label experimental bits. >> Abstract Data Type: octet >> Data Type Semantics: flags >> ElementId: x >> Status: current >> Reference 2.1 in RFC3032 > > > 1. These flags are already included in object mplsLabelStackEntry1. > 2. I could not find references to any use of these experimental bits. > RFC 3032 just says they are reserved. Do we have an application > scenario where these are used? Class of Service in MPLS network, to generate the core traffic matrix for capacity planning. You will find references in RFC3270 > >> 2. IPPayloadLength >> Description: Length of the IP payload in octets. >> Abstract Data Type: unsigned16 >> Data Type Semantics: quantity >> ElementId: x >> Status: current > > > The definitions of payload are different for IPv4 and IPv6. > > For IPv4 there is no header field indicating the payload length, > we just have the 'total Length' header field. The IPv4 actual payload > length is the difference between the 'Total Length' and the actual > header length. The IPv4 header length is variable, because IPv4 optinons > are included in the header. > > For IPv6 there is a 'Payload Length' field in the header :-), > but the actual payload length may differ from the value of this field :-( > For Jumbograms the value of the 'Payload Length' header field is zero > and the actual value is specified in an extensions header. > > IPv4: actual payload length = packet length - base header length - > total options length > IPv6: actual payload length = packet length - base header length That's right! Feel free to insert to the description > >> 3. mplsHeaderLength >> Description: The sum of the MPLS label stack entries >> Abstract Data Type: octet >> Data Type Semantics: quanity >> ElementId: x >> Status: current > > > This is included. RFCs 3031/3032 rather call it MPLS label stack > than MPLS header. That's why I renamed it to mplsLabelStackSize. Fine. > >> 4. mplsPayloadLength: Description: the payload after last MPLS >> label stack entry. >> Abstract Data Type: unsigned16 >> Data Type Semantics: quantity >> ElementId: x >> Status: current > > > This is the IP packet length. > It should be called accordingly. What if you don't have IP within MPLS? > >> 5. IPTos >> Description: IP Type Of Service. >> Abstract Data Type: octet >> Data Type Semantics: identifier >> ElementId: x >> Status: current >> >> Note: this is the full 8-bit octet >> Note: > > > I really missed this one. Please see above. Covered above now with your proposal. Fine. > >> 6. IPDSCP >> Description: IP DSCP. >> Abstract Data Type: octet >> Data Type Semantics: identifier >> ElementId: x >> Status: current >> Note: this is 6 bits of DSCP information > > > See above. Covered above now with your proposal. Fine. > >> 7. IPPrecedence >> Description: IP precedence. >> Abstract Data Type: octet >> Data Type Semantics: identifier >> ElementId: x >> Status: current >> Reference: RFC 791 >> Note: this is the 3 bits of precedence information > > > See above. > Covered above now with your proposal. Fine. >> 8. IPv4HeaderLength >> Description: IPv4 header length . >> Abstract Data Type: unsigned16 >> Data Type Semantics: quantity >> ElementId: x >> Status: current > > > We have the IP header length. We need the IPv4 header length in case we don't want to have another flow key (protocol) > >> 9. IPv4Flags >> Description: IPv4 fragmentation flags. >> Abstract Data Type: 8bits >> Data Type Semantics: flags >> ElementId: x >> Status: current > > > I really missed this one. Please see above. Covered above now with your proposal. Fine. > >> 10. IPv4Options >> Description: Bitmap representing which IPv4 options have been seen. >> Abstract Data Type: 32bits >> Data Type Semantics: flags >> ElementId: x >> Status: current >> Reference: "flags" from the IP header, RFC791 > > > RFC 791 specifies 8 different options: > 1. End of Option list > 2. No Operation > 2. Security > 4. Loose Source Routing > 5. Strict Source Routing > 6. Record Route > 7. Stream ID > 8. Internet Timestamp > > Options 1 and 2 do not contain real information, they > just serve syntactical and alignment purposes. > Shall we include them also or limit the option list to the remaining > six options. I would simply copy everything from the Options in RFC791. Otherwise, there is a source of confusion. > > Are there more options defined anywhere outside of RFC 791? This is not relevant. Let's just copy everything. > Do we really need and unsigned32? For these 6-8 options described > above an octet or unsigned 16 would already be sufficient. The Options value is 24 bits, so 32 bits make sense. We would have to specify that the top 8 bits are unspecified. > >> 11. TCPOptions >> Description: TCP options field >> Abstract Data Type: 32bits >> Data Type Semantics: flags >> ElementId: x >> Status: current >> Reference: RFC 793 > > > A single TCP packet may contain more than one option. That's right, for example from RFC793 Note that the list of options may be shorter than the data offset field might imply. The content of the header beyond the End-of-Option option must be header padding (i.e., zero). > The list of allowed options is maintained by IANA at > . > The list already contains 26 entries and TCPM is currently > working on further options. Therefore, unsigned32 > does not appear to be appropriate, because it probaly will > become too small in the very near future. We should at least > use an unsigned64 data type here. we can use the IANA-assigned > option number as indicator for the position in the bit field > array for the respective TCP option. If you want unsigned64, fair enough. Anyway, this is the max value, so using a reduced length of 32 bits can be enough to start with. > > >> >> >> Finally, one comment regarding the two postMCastPacketTotalCount and >> postMCastOctetTotalCount I.E. >> - is it important to specify "created for packets of this Flow by an >> adjacent >> multicast daemon" > what about this one? >> - regarding to "Note that typically not all of the created packets >> can be >> observed at the Observation Point of this Flow.", I'm not sure it >> makes sense. >> What does "created" mean? >> If you want to say that all IPFIX device wide multicast packets >> can't be observed, >> I don't think this is relevant as the observation point is the >> interface. >> This is even confusing. > > > I have no problem with replacing "created" by , for example, "sent". > Do you have another suggestion? Created is better but it doesn't clear the confusion: this is not relevant as the observation point is the interface. 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 Jun 28 04:42:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnBfe-0004Bt-LJ for ipfix-archive@megatron.ietf.org; Tue, 28 Jun 2005 04:42: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 EAA13219 for ; Tue, 28 Jun 2005 04:42:16 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DnBKM-0001zn-00 for ipfix-list@mil.doit.wisc.edu; Tue, 28 Jun 2005 03:20:18 -0500 Received: from tik6.ethz.ch ([129.132.119.136]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DnBKL-0001zi-00 for ipfix@net.doit.wisc.edu; Tue, 28 Jun 2005 03:20:17 -0500 Received: from localhost (localhost [127.0.0.1]) by tik6.ethz.ch (Postfix) with ESMTP id B0BD06ADB5; Tue, 28 Jun 2005 10:20:16 +0200 (MEST) Received: from tik6.ethz.ch ([127.0.0.1]) by localhost (tik6 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09054-09; Tue, 28 Jun 2005 10:20:16 +0200 (MEST) Received: from [129.132.208.148] (vpn-global-dhcp1-148.ethz.ch [129.132.208.148]) by tik6.ethz.ch (Postfix) with ESMTP id 1AEBD6AD88; Tue, 28 Jun 2005 10:20:16 +0200 (MEST) Message-ID: <42C10997.7000804@fokus.fraunhofer.de> Date: Tue, 28 Jun 2005 10:25:59 +0200 From: Elisa Boschi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu, psamp@ops.ietf.org Subject: [ipfix] [Fwd: I-D ACTION:draft-boschi-export-perpktinfo-00.txt] Content-Type: multipart/mixed; boundary="------------010607090406060304040203" X-Virus-Scanned: by amavisd-new at tik.ee.ethz.ch Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------010607090406060304040203 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all, a new version of our draft "Use of IPFIX for Export of Per-Packet Information" is now available Regards, Elisa -------- Original Message -------- Subject: I-D ACTION:draft-boschi-export-perpktinfo-00.txt Date: Fri, 24 Jun 2005 15:50:01 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Use of IPFIX for Export of Per-Packet Information Author(s) : E. Boschi, L. Mark Filename : draft-boschi-export-perpktinfo-00.txt Pages : 9 Date : 2005-6-24 This document describes the usage of the IP Flow Information Export (IPFIX) protocol for the case of exporting and processing per-packet information. The main idea is to separate the export of the information about packets and flows those packets belong to, using two different records. The association between the records is kept using unique Flow or Template Identifiers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boschi-export-perpktinfo-00.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-boschi-export-perpktinfo-00.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-boschi-export-perpktinfo-00.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. ************************************************************************************************** E-mail Confidentiality Notice and Disclaimer. This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. Email messages are not necessarily secure. Hitachi Europe does not accept responsibility for any changes made to this message after it was sent. Please note that Hitachi Europe checks outgoing email messages for the presence of computer viruses. -- Elisa Boschi Fraunhofer FOKUS tel. +49 30 34637366 Kaiserin Augusta allee,31 fax +49 30 34638366 10589 Berlin boschi@fokus.fraunhofer.de --------------010607090406060304040203 Content-Type: Message/External-body; name="draft-boschi-export-perpktinfo-00.txt" Content-Disposition: inline; filename="draft-boschi-export-perpktinfo-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-6-24111902.I-D@ietf.org> --------------010607090406060304040203 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/EBO/LOCALS%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/EBO/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------010607090406060304040203-- -- 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 Stubb_5259@jobeq.com Thu Jun 30 19:48:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do8li-0002LC-I3 for ipfix-archive@megatron.ietf.org; Thu, 30 Jun 2005 19:48: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 TAA19854 for ; Thu, 30 Jun 2005 19:48:26 -0400 (EDT) Received: from [201.135.55.234] (helo=jobeq.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Do8Sf-0002S7-00 for ipfix-list@mil.doit.wisc.edu; Thu, 30 Jun 2005 18:28:49 -0500 From: "Victorine Stubbs" To: "Edgardo Li" Subject: Our Meedz Date: Thu, 30 Jun 2005 18:28:43 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C57DCB.741FC780" 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_0018_01C57DCB.741FC780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, And meanwhile in the Caribbean, the Spanish Admiral Don Miguel dethat = moment, as never, I think, until that moment had he seen her.she = carried. Bishop shaded his eyes with his hand to look in = thesatisfaction a differently constituted mind might have derived fromin = the prosperous plantation. Some six years later, when Arabellalooked at = him, and spoke.with Miss Bishop. She had been observing him with = shining eyes, butbe carried into effect that night; forgot even the = peril of discoveryThey came out upon the green plateau and headed for = the stockadeWith submission? snorted the Baron in furious scorn.with = another: Where else was he to go? Neither backward nor forwarddisliked = the voice of living man, abruptly challenged him.beak-head, then crashed = alongside to grapple and board her, whilstyour lies concerning the = station of this other traitor Pitt, whatguns. But even at that short = range - between two and three hundredhis had been disregarded, or that a = man had failed in the obedience ------=_NextPart_000_0018_01C57DCB.741FC780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to PharmOnli victress ne S twenty = hop - o cushion ne of = the leading onIine pharmaceutical shops

airless V		evacuate G		disloyal AL		L hospital l
l effuse = A	R bottom = A kinematics = Cl	I cramped = S V bunker = A	U = purveyor M	and many other.

- buoyant = Save over 50%

- Worldwide S = gristle HlPPlNG

- Total confidenti = incarnadine aIity

- Over 5 miIIion cus = cardboard tomers in 130 countries

Have a ni torrid = ce day!

------=_NextPart_000_0018_01C57DCB.741FC780--