From ipfix-bounces@ietf.org Fri Dec 01 05:03:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq5EV-0007T7-D7; Fri, 01 Dec 2006 05:03:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq5CT-0005Xm-Cf for ipfix@ietf.org; Fri, 01 Dec 2006 05:00:57 -0500 Received: from tama55.ecl.ntt.co.jp ([129.60.39.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq5CR-0003Sx-Hy for ipfix@ietf.org; Fri, 01 Dec 2006 05:00:57 -0500 Received: from mfs34.rdh.ecl.ntt.co.jp (mfs34.rdh.ecl.ntt.co.jp [129.60.39.114]) by tama55.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1A0siA021728 for ; Fri, 1 Dec 2006 19:00:54 +0900 (JST) Received: from mfs34.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id BE29020AE2A for ; Fri, 1 Dec 2006 19:00:53 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 8F55D20AE29 for ; Fri, 1 Dec 2006 19:00:53 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1A0rTl009395 for ; Fri, 1 Dec 2006 19:00:53 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1A0q4Z007427 for ; Fri, 1 Dec 2006 19:00:52 +0900 (JST) Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1A0qmR007424 for ; Fri, 1 Dec 2006 19:00:52 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.96]) by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1A0pwf022404 for ; Fri, 1 Dec 2006 19:00:52 +0900 (JST) Message-ID: <456FFD58.6020302@lab.ntt.co.jp> Date: Fri, 01 Dec 2006 19:00:56 +0900 From: Hitoshi Irino User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [IPFIX] Question about tcpSequenceNumber, tcpAcknowledgementNumber, tcpUrgentPointer, tcpWindowSize X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Jurgen, and all I have a question about some IEs relate TCP, tcpSequenceNumber, tcpAcknowledgeNumber, tcpUrgentPointer, tcpWindowSize. How do an exporter decide these values? Exporter has several choices: first packet of TCP flow or last packet of TCP flow etc... Are these values a difference between value of first packet and value of last packet(, or minimum and maximum)? The descriptions of these IEs in IPFIX-INFO-14 do not provide these Information. It is better to provide more description about value, I think. regards, Hitoshi Irino -- Hitoshi Irino NTT Network Service Systems Laboratories 9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan Tel: +81-422-59-4403 Fax: +81-422-59-4549 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Dec 01 05:03:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq5EV-0007T7-D7; Fri, 01 Dec 2006 05:03:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq5CT-0005Xm-Cf for ipfix@ietf.org; Fri, 01 Dec 2006 05:00:57 -0500 Received: from tama55.ecl.ntt.co.jp ([129.60.39.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq5CR-0003Sx-Hy for ipfix@ietf.org; Fri, 01 Dec 2006 05:00:57 -0500 Received: from mfs34.rdh.ecl.ntt.co.jp (mfs34.rdh.ecl.ntt.co.jp [129.60.39.114]) by tama55.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1A0siA021728 for ; Fri, 1 Dec 2006 19:00:54 +0900 (JST) Received: from mfs34.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id BE29020AE2A for ; Fri, 1 Dec 2006 19:00:53 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 8F55D20AE29 for ; Fri, 1 Dec 2006 19:00:53 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1A0rTl009395 for ; Fri, 1 Dec 2006 19:00:53 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1A0q4Z007427 for ; Fri, 1 Dec 2006 19:00:52 +0900 (JST) Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1A0qmR007424 for ; Fri, 1 Dec 2006 19:00:52 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.96]) by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1A0pwf022404 for ; Fri, 1 Dec 2006 19:00:52 +0900 (JST) Message-ID: <456FFD58.6020302@lab.ntt.co.jp> Date: Fri, 01 Dec 2006 19:00:56 +0900 From: Hitoshi Irino User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [IPFIX] Question about tcpSequenceNumber, tcpAcknowledgementNumber, tcpUrgentPointer, tcpWindowSize X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Jurgen, and all I have a question about some IEs relate TCP, tcpSequenceNumber, tcpAcknowledgeNumber, tcpUrgentPointer, tcpWindowSize. How do an exporter decide these values? Exporter has several choices: first packet of TCP flow or last packet of TCP flow etc... Are these values a difference between value of first packet and value of last packet(, or minimum and maximum)? The descriptions of these IEs in IPFIX-INFO-14 do not provide these Information. It is better to provide more description about value, I think. regards, Hitoshi Irino -- Hitoshi Irino NTT Network Service Systems Laboratories 9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan Tel: +81-422-59-4403 Fax: +81-422-59-4549 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Dec 01 05:57:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq64o-0004ao-G8; Fri, 01 Dec 2006 05:57:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq64m-0004ZX-GN for ipfix@ietf.org; Fri, 01 Dec 2006 05:57:04 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq64l-0003Ue-6X for ipfix@ietf.org; Fri, 01 Dec 2006 05:57:04 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Dec 2006 11:56:55 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB1AuquE031282; Fri, 1 Dec 2006 11:56:52 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB1AupAJ008498; Fri, 1 Dec 2006 11:56:51 +0100 (MET) Received: from [10.61.64.7] (ams3-vpn-dhcp7.cisco.com [10.61.64.7]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA01698; Fri, 1 Dec 2006 10:56:50 GMT Message-ID: <45700A54.8010604@cisco.com> Date: Fri, 01 Dec 2006 10:56:20 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Hitoshi Irino Subject: Re: [IPFIX] Question about tcpSequenceNumber, tcpAcknowledgementNumber, tcpUrgentPointer, tcpWindowSize References: <456FFD58.6020302@lab.ntt.co.jp> In-Reply-To: <456FFD58.6020302@lab.ntt.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1158; t=1164970612; x=1165834612; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Question=20about=20tcpSequenceNumber, =20tcp AcknowledgementNumber,=0A=20tcpUrgentPointer,=20tcpWindowSize |Sender:=20; bh=9mTzYgODYnIt3UElige0u8qwRNIyRk9HcMrTTPPyVd4=; b=GASkIRnpCjH7MWOrH4s2TdeIuKlTvyD7CrvSFhuApbQvb3Voyj4SnGA8gI9mxUIS2rPOBAZv z/Yjj2G3vigixS0GoMD2qQdAGW56YIbyCt5zMOuz29bmioyl0b7pkp6k; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hitoshi Irino wrote: > Dear Jurgen, and all > > I have a question about some IEs relate TCP, tcpSequenceNumber, > tcpAcknowledgeNumber, tcpUrgentPointer, tcpWindowSize. > How do an exporter decide these values? > Exporter has several choices: first packet of TCP flow or last packet of > TCP flow etc... > Are these values a difference between value of first packet and value of > last packet(, or minimum and maximum)? > > The descriptions of these IEs in IPFIX-INFO-14 do not provide these > Information. > It is better to provide more description about value, I think. >From IPFIX INFO: If they do not serve as Flow Keys, their value may change from packet to packet within a single Flow. For Information Elements with values that are derived from fields of packets or from packet treatment and for which the value may change from packet to packet within a single Flow, the IPFIX information model defines 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. Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Dec 01 05:57:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq64o-0004ao-G8; Fri, 01 Dec 2006 05:57:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq64m-0004ZX-GN for ipfix@ietf.org; Fri, 01 Dec 2006 05:57:04 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq64l-0003Ue-6X for ipfix@ietf.org; Fri, 01 Dec 2006 05:57:04 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Dec 2006 11:56:55 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB1AuquE031282; Fri, 1 Dec 2006 11:56:52 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB1AupAJ008498; Fri, 1 Dec 2006 11:56:51 +0100 (MET) Received: from [10.61.64.7] (ams3-vpn-dhcp7.cisco.com [10.61.64.7]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA01698; Fri, 1 Dec 2006 10:56:50 GMT Message-ID: <45700A54.8010604@cisco.com> Date: Fri, 01 Dec 2006 10:56:20 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Hitoshi Irino Subject: Re: [IPFIX] Question about tcpSequenceNumber, tcpAcknowledgementNumber, tcpUrgentPointer, tcpWindowSize References: <456FFD58.6020302@lab.ntt.co.jp> In-Reply-To: <456FFD58.6020302@lab.ntt.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1158; t=1164970612; x=1165834612; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Question=20about=20tcpSequenceNumber, =20tcp AcknowledgementNumber,=0A=20tcpUrgentPointer,=20tcpWindowSize |Sender:=20; bh=9mTzYgODYnIt3UElige0u8qwRNIyRk9HcMrTTPPyVd4=; b=GASkIRnpCjH7MWOrH4s2TdeIuKlTvyD7CrvSFhuApbQvb3Voyj4SnGA8gI9mxUIS2rPOBAZv z/Yjj2G3vigixS0GoMD2qQdAGW56YIbyCt5zMOuz29bmioyl0b7pkp6k; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hitoshi Irino wrote: > Dear Jurgen, and all > > I have a question about some IEs relate TCP, tcpSequenceNumber, > tcpAcknowledgeNumber, tcpUrgentPointer, tcpWindowSize. > How do an exporter decide these values? > Exporter has several choices: first packet of TCP flow or last packet of > TCP flow etc... > Are these values a difference between value of first packet and value of > last packet(, or minimum and maximum)? > > The descriptions of these IEs in IPFIX-INFO-14 do not provide these > Information. > It is better to provide more description about value, I think. >From IPFIX INFO: If they do not serve as Flow Keys, their value may change from packet to packet within a single Flow. For Information Elements with values that are derived from fields of packets or from packet treatment and for which the value may change from packet to packet within a single Flow, the IPFIX information model defines 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. Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Dec 01 06:22:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq6TA-00077F-0A; Fri, 01 Dec 2006 06:22:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq6T8-00076z-Ov for ipfix@ietf.org; Fri, 01 Dec 2006 06:22:14 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq6T6-0000xO-5H for ipfix@ietf.org; Fri, 01 Dec 2006 06:22:14 -0500 Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1BM9LF029280; Fri, 1 Dec 2006 20:22:09 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1BM8Sh025876; Fri, 1 Dec 2006 20:22:08 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1BM8vF003714; Fri, 1 Dec 2006 20:22:08 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1BM7E5026739; Fri, 1 Dec 2006 20:22:07 +0900 (JST) Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1BM7xZ026736; Fri, 1 Dec 2006 20:22:07 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.96]) by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1BM65g001227; Fri, 1 Dec 2006 20:22:07 +0900 (JST) Message-ID: <45701063.6050301@lab.ntt.co.jp> Date: Fri, 01 Dec 2006 20:22:11 +0900 From: Hitoshi Irino User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] Question about tcpSequenceNumber, tcpAcknowledgementNumber, tcpUrgentPointer, tcpWindowSize References: <456FFD58.6020302@lab.ntt.co.jp> <45700A54.8010604@cisco.com> In-Reply-To: <45700A54.8010604@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Andrew and all, Thank you for reply, and I am sorry that I wrote "IPFIX-INFO-14 do not provide" by just reading description of these IEs (section 5.5.8-5.5.11). Andrew Johnson wrote: > Hitoshi Irino wrote: >> Dear Jurgen, and all >> >> I have a question about some IEs relate TCP, tcpSequenceNumber, >> tcpAcknowledgeNumber, tcpUrgentPointer, tcpWindowSize. >> How do an exporter decide these values? >> Exporter has several choices: first packet of TCP flow or last packet >> of TCP flow etc... >> Are these values a difference between value of first packet and value >> of last packet(, or minimum and maximum)? >> >> The descriptions of these IEs in IPFIX-INFO-14 do not provide these >> Information. >> It is better to provide more description about value, I think. > > From IPFIX INFO: > If they do not serve as Flow Keys, their value may change from packet > to packet within a single Flow. For Information Elements with values > that are derived from fields of packets or from packet treatment and > for which the value may change from packet to packet within a single > Flow, the IPFIX information model defines 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. > > > Andrew > regards, Hitoshi Irino _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Dec 01 06:22:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq6TA-00077F-0A; Fri, 01 Dec 2006 06:22:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq6T8-00076z-Ov for ipfix@ietf.org; Fri, 01 Dec 2006 06:22:14 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq6T6-0000xO-5H for ipfix@ietf.org; Fri, 01 Dec 2006 06:22:14 -0500 Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1BM9LF029280; Fri, 1 Dec 2006 20:22:09 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1BM8Sh025876; Fri, 1 Dec 2006 20:22:08 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1BM8vF003714; Fri, 1 Dec 2006 20:22:08 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1BM7E5026739; Fri, 1 Dec 2006 20:22:07 +0900 (JST) Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1BM7xZ026736; Fri, 1 Dec 2006 20:22:07 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.96]) by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kB1BM65g001227; Fri, 1 Dec 2006 20:22:07 +0900 (JST) Message-ID: <45701063.6050301@lab.ntt.co.jp> Date: Fri, 01 Dec 2006 20:22:11 +0900 From: Hitoshi Irino User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] Question about tcpSequenceNumber, tcpAcknowledgementNumber, tcpUrgentPointer, tcpWindowSize References: <456FFD58.6020302@lab.ntt.co.jp> <45700A54.8010604@cisco.com> In-Reply-To: <45700A54.8010604@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Andrew and all, Thank you for reply, and I am sorry that I wrote "IPFIX-INFO-14 do not provide" by just reading description of these IEs (section 5.5.8-5.5.11). Andrew Johnson wrote: > Hitoshi Irino wrote: >> Dear Jurgen, and all >> >> I have a question about some IEs relate TCP, tcpSequenceNumber, >> tcpAcknowledgeNumber, tcpUrgentPointer, tcpWindowSize. >> How do an exporter decide these values? >> Exporter has several choices: first packet of TCP flow or last packet >> of TCP flow etc... >> Are these values a difference between value of first packet and value >> of last packet(, or minimum and maximum)? >> >> The descriptions of these IEs in IPFIX-INFO-14 do not provide these >> Information. >> It is better to provide more description about value, I think. > > From IPFIX INFO: > If they do not serve as Flow Keys, their value may change from packet > to packet within a single Flow. For Information Elements with values > that are derived from fields of packets or from packet treatment and > for which the value may change from packet to packet within a single > Flow, the IPFIX information model defines 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. > > > Andrew > regards, Hitoshi Irino _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Dec 01 07:13:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq7GD-0005W1-0S; Fri, 01 Dec 2006 07:12:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq7GB-0005U3-PI for ipfix@ietf.org; Fri, 01 Dec 2006 07:12:55 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq7GA-0002qR-Fy for ipfix@ietf.org; Fri, 01 Dec 2006 07:12:55 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 01 Dec 2006 13:12:51 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB1CCmKg026932; Fri, 1 Dec 2006 13:12:48 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB1CCmAJ028141; Fri, 1 Dec 2006 13:12:48 +0100 (MET) Received: from [10.61.66.7] (ams3-vpn-dhcp519.cisco.com [10.61.66.7]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA08014; Fri, 1 Dec 2006 12:12:45 GMT Message-ID: <45701C23.2060109@cisco.com> Date: Fri, 01 Dec 2006 12:12:19 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: Hitoshi Irino Subject: Re: [IPFIX] Question about tcpSequenceNumber, tcpAcknowledgementNumber, tcpUrgentPointer, tcpWindowSize References: <456FFD58.6020302@lab.ntt.co.jp> In-Reply-To: <456FFD58.6020302@lab.ntt.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=340; t=1164975168; x=1165839168; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20Question=20about=20tcpSequenceNumber, =20tcp AcknowledgementNumber,=0A=20tcpUrgentPointer,=20tcpWindowSize |Sender:=20; bh=eF53d+1rkxLG/Nj0B8vBCyAHbqjAgrBvHFjnSd3Havs=; b=WWMpVW/sFzRB0CZIuryGsnn5hPyeBAG6JJr4uCVoj/OoHMc1Ezh0T7CWM3DrkIWU+KF+h6Hk sBXdkFf4wQv4kxsJu3RVa2RtqG3c2qM44G7h6WmpHrB3c1gOVzUBR2M1; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hitoshi, > I have a question about some IEs relate TCP, tcpSequenceNumber, > tcpAcknowledgeNumber, tcpUrgentPointer, tcpWindowSize. > How do an exporter decide these values? The Exporter doesn't decide the values at all. It's fed with data from the Metering Process. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Dec 01 07:13:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq7GD-0005W1-0S; Fri, 01 Dec 2006 07:12:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq7GB-0005U3-PI for ipfix@ietf.org; Fri, 01 Dec 2006 07:12:55 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq7GA-0002qR-Fy for ipfix@ietf.org; Fri, 01 Dec 2006 07:12:55 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 01 Dec 2006 13:12:51 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB1CCmKg026932; Fri, 1 Dec 2006 13:12:48 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB1CCmAJ028141; Fri, 1 Dec 2006 13:12:48 +0100 (MET) Received: from [10.61.66.7] (ams3-vpn-dhcp519.cisco.com [10.61.66.7]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA08014; Fri, 1 Dec 2006 12:12:45 GMT Message-ID: <45701C23.2060109@cisco.com> Date: Fri, 01 Dec 2006 12:12:19 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: Hitoshi Irino Subject: Re: [IPFIX] Question about tcpSequenceNumber, tcpAcknowledgementNumber, tcpUrgentPointer, tcpWindowSize References: <456FFD58.6020302@lab.ntt.co.jp> In-Reply-To: <456FFD58.6020302@lab.ntt.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=340; t=1164975168; x=1165839168; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20Question=20about=20tcpSequenceNumber, =20tcp AcknowledgementNumber,=0A=20tcpUrgentPointer,=20tcpWindowSize |Sender:=20; bh=eF53d+1rkxLG/Nj0B8vBCyAHbqjAgrBvHFjnSd3Havs=; b=WWMpVW/sFzRB0CZIuryGsnn5hPyeBAG6JJr4uCVoj/OoHMc1Ezh0T7CWM3DrkIWU+KF+h6Hk sBXdkFf4wQv4kxsJu3RVa2RtqG3c2qM44G7h6WmpHrB3c1gOVzUBR2M1; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hitoshi, > I have a question about some IEs relate TCP, tcpSequenceNumber, > tcpAcknowledgeNumber, tcpUrgentPointer, tcpWindowSize. > How do an exporter decide these values? The Exporter doesn't decide the values at all. It's fed with data from the Metering Process. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Dec 01 11:32:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBIM-0007Gh-WD; Fri, 01 Dec 2006 11:31:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBIM-0007DC-AL for ipfix@ietf.org; Fri, 01 Dec 2006 11:31:26 -0500 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqBIG-0006Mz-VY for ipfix@ietf.org; Fri, 01 Dec 2006 11:31:26 -0500 Received: from [192.168.1.11] (z168.58-98-179.ppp.wakwak.ne.jp [58.98.179.168]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id E785C4D9BA; Sat, 2 Dec 2006 01:31:00 +0900 (JST) Message-ID: <457058BD.7090307@sfc.wide.ad.jp> Date: Sat, 02 Dec 2006 01:30:53 +0900 From: Hitoshi Irino Organization: WIDE User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Paul Aitken Subject: Re: [IPFIX] Question about tcpSequenceNumber, tcpAcknowledgementNumber, tcpUrgentPointer, tcpWindowSize References: <456FFD58.6020302@lab.ntt.co.jp> <45701C23.2060109@cisco.com> In-Reply-To: <45701C23.2060109@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Paul Paul Aitken wrote: > Hitoshi, > >> I have a question about some IEs relate TCP, tcpSequenceNumber, >> tcpAcknowledgeNumber, tcpUrgentPointer, tcpWindowSize. >> How do an exporter decide these values? > > The Exporter doesn't decide the values at all. It's fed with data from > the Metering Process. Thanks, I have understood, however I wrote a sentence which makes confusion. I wanted to represent a device which contains exporting process and metering process. I should write metering process instead of exporter. regards, Hitoshi Irino _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Dec 01 11:32:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBIM-0007Gh-WD; Fri, 01 Dec 2006 11:31:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBIM-0007DC-AL for ipfix@ietf.org; Fri, 01 Dec 2006 11:31:26 -0500 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqBIG-0006Mz-VY for ipfix@ietf.org; Fri, 01 Dec 2006 11:31:26 -0500 Received: from [192.168.1.11] (z168.58-98-179.ppp.wakwak.ne.jp [58.98.179.168]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id E785C4D9BA; Sat, 2 Dec 2006 01:31:00 +0900 (JST) Message-ID: <457058BD.7090307@sfc.wide.ad.jp> Date: Sat, 02 Dec 2006 01:30:53 +0900 From: Hitoshi Irino Organization: WIDE User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Paul Aitken Subject: Re: [IPFIX] Question about tcpSequenceNumber, tcpAcknowledgementNumber, tcpUrgentPointer, tcpWindowSize References: <456FFD58.6020302@lab.ntt.co.jp> <45701C23.2060109@cisco.com> In-Reply-To: <45701C23.2060109@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Paul Paul Aitken wrote: > Hitoshi, > >> I have a question about some IEs relate TCP, tcpSequenceNumber, >> tcpAcknowledgeNumber, tcpUrgentPointer, tcpWindowSize. >> How do an exporter decide these values? > > The Exporter doesn't decide the values at all. It's fed with data from > the Metering Process. Thanks, I have understood, however I wrote a sentence which makes confusion. I wanted to represent a device which contains exporting process and metering process. I should write metering process instead of exporter. regards, Hitoshi Irino _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From janotlynn@taniaamazon.com Fri Dec 01 19:08:54 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqIR4-0001K7-05 for ipfix-archive@lists.ietf.org; Fri, 01 Dec 2006 19:08:54 -0500 Received: from h-68-166-27-182.atlngahp.dynamic.covad.net ([68.166.27.182] helo=bkml) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GqIQz-0003mc-Iw for ipfix-archive@lists.ietf.org; Fri, 01 Dec 2006 19:08:53 -0500 Message-ID: <002a01c7159f.2d756480.a344c0a8@galen> Date: Fri, 01 Dec 2006 23:19:41 +0000 From: bobbette gillian User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: evan elenore Subject: Cristmas, gun Content-Type: multipart/alternative; boundary="---------00000079.01C7159F" X-Spam-Score: 2.4 (++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a This is a multi-part message in MIME format. -----------00000079.01C7159F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Upcoming holydays brings you headache? We have a solution! whitevpinkandtwo.com king nut hoity-toity fidelity insurance gharry-wallah -----------00000079.01C7159F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Upcoming holydays brings you headache?
We have a solution!
whitevpinkandtwo.com
king nut hoity-toity
fidelity insurance gharry-wallah
-----------00000079.01C7159F-- From ipfix-bounces@ietf.org Mon Dec 04 11:09:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGMt-0006C1-Ku; Mon, 04 Dec 2006 11:08:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGMs-0006An-DX for ipfix@ietf.org; Mon, 04 Dec 2006 11:08:34 -0500 Received: from gatekeeper.hitachi-eu.com ([194.36.128.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrGMm-0002Od-Ov for ipfix@ietf.org; Mon, 04 Dec 2006 11:08:34 -0500 X-ASG-Debug-ID: 1165248497-7e6300750000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: primary.hitachi-eu.net[193.39.225.234] X-Barracuda-Start-Time: 1165248497 X-ASG-Whitelist: Client Received: from mhd-esafe-int.hitachi-eu.com (primary.hitachi-eu.net [193.39.225.234]) by gatekeeper.hitachi-eu.com (Spam Firewall) with SMTP id 7412A2C22C for ; Mon, 4 Dec 2006 16:08:17 +0000 (GMT) Received: from MHDEXC99.adhel.hitachi-eu.com ([IP=193.39.227.52]) by eSafe SMTP Relay 1165163447; Mon Dec 4 16:08:16 2006 Received: from mhdexc02.adhel.hitachi-eu.com ([193.39.227.51]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 16:08:16 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Date: Mon, 4 Dec 2006 16:06:41 -0000 Message-ID: <3167F18F59B81B4888A4D4C0A1717DD6670F94@mhdexc02.adhel.hitachi-eu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Thread-Index: AccXvi+Twyp0gnWNRKSnDT2SQXFONA== From: "Boschi, Elisa" To: X-OriginalArrivalTime: 04 Dec 2006 16:08:16.0201 (UTC) FILETIME=[6827C390:01C717BE] X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: ipfix@ietf.org, boschie@tik.ee.ethz.ch X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0609916431==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0609916431== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C717BE.67DD0680" This is a multi-part message in MIME format. ------_=_NextPart_001_01C717BE.67DD0680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, thanks for your comments. I've changed the text according to your suggest= ions, just one minor comment below: > > 7.1 para 3 OLD: > > The Collecting Process MUST NOT decode any further Data Records whi= ch > are associated with the expired Common Properties. If a Common > Property is refreshed with a Template Record that differs from the > previous received Template Record, the Collecting Process SHOULD log > a warning and replace the previous received Common Property with the > new one. The Template lifetime at the Collecting Process MUST be at > least 3 times higher than the Template refresh timeout configured on > the Exporting Process. > > 7.1 para 3 NEW: > > The Collecting Process MUST NOT decode any further Data Records whi= ch > are associated with the expired Common Properties. If a Common > Property is refreshed with a definition that differs from the > previous definition, the Collecting Process SHOULD log > a warning and replace the previous received Common Property with the > new one. The Common Property lifetime at the Collecting Process MU= ST be at > least 3 times higher than the Common Property timeout configured on > the Exporting Process. OK. But in the last sentence I'd prefer keeping "refresh timeout" instead= of just "timeout": " The Common Property lifetime at the Collecting Process MUST be at leas= t 3 times higher than the Common Property refresh timeout configured on t= he Exporting Process." Regards, Elisa > > > Regards, > > Brian > > On Nov 13, 2006, at 2:17 PM, Juergen Quittek wrote: > >> Dear all, >> >> As agreed at the IPFIX session in San Diego last week >> this is the WG last call on the Internet draft on >> Reducing redundancy in IPFIX and PSAMP reports, >> draft-ietf-ipfix-reducing-redundancy-01.txt. >> >> The WG last call starts today and will be closed on >> December 1st. >> >> Please review the draft and send your comments! Please also >> send a message to the mailing list if you reviewed it and >> have no comment to make! >> >> Thanks, >> >> Juergen >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipfix > > *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* ------_=_NextPart_001_01C717BE.67DD0680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-0= 1.txt until December 1st

Brian,

thanks for your comments. I've changed the text according to your suggest= ions, just one minor comment below:

>
> 7.1 para 3 OLD:
>
>    The Collecting Process MUST NOT decode any further= Data Records  which
>    are associated with the expired Common Properties.=   If a Common
>    Property is refreshed with a Template Record that = differs from the
>    previous received Template Record, the Collecting = Process SHOULD log
>    a warning and replace the previous received Common= Property with the
>    new one.  The Template lifetime at the Collec= ting Process MUST be at
>    least 3 times higher than the Template refresh tim= eout configured on
>    the Exporting Process.
>
> 7.1 para 3 NEW:
>
>    The Collecting Process MUST NOT decode any further= Data Records  which
>    are associated with the expired Common Properties.=   If a Common
>    Property is refreshed with a definition that diffe= rs from the
>    previous definition, the Collecting Process SHOULD= log
>    a warning and replace the previous received Common= Property with the
>    new one.  The Common Property lifetime at the= Collecting Process  MUST be at
>    least 3 times higher than the Common Property time= out configured on
>    the Exporting Process.

OK. But in the last sentence I'd prefer keeping "refresh timeout&quo= t; instead of just "timeout":

" The Common Property lifetime at the Collecting Process  MUST = be at least 3 times higher than the Common Property refresh timeout confi= gured on the Exporting Process."


Regards,
Elisa

>
>
> Regards,
>
> Brian
>
> On Nov 13, 2006, at 2:17 PM, Juergen Quittek wrote:
>
>> Dear all,
>>
>> As agreed at the IPFIX session in San Diego last week
>> this is the WG last call on the Internet draft on
>> Reducing redundancy in IPFIX and PSAMP reports,
>> draft-ietf-ipfix-reducing-redundancy-01.txt.
>>
>> The WG last call starts today and will be closed on
>> December 1st.
>>
>> Please review the draft and send your comments!  Please als= o
>> send a message to the mailing list if you reviewed it and
>> have no comment to make!
>>
>> Thanks,
>>
>>    Juergen
>>
>>
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https:/= /www1.ietf.org/mailman/listinfo/ipfix
>
>





 

*************************************************************************=
*************************
=20
 E-mail Confidentiality Notice and Disclaimer.
=20
  This email and any files transmitted with it are confidential and are i=
ntended solely for=20
the use of the individual or entity to which they are addressed. Access t=
o this e-mail by=20
anyone else is unauthorised. If you are not the intended recipient, any d=
isclosure,=20
copying, distribution or any action taken or omitted to be taken in relia=
nce on it, is=20
prohibited.=20
  E-mail messages are not necessarily secure.  Hitachi does not accept re=
sponsibility=20
for any changes made to this message after it was sent.=20
  Please note that Hitachi checks outgoing e-mail messages for the presen=
ce of=20
computer viruses.

*************************************************************************=
*************************
------_=_NextPart_001_01C717BE.67DD0680-- --===============0609916431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============0609916431==-- From ipfix-bounces@ietf.org Mon Dec 04 11:09:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGMt-0006C1-Ku; Mon, 04 Dec 2006 11:08:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGMs-0006An-DX for ipfix@ietf.org; Mon, 04 Dec 2006 11:08:34 -0500 Received: from gatekeeper.hitachi-eu.com ([194.36.128.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrGMm-0002Od-Ov for ipfix@ietf.org; Mon, 04 Dec 2006 11:08:34 -0500 X-ASG-Debug-ID: 1165248497-7e6300750000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: primary.hitachi-eu.net[193.39.225.234] X-Barracuda-Start-Time: 1165248497 X-ASG-Whitelist: Client Received: from mhd-esafe-int.hitachi-eu.com (primary.hitachi-eu.net [193.39.225.234]) by gatekeeper.hitachi-eu.com (Spam Firewall) with SMTP id 7412A2C22C for ; Mon, 4 Dec 2006 16:08:17 +0000 (GMT) Received: from MHDEXC99.adhel.hitachi-eu.com ([IP=193.39.227.52]) by eSafe SMTP Relay 1165163447; Mon Dec 4 16:08:16 2006 Received: from mhdexc02.adhel.hitachi-eu.com ([193.39.227.51]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 16:08:16 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Date: Mon, 4 Dec 2006 16:06:41 -0000 Message-ID: <3167F18F59B81B4888A4D4C0A1717DD6670F94@mhdexc02.adhel.hitachi-eu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Thread-Index: AccXvi+Twyp0gnWNRKSnDT2SQXFONA== From: "Boschi, Elisa" To: X-OriginalArrivalTime: 04 Dec 2006 16:08:16.0201 (UTC) FILETIME=[6827C390:01C717BE] X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: ipfix@ietf.org, boschie@tik.ee.ethz.ch X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0609916431==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0609916431== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C717BE.67DD0680" This is a multi-part message in MIME format. ------_=_NextPart_001_01C717BE.67DD0680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, thanks for your comments. I've changed the text according to your suggest= ions, just one minor comment below: > > 7.1 para 3 OLD: > > The Collecting Process MUST NOT decode any further Data Records whi= ch > are associated with the expired Common Properties. If a Common > Property is refreshed with a Template Record that differs from the > previous received Template Record, the Collecting Process SHOULD log > a warning and replace the previous received Common Property with the > new one. The Template lifetime at the Collecting Process MUST be at > least 3 times higher than the Template refresh timeout configured on > the Exporting Process. > > 7.1 para 3 NEW: > > The Collecting Process MUST NOT decode any further Data Records whi= ch > are associated with the expired Common Properties. If a Common > Property is refreshed with a definition that differs from the > previous definition, the Collecting Process SHOULD log > a warning and replace the previous received Common Property with the > new one. The Common Property lifetime at the Collecting Process MU= ST be at > least 3 times higher than the Common Property timeout configured on > the Exporting Process. OK. But in the last sentence I'd prefer keeping "refresh timeout" instead= of just "timeout": " The Common Property lifetime at the Collecting Process MUST be at leas= t 3 times higher than the Common Property refresh timeout configured on t= he Exporting Process." Regards, Elisa > > > Regards, > > Brian > > On Nov 13, 2006, at 2:17 PM, Juergen Quittek wrote: > >> Dear all, >> >> As agreed at the IPFIX session in San Diego last week >> this is the WG last call on the Internet draft on >> Reducing redundancy in IPFIX and PSAMP reports, >> draft-ietf-ipfix-reducing-redundancy-01.txt. >> >> The WG last call starts today and will be closed on >> December 1st. >> >> Please review the draft and send your comments! Please also >> send a message to the mailing list if you reviewed it and >> have no comment to make! >> >> Thanks, >> >> Juergen >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipfix > > *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* ------_=_NextPart_001_01C717BE.67DD0680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-0= 1.txt until December 1st

Brian,

thanks for your comments. I've changed the text according to your suggest= ions, just one minor comment below:

>
> 7.1 para 3 OLD:
>
>    The Collecting Process MUST NOT decode any further= Data Records  which
>    are associated with the expired Common Properties.=   If a Common
>    Property is refreshed with a Template Record that = differs from the
>    previous received Template Record, the Collecting = Process SHOULD log
>    a warning and replace the previous received Common= Property with the
>    new one.  The Template lifetime at the Collec= ting Process MUST be at
>    least 3 times higher than the Template refresh tim= eout configured on
>    the Exporting Process.
>
> 7.1 para 3 NEW:
>
>    The Collecting Process MUST NOT decode any further= Data Records  which
>    are associated with the expired Common Properties.=   If a Common
>    Property is refreshed with a definition that diffe= rs from the
>    previous definition, the Collecting Process SHOULD= log
>    a warning and replace the previous received Common= Property with the
>    new one.  The Common Property lifetime at the= Collecting Process  MUST be at
>    least 3 times higher than the Common Property time= out configured on
>    the Exporting Process.

OK. But in the last sentence I'd prefer keeping "refresh timeout&quo= t; instead of just "timeout":

" The Common Property lifetime at the Collecting Process  MUST = be at least 3 times higher than the Common Property refresh timeout confi= gured on the Exporting Process."


Regards,
Elisa

>
>
> Regards,
>
> Brian
>
> On Nov 13, 2006, at 2:17 PM, Juergen Quittek wrote:
>
>> Dear all,
>>
>> As agreed at the IPFIX session in San Diego last week
>> this is the WG last call on the Internet draft on
>> Reducing redundancy in IPFIX and PSAMP reports,
>> draft-ietf-ipfix-reducing-redundancy-01.txt.
>>
>> The WG last call starts today and will be closed on
>> December 1st.
>>
>> Please review the draft and send your comments!  Please als= o
>> send a message to the mailing list if you reviewed it and
>> have no comment to make!
>>
>> Thanks,
>>
>>    Juergen
>>
>>
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https:/= /www1.ietf.org/mailman/listinfo/ipfix
>
>





 

*************************************************************************=
*************************
=20
 E-mail Confidentiality Notice and Disclaimer.
=20
  This email and any files transmitted with it are confidential and are i=
ntended solely for=20
the use of the individual or entity to which they are addressed. Access t=
o this e-mail by=20
anyone else is unauthorised. If you are not the intended recipient, any d=
isclosure,=20
copying, distribution or any action taken or omitted to be taken in relia=
nce on it, is=20
prohibited.=20
  E-mail messages are not necessarily secure.  Hitachi does not accept re=
sponsibility=20
for any changes made to this message after it was sent.=20
  Please note that Hitachi checks outgoing e-mail messages for the presen=
ce of=20
computer viruses.

*************************************************************************=
*************************
------_=_NextPart_001_01C717BE.67DD0680-- --===============0609916431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============0609916431==-- From ipfix-bounces@ietf.org Mon Dec 04 11:12:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGQW-0007sV-7h; Mon, 04 Dec 2006 11:12:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGQV-0007s3-5o for ipfix@ietf.org; Mon, 04 Dec 2006 11:12:19 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrGQT-0003FX-SI for ipfix@ietf.org; Mon, 04 Dec 2006 11:12:19 -0500 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kB4GBis6029650 for ; Mon, 4 Dec 2006 11:12:07 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kB4GAbJA029457 for ; Mon, 4 Dec 2006 11:10:37 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kB4GAarv029452; Mon, 04 Dec 2006 11:10:37 -0500 (EST) Received: from [128.237.236.103] (vpn-10-25-4-19.remote.cert.org [10.25.4.19]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.66) with ESMTP id kB4GAaEd029681; Mon, 4 Dec 2006 11:10:36 -0500 In-Reply-To: <3167F18F59B81B4888A4D4C0A1717DD6670F94@mhdexc02.adhel.hitachi-eu.com> References: <3167F18F59B81B4888A4D4C0A1717DD6670F94@mhdexc02.adhel.hitachi-eu.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <83171543-2964-43F7-A2EA-636322F1B85D@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Date: Mon, 4 Dec 2006 11:09:54 -0500 To: "Boschi, Elisa" X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: ipfix@ietf.org, boschie@tik.ee.ethz.ch X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Elisa, Agreed. "Common Property refresh timeout" is clearer. Regards, Brian On Dec 4, 2006, at 11:06 AM, Boschi, Elisa wrote: > > Brian, > > thanks for your comments. I've changed the text according to your > suggestions, just one minor comment below: > > > > > 7.1 para 3 OLD: > > > > The Collecting Process MUST NOT decode any further Data > Records which > > are associated with the expired Common Properties. If a Common > > Property is refreshed with a Template Record that differs from > the > > previous received Template Record, the Collecting Process > SHOULD log > > a warning and replace the previous received Common Property > with the > > new one. The Template lifetime at the Collecting Process MUST > be at > > least 3 times higher than the Template refresh timeout > configured on > > the Exporting Process. > > > > 7.1 para 3 NEW: > > > > The Collecting Process MUST NOT decode any further Data > Records which > > are associated with the expired Common Properties. If a Common > > Property is refreshed with a definition that differs from the > > previous definition, the Collecting Process SHOULD log > > a warning and replace the previous received Common Property > with the > > new one. The Common Property lifetime at the Collecting > Process MUST be at > > least 3 times higher than the Common Property timeout > configured on > > the Exporting Process. > > OK. But in the last sentence I'd prefer keeping "refresh timeout" > instead of just "timeout": > > " The Common Property lifetime at the Collecting Process MUST be > at least 3 times higher than the Common Property refresh timeout > configured on the Exporting Process." > > > Regards, > Elisa > > > > > > > Regards, > > > > Brian > > > > On Nov 13, 2006, at 2:17 PM, Juergen Quittek wrote: > > > >> Dear all, > >> > >> As agreed at the IPFIX session in San Diego last week > >> this is the WG last call on the Internet draft on > >> Reducing redundancy in IPFIX and PSAMP reports, > >> draft-ietf-ipfix-reducing-redundancy-01.txt. > >> > >> The WG last call starts today and will be closed on > >> December 1st. > >> > >> Please review the draft and send your comments! Please also > >> send a message to the mailing list if you reviewed it and > >> have no comment to make! > >> > >> Thanks, > >> > >> Juergen > >> > >> > >> _______________________________________________ > >> IPFIX mailing list > >> IPFIX@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ipfix > > > > > > > > > > > ********************************************************************** > **************************** 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 e-mail 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. E-mail > messages are not necessarily secure. Hitachi does not accept > responsibility for any changes made to this message after it was > sent. Please note that Hitachi checks outgoing e-mail messages for > the presence of computer viruses. > ********************************************************************** > **************************** _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Dec 04 11:12:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGQW-0007sV-7h; Mon, 04 Dec 2006 11:12:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGQV-0007s3-5o for ipfix@ietf.org; Mon, 04 Dec 2006 11:12:19 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrGQT-0003FX-SI for ipfix@ietf.org; Mon, 04 Dec 2006 11:12:19 -0500 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kB4GBis6029650 for ; Mon, 4 Dec 2006 11:12:07 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kB4GAbJA029457 for ; Mon, 4 Dec 2006 11:10:37 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kB4GAarv029452; Mon, 04 Dec 2006 11:10:37 -0500 (EST) Received: from [128.237.236.103] (vpn-10-25-4-19.remote.cert.org [10.25.4.19]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.66) with ESMTP id kB4GAaEd029681; Mon, 4 Dec 2006 11:10:36 -0500 In-Reply-To: <3167F18F59B81B4888A4D4C0A1717DD6670F94@mhdexc02.adhel.hitachi-eu.com> References: <3167F18F59B81B4888A4D4C0A1717DD6670F94@mhdexc02.adhel.hitachi-eu.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <83171543-2964-43F7-A2EA-636322F1B85D@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Date: Mon, 4 Dec 2006 11:09:54 -0500 To: "Boschi, Elisa" X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: ipfix@ietf.org, boschie@tik.ee.ethz.ch X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Elisa, Agreed. "Common Property refresh timeout" is clearer. Regards, Brian On Dec 4, 2006, at 11:06 AM, Boschi, Elisa wrote: > > Brian, > > thanks for your comments. I've changed the text according to your > suggestions, just one minor comment below: > > > > > 7.1 para 3 OLD: > > > > The Collecting Process MUST NOT decode any further Data > Records which > > are associated with the expired Common Properties. If a Common > > Property is refreshed with a Template Record that differs from > the > > previous received Template Record, the Collecting Process > SHOULD log > > a warning and replace the previous received Common Property > with the > > new one. The Template lifetime at the Collecting Process MUST > be at > > least 3 times higher than the Template refresh timeout > configured on > > the Exporting Process. > > > > 7.1 para 3 NEW: > > > > The Collecting Process MUST NOT decode any further Data > Records which > > are associated with the expired Common Properties. If a Common > > Property is refreshed with a definition that differs from the > > previous definition, the Collecting Process SHOULD log > > a warning and replace the previous received Common Property > with the > > new one. The Common Property lifetime at the Collecting > Process MUST be at > > least 3 times higher than the Common Property timeout > configured on > > the Exporting Process. > > OK. But in the last sentence I'd prefer keeping "refresh timeout" > instead of just "timeout": > > " The Common Property lifetime at the Collecting Process MUST be > at least 3 times higher than the Common Property refresh timeout > configured on the Exporting Process." > > > Regards, > Elisa > > > > > > > Regards, > > > > Brian > > > > On Nov 13, 2006, at 2:17 PM, Juergen Quittek wrote: > > > >> Dear all, > >> > >> As agreed at the IPFIX session in San Diego last week > >> this is the WG last call on the Internet draft on > >> Reducing redundancy in IPFIX and PSAMP reports, > >> draft-ietf-ipfix-reducing-redundancy-01.txt. > >> > >> The WG last call starts today and will be closed on > >> December 1st. > >> > >> Please review the draft and send your comments! Please also > >> send a message to the mailing list if you reviewed it and > >> have no comment to make! > >> > >> Thanks, > >> > >> Juergen > >> > >> > >> _______________________________________________ > >> IPFIX mailing list > >> IPFIX@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ipfix > > > > > > > > > > > ********************************************************************** > **************************** 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 e-mail 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. E-mail > messages are not necessarily secure. Hitachi does not accept > responsibility for any changes made to this message after it was > sent. Please note that Hitachi checks outgoing e-mail messages for > the presence of computer viruses. > ********************************************************************** > **************************** _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Dec 04 11:16:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGUX-00084T-3J; Mon, 04 Dec 2006 11:16:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGUU-0007Yu-6w for ipfix@ietf.org; Mon, 04 Dec 2006 11:16:26 -0500 Received: from gatekeeper.hitachi-eu.com ([194.36.128.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrGUT-0003ic-8N for ipfix@ietf.org; Mon, 04 Dec 2006 11:16:26 -0500 X-ASG-Debug-ID: 1165248984-0ec800210000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: primary.hitachi-eu.net[193.39.225.234] X-Barracuda-Start-Time: 1165248984 X-ASG-Whitelist: Client Received: from mhd-esafe-int.hitachi-eu.com (primary.hitachi-eu.net [193.39.225.234]) by gatekeeper.hitachi-eu.com (Spam Firewall) with SMTP id AE99E1727E for ; Mon, 4 Dec 2006 16:16:24 +0000 (GMT) Received: from MHDEXC99.adhel.hitachi-eu.com ([IP=193.39.227.52]) by eSafe SMTP Relay 1165163447; Mon Dec 4 16:16:24 2006 Received: from mhdexc02.adhel.hitachi-eu.com ([193.39.227.51]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 16:16:24 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Date: Mon, 4 Dec 2006 16:16:23 -0000 Message-ID: <3167F18F59B81B4888A4D4C0A1717DD6670F95@mhdexc02.adhel.hitachi-eu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Thread-Index: AccXv4q4zwzAtD3nT8O3rIelX9QxeA== From: "Boschi, Elisa" To: X-OriginalArrivalTime: 04 Dec 2006 16:16:24.0232 (UTC) FILETIME=[8B0B6280:01C717BF] X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com X-Spam-Score: 0.6 (/) X-Scan-Signature: c853ec6e79db43c8dbe6774215da1042 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0532550691==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0532550691== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C717BF.8ABDD2D9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C717BF.8ABDD2D9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gerhard, thanks for your comments. Find my answers (and comments) inline: > >Some comments on Section 8: > > The main advantage of the method specified in this document is the > reduction in the amount of measurement data that has to be > transferred from the Exporter to the Collector. > >I would like to add here "under some conditions" (or something similar) >since the proposed method does not necessarily lead to a reduction of >the amount of data. > I propose to add a sentence at the beginning of section 8: "The main advantage of the method specified in this document is the reduc= tion in the amount of measurement data that has to be transferred from th= e Exporter to the Collector. Note that several factors influence its eff= iciency, as discussed in this section. " and then in section 8.4 swap the two paragraphs, moving the example evalu= ation to the end: "While the goal of this specification is to reduce the bandwidth, the eff= iciency might be limited. Indeed, the efficiency gain is based on the nu= merous redundant information in flows. While the Exporting Process can e= valuate the direct gain for the Flow Records to be exported, it can=92t p= redict whether future Flow Records would contain the information specifie= d by active commonPropertiesID values. This implies that the efficiency = factor of this specification is higher for specific applications where fi= ltering is involved, such as one-way delay or trajectory sampling. The example in section 11.2 below uses IPFIX to export measurement data f= or each received packet. In that case, for a flow of 1000 packets the am= ount of data can be decreased more than 33 percent." > > The transfer of the commonPropertiesIDs originates some overhead. > Note that IPFIX allows reduced-size encoding of Information > Elements. In cases where the range of the commonPropertiesID can be > restricted, reduced-size encoding can be applied also to the > commonPropertiesID, and would result in a further bandwidth > efficiency gain. > >I would say: the overhead of the commonPropertiesID IE is very >significant if 64 bit are used.=20 > >The length of the commonPropertiesID >field also gives you a necessary condition if you ever want to reach a >reduced amount of data: The length must be shorter than the length of >the replaced IEs, otherwise you even increase the amount monitoring data= ! > >As a consequence, reduced-size encoding should be used whenever possible. > what about changing the text in 8.2 as follows: OLD: In cases where the range of the commonPropertiesID can be restricted, red= uced-size encoding can be applied also to the commonPropertiesID, and wou= ld result in a further bandwidth efficiency gain. NEW: In cases where the range of the commonPropertiesID can be restricted, it = is RECOMMENDED to apply reduced-size encoding to the commonPropertiesID,= to achieve a further bandwidth efficiency gain. > > The example in section 11.2 below uses IPFIX to export measurement > data for each received packet. In that case, for a flow of 1000 > packets the amount of data can be decreased more than 33 percent. > >The example in 11.2 refers to OWD measurements, which is a very special >application where the proposed method is very beneficial. Maybe you >should mention "OWD measurements" here, since 33 percent may not be the >general case. > 33 percent is of course not the general case. It is the efficiency gain o= f the example in 11.2... > > While the goal of this specification is to reduce the bandwidth, the > efficiency might be limited. > >As I said before, you can even increase the amount of data with the >proposed method. So I suggest to explain under which conditions the >approach achieves its goal. > we give guidelines in sections 8.1 and 8.4 for that: "The proposed method is most effective using a reliable transport protoco= l for the transfer of the Common Properties...." and: "While the goal of this specification is to reduce the bandwidth, the eff= iciency might be limited. Indeed, the efficiency gain is based on the nu= merous redundant information in flows. While the Exporting Process can e= valuate the direct gain for the Flow Records to be exported, it can=92t p= redict whether future Flow Records would contain the information specifie= d by active commonPropertiesID values. This implies that the efficiency = factor of this specification is higher for specific applications where fi= ltering is involved, such as one-way delay or trajectory sampling." Are you suggesting to add more conditions (which ones?) or is the text ab= ove not clear? =20 >How many times do I need to refer to the common properties until the >amount of data is reduced for the first time? >This should be a simple calculation. Even if this number cannot be >predicted in advance in pratice, it might be useful to estimate when I >should use the approach. > that depends on which ones the Common Properties are, and how many they a= re, don't you think? Or are you proposing to do this for one of the examp= les? Regards, Elisa > >Regards, >Gerhard > >Juergen Quittek wrote: > >>Dear all, >> >>As agreed at the IPFIX session in San Diego last week >>this is the WG last call on the Internet draft on >>Reducing redundancy in IPFIX and PSAMP reports, >>draft-ietf-ipfix-reducing-redundancy-01.txt. >> >>The WG last call starts today and will be closed on >>December 1st. >> >>Please review the draft and send your comments! Please also >>send a message to the mailing list if you reviewed it and >>have no comment to make! >> >>Thanks, >> >> Juergen >> >> >>_______________________________________________ >>IPFIX mailing list >>IPFIX@ietf.org >>https://www1.ietf.org/mailman/listinfo/ipfix > > > > >_______________________________________________ >IPFIX mailing list >IPFIX@ietf.org >https://www1.ietf.org/mailman/listinfo/ipfix > *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* ------_=_NextPart_001_01C717BF.8ABDD2D9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-0= 1.txt until December 1st

Gerhard,

thanks for your comments.
Find my answers (and comments) inline:


>
>Some comments on Section 8:
>
>   The main advantage of the method specified in this docum= ent is the
>   reduction in the amount of measurement data that has to = be
>   transferred from the Exporter to the Collector.
>
>I would like to add here "under some conditions" (or someth= ing similar)
>since the proposed method does not necessarily lead to a reduction of=
>the amount of data.
>


I propose to add a sentence at the beginning of section 8:

"The main advantage of the method specified in this document is the = reduction in the amount of measurement data that has to be transferred fr= om the Exporter to the Collector.  Note that several factors influen= ce its efficiency, as discussed in this section. "

and then in section 8.4 swap the two paragraphs, moving the example evalu= ation to the end:

"While the goal of this specification is to reduce the bandwidth, th= e efficiency might be limited.  Indeed, the efficiency gain is based= on the numerous redundant information in flows.  While the Exportin= g Process can evaluate the direct gain for the Flow Records to be exporte= d, it can’t predict whether future Flow Records would contain the in= formation specified by active commonPropertiesID values.  This impli= es that the efficiency factor of this specification is higher for specifi= c applications where filtering is involved, such as one-way delay or traj= ectory sampling.

The example in section 11.2 below uses IPFIX to export measurement data f= or each received packet.  In that case, for a flow of 1000 packets t= he amount of data can be decreased more than 33 percent."


>
>   The transfer of the commonPropertiesIDs originates some = overhead.
>   Note that IPFIX allows reduced-size encoding of Informat= ion
>   Elements.  In cases where the range of the commonPr= opertiesID can be
>   restricted, reduced-size encoding can be applied also to= the
>   commonPropertiesID, and would result in a further bandwi= dth
>   efficiency gain.
>
>I would say: the overhead of the commonPropertiesID IE is very
>significant if 64 bit are used.
>
>The length of the commonPropertiesID
>field also gives you a necessary condition if you ever want to reach = a
>reduced amount of data: The length must be shorter than the length of=
>the replaced IEs, otherwise you even increase the amount monitoring d= ata!
>
>As a consequence, reduced-size encoding should be used whenever possi= ble.
>


what about changing the text in 8.2 as follows:

OLD:
In cases where the range of the commonPropertiesID can be restricted, red= uced-size encoding can be applied also to the commonPropertiesID, and wou= ld result in a further bandwidth efficiency gain.

NEW:
In cases where the range of the commonPropertiesID can be restricted, it = is  RECOMMENDED to apply reduced-size encoding to the commonProperti= esID, to achieve a further bandwidth efficiency gain.


>
>   The example in section 11.2 below uses IPFIX to export m= easurement
>   data for each received packet.  In that case, for a= flow of 1000
>   packets the amount of data can be decreased more than 33= percent.
>
>The example in 11.2 refers to OWD measurements, which is a very speci= al
>application where the proposed method is very beneficial. Maybe you >should mention "OWD measurements" here, since 33 percent ma= y not be the
>general case.
>

33 percent is of course not the general case. It is the efficiency gain o= f the example in 11.2...

>
>   While the goal of this specification is to reduce the ba= ndwidth, the
>   efficiency might be limited.
>
>As I said before, you can even increase the amount of data with the >proposed method. So I suggest to explain under which conditions the >approach achieves its goal.
>

we give guidelines in sections 8.1 and 8.4 for that:

"The proposed method is most effective using a reliable transport pr= otocol for the transfer of the Common Properties...."

and:

"While the goal of this specification is to reduce the bandwidth, th= e efficiency might be limited.  Indeed, the efficiency gain is based= on the numerous redundant information in flows.  While the Exportin= g Process can evaluate the direct gain for the Flow Records to be exporte= d, it can’t predict whether future Flow Records would contain the in= formation specified by active commonPropertiesID values.  This impli= es that the efficiency factor of this specification is higher for specifi= c applications where filtering is involved, such as one-way delay or traj= ectory sampling."

Are you suggesting to add more conditions (which ones?) or is the text ab= ove not clear?


>How many times do I need to refer to the common properties until the<= BR> >amount of data is reduced for the first time?
>This should be a simple calculation. Even if this number cannot be >predicted in advance in pratice, it might be useful to estimate when = I
>should use the approach.
>

that depends on which ones the Common Properties are, and how many they a= re, don't you think? Or are you proposing to do this for one of the examp= les?

Regards,
Elisa


>
>Regards,
>Gerhard
>
>Juergen Quittek wrote:
>
>>Dear all,
>>
>>As agreed at the IPFIX session in San Diego last week
>>this is the WG last call on the Internet draft on
>>Reducing redundancy in IPFIX and PSAMP reports,
>>draft-ietf-ipfix-reducing-redundancy-01.txt.
>>
>>The WG last call starts today and will be closed on
>>December 1st.
>>
>>Please review the draft and send your comments!  Please also=
>>send a message to the mailing list if you reviewed it and
>>have no comment to make!
>>
>>Thanks,
>>
>>   Juergen
>>
>>
>>_______________________________________________
>>IPFIX mailing list
>>IPFIX@ietf.org
>>https://= www1.ietf.org/mailman/listinfo/ipfix
>
>
>
>
>_______________________________________________
>IPFIX mailing list
>IPFIX@ietf.org
>https://www1= =2Eietf.org/mailman/listinfo/ipfix
>
 

*************************************************************************=
*************************
=20
 E-mail Confidentiality Notice and Disclaimer.
=20
  This email and any files transmitted with it are confidential and are i=
ntended solely for=20
the use of the individual or entity to which they are addressed. Access t=
o this e-mail by=20
anyone else is unauthorised. If you are not the intended recipient, any d=
isclosure,=20
copying, distribution or any action taken or omitted to be taken in relia=
nce on it, is=20
prohibited.=20
  E-mail messages are not necessarily secure.  Hitachi does not accept re=
sponsibility=20
for any changes made to this message after it was sent.=20
  Please note that Hitachi checks outgoing e-mail messages for the presen=
ce of=20
computer viruses.

*************************************************************************=
*************************
------_=_NextPart_001_01C717BF.8ABDD2D9-- --===============0532550691== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============0532550691==-- From ipfix-bounces@ietf.org Mon Dec 04 11:16:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGUX-00084T-3J; Mon, 04 Dec 2006 11:16:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGUU-0007Yu-6w for ipfix@ietf.org; Mon, 04 Dec 2006 11:16:26 -0500 Received: from gatekeeper.hitachi-eu.com ([194.36.128.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrGUT-0003ic-8N for ipfix@ietf.org; Mon, 04 Dec 2006 11:16:26 -0500 X-ASG-Debug-ID: 1165248984-0ec800210000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: primary.hitachi-eu.net[193.39.225.234] X-Barracuda-Start-Time: 1165248984 X-ASG-Whitelist: Client Received: from mhd-esafe-int.hitachi-eu.com (primary.hitachi-eu.net [193.39.225.234]) by gatekeeper.hitachi-eu.com (Spam Firewall) with SMTP id AE99E1727E for ; Mon, 4 Dec 2006 16:16:24 +0000 (GMT) Received: from MHDEXC99.adhel.hitachi-eu.com ([IP=193.39.227.52]) by eSafe SMTP Relay 1165163447; Mon Dec 4 16:16:24 2006 Received: from mhdexc02.adhel.hitachi-eu.com ([193.39.227.51]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 16:16:24 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Date: Mon, 4 Dec 2006 16:16:23 -0000 Message-ID: <3167F18F59B81B4888A4D4C0A1717DD6670F95@mhdexc02.adhel.hitachi-eu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Thread-Index: AccXv4q4zwzAtD3nT8O3rIelX9QxeA== From: "Boschi, Elisa" To: X-OriginalArrivalTime: 04 Dec 2006 16:16:24.0232 (UTC) FILETIME=[8B0B6280:01C717BF] X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com X-Spam-Score: 0.6 (/) X-Scan-Signature: c853ec6e79db43c8dbe6774215da1042 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0532550691==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0532550691== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C717BF.8ABDD2D9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C717BF.8ABDD2D9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gerhard, thanks for your comments. Find my answers (and comments) inline: > >Some comments on Section 8: > > The main advantage of the method specified in this document is the > reduction in the amount of measurement data that has to be > transferred from the Exporter to the Collector. > >I would like to add here "under some conditions" (or something similar) >since the proposed method does not necessarily lead to a reduction of >the amount of data. > I propose to add a sentence at the beginning of section 8: "The main advantage of the method specified in this document is the reduc= tion in the amount of measurement data that has to be transferred from th= e Exporter to the Collector. Note that several factors influence its eff= iciency, as discussed in this section. " and then in section 8.4 swap the two paragraphs, moving the example evalu= ation to the end: "While the goal of this specification is to reduce the bandwidth, the eff= iciency might be limited. Indeed, the efficiency gain is based on the nu= merous redundant information in flows. While the Exporting Process can e= valuate the direct gain for the Flow Records to be exported, it can=92t p= redict whether future Flow Records would contain the information specifie= d by active commonPropertiesID values. This implies that the efficiency = factor of this specification is higher for specific applications where fi= ltering is involved, such as one-way delay or trajectory sampling. The example in section 11.2 below uses IPFIX to export measurement data f= or each received packet. In that case, for a flow of 1000 packets the am= ount of data can be decreased more than 33 percent." > > The transfer of the commonPropertiesIDs originates some overhead. > Note that IPFIX allows reduced-size encoding of Information > Elements. In cases where the range of the commonPropertiesID can be > restricted, reduced-size encoding can be applied also to the > commonPropertiesID, and would result in a further bandwidth > efficiency gain. > >I would say: the overhead of the commonPropertiesID IE is very >significant if 64 bit are used.=20 > >The length of the commonPropertiesID >field also gives you a necessary condition if you ever want to reach a >reduced amount of data: The length must be shorter than the length of >the replaced IEs, otherwise you even increase the amount monitoring data= ! > >As a consequence, reduced-size encoding should be used whenever possible. > what about changing the text in 8.2 as follows: OLD: In cases where the range of the commonPropertiesID can be restricted, red= uced-size encoding can be applied also to the commonPropertiesID, and wou= ld result in a further bandwidth efficiency gain. NEW: In cases where the range of the commonPropertiesID can be restricted, it = is RECOMMENDED to apply reduced-size encoding to the commonPropertiesID,= to achieve a further bandwidth efficiency gain. > > The example in section 11.2 below uses IPFIX to export measurement > data for each received packet. In that case, for a flow of 1000 > packets the amount of data can be decreased more than 33 percent. > >The example in 11.2 refers to OWD measurements, which is a very special >application where the proposed method is very beneficial. Maybe you >should mention "OWD measurements" here, since 33 percent may not be the >general case. > 33 percent is of course not the general case. It is the efficiency gain o= f the example in 11.2... > > While the goal of this specification is to reduce the bandwidth, the > efficiency might be limited. > >As I said before, you can even increase the amount of data with the >proposed method. So I suggest to explain under which conditions the >approach achieves its goal. > we give guidelines in sections 8.1 and 8.4 for that: "The proposed method is most effective using a reliable transport protoco= l for the transfer of the Common Properties...." and: "While the goal of this specification is to reduce the bandwidth, the eff= iciency might be limited. Indeed, the efficiency gain is based on the nu= merous redundant information in flows. While the Exporting Process can e= valuate the direct gain for the Flow Records to be exported, it can=92t p= redict whether future Flow Records would contain the information specifie= d by active commonPropertiesID values. This implies that the efficiency = factor of this specification is higher for specific applications where fi= ltering is involved, such as one-way delay or trajectory sampling." Are you suggesting to add more conditions (which ones?) or is the text ab= ove not clear? =20 >How many times do I need to refer to the common properties until the >amount of data is reduced for the first time? >This should be a simple calculation. Even if this number cannot be >predicted in advance in pratice, it might be useful to estimate when I >should use the approach. > that depends on which ones the Common Properties are, and how many they a= re, don't you think? Or are you proposing to do this for one of the examp= les? Regards, Elisa > >Regards, >Gerhard > >Juergen Quittek wrote: > >>Dear all, >> >>As agreed at the IPFIX session in San Diego last week >>this is the WG last call on the Internet draft on >>Reducing redundancy in IPFIX and PSAMP reports, >>draft-ietf-ipfix-reducing-redundancy-01.txt. >> >>The WG last call starts today and will be closed on >>December 1st. >> >>Please review the draft and send your comments! Please also >>send a message to the mailing list if you reviewed it and >>have no comment to make! >> >>Thanks, >> >> Juergen >> >> >>_______________________________________________ >>IPFIX mailing list >>IPFIX@ietf.org >>https://www1.ietf.org/mailman/listinfo/ipfix > > > > >_______________________________________________ >IPFIX mailing list >IPFIX@ietf.org >https://www1.ietf.org/mailman/listinfo/ipfix > *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* ------_=_NextPart_001_01C717BF.8ABDD2D9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-0= 1.txt until December 1st

Gerhard,

thanks for your comments.
Find my answers (and comments) inline:


>
>Some comments on Section 8:
>
>   The main advantage of the method specified in this docum= ent is the
>   reduction in the amount of measurement data that has to = be
>   transferred from the Exporter to the Collector.
>
>I would like to add here "under some conditions" (or someth= ing similar)
>since the proposed method does not necessarily lead to a reduction of=
>the amount of data.
>


I propose to add a sentence at the beginning of section 8:

"The main advantage of the method specified in this document is the = reduction in the amount of measurement data that has to be transferred fr= om the Exporter to the Collector.  Note that several factors influen= ce its efficiency, as discussed in this section. "

and then in section 8.4 swap the two paragraphs, moving the example evalu= ation to the end:

"While the goal of this specification is to reduce the bandwidth, th= e efficiency might be limited.  Indeed, the efficiency gain is based= on the numerous redundant information in flows.  While the Exportin= g Process can evaluate the direct gain for the Flow Records to be exporte= d, it can’t predict whether future Flow Records would contain the in= formation specified by active commonPropertiesID values.  This impli= es that the efficiency factor of this specification is higher for specifi= c applications where filtering is involved, such as one-way delay or traj= ectory sampling.

The example in section 11.2 below uses IPFIX to export measurement data f= or each received packet.  In that case, for a flow of 1000 packets t= he amount of data can be decreased more than 33 percent."


>
>   The transfer of the commonPropertiesIDs originates some = overhead.
>   Note that IPFIX allows reduced-size encoding of Informat= ion
>   Elements.  In cases where the range of the commonPr= opertiesID can be
>   restricted, reduced-size encoding can be applied also to= the
>   commonPropertiesID, and would result in a further bandwi= dth
>   efficiency gain.
>
>I would say: the overhead of the commonPropertiesID IE is very
>significant if 64 bit are used.
>
>The length of the commonPropertiesID
>field also gives you a necessary condition if you ever want to reach = a
>reduced amount of data: The length must be shorter than the length of=
>the replaced IEs, otherwise you even increase the amount monitoring d= ata!
>
>As a consequence, reduced-size encoding should be used whenever possi= ble.
>


what about changing the text in 8.2 as follows:

OLD:
In cases where the range of the commonPropertiesID can be restricted, red= uced-size encoding can be applied also to the commonPropertiesID, and wou= ld result in a further bandwidth efficiency gain.

NEW:
In cases where the range of the commonPropertiesID can be restricted, it = is  RECOMMENDED to apply reduced-size encoding to the commonProperti= esID, to achieve a further bandwidth efficiency gain.


>
>   The example in section 11.2 below uses IPFIX to export m= easurement
>   data for each received packet.  In that case, for a= flow of 1000
>   packets the amount of data can be decreased more than 33= percent.
>
>The example in 11.2 refers to OWD measurements, which is a very speci= al
>application where the proposed method is very beneficial. Maybe you >should mention "OWD measurements" here, since 33 percent ma= y not be the
>general case.
>

33 percent is of course not the general case. It is the efficiency gain o= f the example in 11.2...

>
>   While the goal of this specification is to reduce the ba= ndwidth, the
>   efficiency might be limited.
>
>As I said before, you can even increase the amount of data with the >proposed method. So I suggest to explain under which conditions the >approach achieves its goal.
>

we give guidelines in sections 8.1 and 8.4 for that:

"The proposed method is most effective using a reliable transport pr= otocol for the transfer of the Common Properties...."

and:

"While the goal of this specification is to reduce the bandwidth, th= e efficiency might be limited.  Indeed, the efficiency gain is based= on the numerous redundant information in flows.  While the Exportin= g Process can evaluate the direct gain for the Flow Records to be exporte= d, it can’t predict whether future Flow Records would contain the in= formation specified by active commonPropertiesID values.  This impli= es that the efficiency factor of this specification is higher for specifi= c applications where filtering is involved, such as one-way delay or traj= ectory sampling."

Are you suggesting to add more conditions (which ones?) or is the text ab= ove not clear?


>How many times do I need to refer to the common properties until the<= BR> >amount of data is reduced for the first time?
>This should be a simple calculation. Even if this number cannot be >predicted in advance in pratice, it might be useful to estimate when = I
>should use the approach.
>

that depends on which ones the Common Properties are, and how many they a= re, don't you think? Or are you proposing to do this for one of the examp= les?

Regards,
Elisa


>
>Regards,
>Gerhard
>
>Juergen Quittek wrote:
>
>>Dear all,
>>
>>As agreed at the IPFIX session in San Diego last week
>>this is the WG last call on the Internet draft on
>>Reducing redundancy in IPFIX and PSAMP reports,
>>draft-ietf-ipfix-reducing-redundancy-01.txt.
>>
>>The WG last call starts today and will be closed on
>>December 1st.
>>
>>Please review the draft and send your comments!  Please also=
>>send a message to the mailing list if you reviewed it and
>>have no comment to make!
>>
>>Thanks,
>>
>>   Juergen
>>
>>
>>_______________________________________________
>>IPFIX mailing list
>>IPFIX@ietf.org
>>https://= www1.ietf.org/mailman/listinfo/ipfix
>
>
>
>
>_______________________________________________
>IPFIX mailing list
>IPFIX@ietf.org
>https://www1= =2Eietf.org/mailman/listinfo/ipfix
>
 

*************************************************************************=
*************************
=20
 E-mail Confidentiality Notice and Disclaimer.
=20
  This email and any files transmitted with it are confidential and are i=
ntended solely for=20
the use of the individual or entity to which they are addressed. Access t=
o this e-mail by=20
anyone else is unauthorised. If you are not the intended recipient, any d=
isclosure,=20
copying, distribution or any action taken or omitted to be taken in relia=
nce on it, is=20
prohibited.=20
  E-mail messages are not necessarily secure.  Hitachi does not accept re=
sponsibility=20
for any changes made to this message after it was sent.=20
  Please note that Hitachi checks outgoing e-mail messages for the presen=
ce of=20
computer viruses.

*************************************************************************=
*************************
------_=_NextPart_001_01C717BF.8ABDD2D9-- --===============0532550691== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============0532550691==-- From ipfix-bounces@ietf.org Mon Dec 04 14:53:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrJqr-0006U0-45; Mon, 04 Dec 2006 14:51:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrJqq-0006Tv-J8 for ipfix@ietf.org; Mon, 04 Dec 2006 14:51:44 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrJqn-0003SO-6T for ipfix@ietf.org; Mon, 04 Dec 2006 14:51:44 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 04 Dec 2006 20:51:39 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB4JpcQ1030047; Mon, 4 Dec 2006 20:51:38 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB4JpbAJ016979; Mon, 4 Dec 2006 20:51:37 +0100 (MET) Received: from [10.61.65.121] (ams3-vpn-dhcp377.cisco.com [10.61.65.121]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA07293; Mon, 4 Dec 2006 19:51:36 GMT Message-ID: <45747C2C.4010604@cisco.com> Date: Mon, 04 Dec 2006 19:51:08 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: ipfix@ietf.org References: <3167F18F59B81B4888A4D4C0A1717DD6670F94@mhdexc02.adhel.hitachi-eu.com> In-Reply-To: <3167F18F59B81B4888A4D4C0A1717DD6670F94@mhdexc02.adhel.hitachi-eu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1105; t=1165261898; x=1166125898; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20communicating=20timeouts |Sender:=20; bh=kLEKUVrEtrLtJgNjCrbkc7BL+2WFsLFKnyD8Qh3VA8w=; b=nznWcS/lUKavKQ4wJLb3X39sKL0XPyeUy4gafIo+K1SeqSTcDhsfsfKkO5pz9YfuG9XhDJ2Z af2MnE5OOy8Nc1NVyF/vsQ+uLLur2WKy5rzjLeUP7XVE117xCUPfdKSj; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "Boschi, Elisa" , boschie@tik.ee.ethz.ch Subject: [IPFIX] communicating timeouts X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear all, Elisa wrote: > OK. But in the last sentence I'd prefer keeping "refresh timeout" > instead of just "timeout": > > " The Common Property lifetime at the Collecting Process MUST be at > least 3 times higher than the Common Property refresh timeout configured > on the Exporting Process." There's a lot of talk about - and reliance on - timeouts in IPFIX. But there's currently no way for exporters to communicate timeouts to collectors in band; all communication must be done OOB (eg, by an operator). It'd be really straightforward to send a template lifetime IE or common properties ID lifetime IE in an option with the relevant template ID or CP ID as scope. But it's not a very efficient method, since you'd have to repeat this N times, once per template / CP ID - though we could export using another IE that scopes a single lifetime to the system as a whole, or to the transport session. I believe that Brian and Andrew have some ideas about this in the upcoming managing scope draft. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Dec 04 14:53:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrJqr-0006U0-45; Mon, 04 Dec 2006 14:51:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrJqq-0006Tv-J8 for ipfix@ietf.org; Mon, 04 Dec 2006 14:51:44 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrJqn-0003SO-6T for ipfix@ietf.org; Mon, 04 Dec 2006 14:51:44 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 04 Dec 2006 20:51:39 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB4JpcQ1030047; Mon, 4 Dec 2006 20:51:38 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB4JpbAJ016979; Mon, 4 Dec 2006 20:51:37 +0100 (MET) Received: from [10.61.65.121] (ams3-vpn-dhcp377.cisco.com [10.61.65.121]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA07293; Mon, 4 Dec 2006 19:51:36 GMT Message-ID: <45747C2C.4010604@cisco.com> Date: Mon, 04 Dec 2006 19:51:08 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: ipfix@ietf.org References: <3167F18F59B81B4888A4D4C0A1717DD6670F94@mhdexc02.adhel.hitachi-eu.com> In-Reply-To: <3167F18F59B81B4888A4D4C0A1717DD6670F94@mhdexc02.adhel.hitachi-eu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1105; t=1165261898; x=1166125898; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20communicating=20timeouts |Sender:=20; bh=kLEKUVrEtrLtJgNjCrbkc7BL+2WFsLFKnyD8Qh3VA8w=; b=nznWcS/lUKavKQ4wJLb3X39sKL0XPyeUy4gafIo+K1SeqSTcDhsfsfKkO5pz9YfuG9XhDJ2Z af2MnE5OOy8Nc1NVyF/vsQ+uLLur2WKy5rzjLeUP7XVE117xCUPfdKSj; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "Boschi, Elisa" , boschie@tik.ee.ethz.ch Subject: [IPFIX] communicating timeouts X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear all, Elisa wrote: > OK. But in the last sentence I'd prefer keeping "refresh timeout" > instead of just "timeout": > > " The Common Property lifetime at the Collecting Process MUST be at > least 3 times higher than the Common Property refresh timeout configured > on the Exporting Process." There's a lot of talk about - and reliance on - timeouts in IPFIX. But there's currently no way for exporters to communicate timeouts to collectors in band; all communication must be done OOB (eg, by an operator). It'd be really straightforward to send a template lifetime IE or common properties ID lifetime IE in an option with the relevant template ID or CP ID as scope. But it's not a very efficient method, since you'd have to repeat this N times, once per template / CP ID - though we could export using another IE that scopes a single lifetime to the system as a whole, or to the transport session. I believe that Brian and Andrew have some ideas about this in the upcoming managing scope draft. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 05 04:39:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWkF-0003gh-Md; Tue, 05 Dec 2006 04:37:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWkD-0003Mi-VL for ipfix@ietf.org; Tue, 05 Dec 2006 04:37:46 -0500 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrWkC-0001aa-8Y for ipfix@ietf.org; Tue, 05 Dec 2006 04:37:45 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 7C721125; Tue, 5 Dec 2006 10:37:42 +0100 (MET) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28798-03; Tue, 5 Dec 2006 10:37:39 +0100 (NFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 4282311C; Tue, 5 Dec 2006 10:37:39 +0100 (MET) Message-ID: <45753E11.2040100@informatik.uni-tuebingen.de> Date: Tue, 05 Dec 2006 10:38:25 +0100 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Boschi, Elisa" Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <3167F18F59B81B4888A4D4C0A1717DD6670F95@mhdexc02.adhel.hitachi-eu.com> In-Reply-To: <3167F18F59B81B4888A4D4C0A1717DD6670F95@mhdexc02.adhel.hitachi-eu.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Elisa, Boschi, Elisa wrote: >> The main advantage of the method specified in this document is the >> reduction in the amount of measurement data that has to be >> transferred from the Exporter to the Collector. >> >>I would like to add here "under some conditions" (or something similar) >>since the proposed method does not necessarily lead to a reduction of >>the amount of data. >> > > I propose to add a sentence at the beginning of section 8: > > "The main advantage of the method specified in this document is the > reduction in the amount of measurement data that has to be transferred > from the Exporter to the Collector. Note that several factors influence > its efficiency, as discussed in this section. " You write "main advantage". Are there any other advantages than reducing the amount of data? Then you should mention them. If not, what do you think about: "The objective of the method..." This would also leave it open if this goal is actually achieved or not. Otherwise, your added sentence is fine. > and then in section 8.4 swap the two paragraphs, moving the example > evaluation to the end: > > "While the goal of this specification is to reduce the bandwidth, the > efficiency might be limited. Indeed, the efficiency gain is based on > the numerous redundant information in flows. While the Exporting > Process can evaluate the direct gain for the Flow Records to be > exported, it can?t predict whether future Flow Records would contain the > information specified by active commonPropertiesID values. This implies > that the efficiency factor of this specification is higher for specific > applications where filtering is involved, such as one-way delay or > trajectory sampling. You could remark here that the amount of data might even increase under bad conditions. > The example in section 11.2 below uses IPFIX to export measurement data > for each received packet. In that case, for a flow of 1000 packets the > amount of data can be decreased more than 33 percent." >> The transfer of the commonPropertiesIDs originates some overhead. >> Note that IPFIX allows reduced-size encoding of Information >> Elements. In cases where the range of the commonPropertiesID can be >> restricted, reduced-size encoding can be applied also to the >> commonPropertiesID, and would result in a further bandwidth >> efficiency gain. >> >>I would say: the overhead of the commonPropertiesID IE is very >>significant if 64 bit are used. >> >>The length of the commonPropertiesID >>field also gives you a necessary condition if you ever want to reach a >>reduced amount of data: The length must be shorter than the length of >>the replaced IEs, otherwise you even increase the amount monitoring data! >> >>As a consequence, reduced-size encoding should be used whenever possible. >> > > > what about changing the text in 8.2 as follows: > > OLD: > In cases where the range of the commonPropertiesID can be restricted, > reduced-size encoding can be applied also to the commonPropertiesID, and > would result in a further bandwidth efficiency gain. > > NEW: > In cases where the range of the commonPropertiesID can be restricted, it > is RECOMMENDED to apply reduced-size encoding to the > commonPropertiesID, to achieve a further bandwidth efficiency gain. Ok. You should add that the length of the commonPropertiesID field has to be shorter than the length of the replaced fields, otherwise the amount of data is increased. You could note that a big difference between the length of the replaced fields and the length of the commonPropertiesID field increases the efficiency gain. >> While the goal of this specification is to reduce the bandwidth, the >> efficiency might be limited. >> >>As I said before, you can even increase the amount of data with the >>proposed method. So I suggest to explain under which conditions the >>approach achieves its goal. >> > > we give guidelines in sections 8.1 and 8.4 for that: > > "The proposed method is most effective using a reliable transport > protocol for the transfer of the Common Properties...." > > and: > > "While the goal of this specification is to reduce the bandwidth, the > efficiency might be limited. Indeed, the efficiency gain is based on > the numerous redundant information in flows. While the Exporting > Process can evaluate the direct gain for the Flow Records to be > exported, it can?t predict whether future Flow Records would contain the > information specified by active commonPropertiesID values. This implies > that the efficiency factor of this specification is higher for specific > applications where filtering is involved, such as one-way delay or > trajectory sampling." > > Are you suggesting to add more conditions (which ones?) or is the text > above not clear? See my suggestions above. >>How many times do I need to refer to the common properties until the >>amount of data is reduced for the first time? >>This should be a simple calculation. Even if this number cannot be >>predicted in advance in pratice, it might be useful to estimate when I >>should use the approach. >> > > that depends on which ones the Common Properties are, and how many they > are, don't you think? Or are you proposing to do this for one of the > examples? A calculation of thumb is: 1) I save X bytes in my flow records (difference between length of replaced fields and length of commonPropertiesID field) 2) I need my Y bytes to send the option record => The amount if data is reduced after Y/X flow records sent This calculation neglects the overhead of additional templates and set headers. But maybe these considerations are more interesting for an academic publication than for a standard document. Regards, Gerhard _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 05 04:39:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWkF-0003gh-Md; Tue, 05 Dec 2006 04:37:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWkD-0003Mi-VL for ipfix@ietf.org; Tue, 05 Dec 2006 04:37:46 -0500 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrWkC-0001aa-8Y for ipfix@ietf.org; Tue, 05 Dec 2006 04:37:45 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 7C721125; Tue, 5 Dec 2006 10:37:42 +0100 (MET) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28798-03; Tue, 5 Dec 2006 10:37:39 +0100 (NFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 4282311C; Tue, 5 Dec 2006 10:37:39 +0100 (MET) Message-ID: <45753E11.2040100@informatik.uni-tuebingen.de> Date: Tue, 05 Dec 2006 10:38:25 +0100 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Boschi, Elisa" Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <3167F18F59B81B4888A4D4C0A1717DD6670F95@mhdexc02.adhel.hitachi-eu.com> In-Reply-To: <3167F18F59B81B4888A4D4C0A1717DD6670F95@mhdexc02.adhel.hitachi-eu.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Elisa, Boschi, Elisa wrote: >> The main advantage of the method specified in this document is the >> reduction in the amount of measurement data that has to be >> transferred from the Exporter to the Collector. >> >>I would like to add here "under some conditions" (or something similar) >>since the proposed method does not necessarily lead to a reduction of >>the amount of data. >> > > I propose to add a sentence at the beginning of section 8: > > "The main advantage of the method specified in this document is the > reduction in the amount of measurement data that has to be transferred > from the Exporter to the Collector. Note that several factors influence > its efficiency, as discussed in this section. " You write "main advantage". Are there any other advantages than reducing the amount of data? Then you should mention them. If not, what do you think about: "The objective of the method..." This would also leave it open if this goal is actually achieved or not. Otherwise, your added sentence is fine. > and then in section 8.4 swap the two paragraphs, moving the example > evaluation to the end: > > "While the goal of this specification is to reduce the bandwidth, the > efficiency might be limited. Indeed, the efficiency gain is based on > the numerous redundant information in flows. While the Exporting > Process can evaluate the direct gain for the Flow Records to be > exported, it can?t predict whether future Flow Records would contain the > information specified by active commonPropertiesID values. This implies > that the efficiency factor of this specification is higher for specific > applications where filtering is involved, such as one-way delay or > trajectory sampling. You could remark here that the amount of data might even increase under bad conditions. > The example in section 11.2 below uses IPFIX to export measurement data > for each received packet. In that case, for a flow of 1000 packets the > amount of data can be decreased more than 33 percent." >> The transfer of the commonPropertiesIDs originates some overhead. >> Note that IPFIX allows reduced-size encoding of Information >> Elements. In cases where the range of the commonPropertiesID can be >> restricted, reduced-size encoding can be applied also to the >> commonPropertiesID, and would result in a further bandwidth >> efficiency gain. >> >>I would say: the overhead of the commonPropertiesID IE is very >>significant if 64 bit are used. >> >>The length of the commonPropertiesID >>field also gives you a necessary condition if you ever want to reach a >>reduced amount of data: The length must be shorter than the length of >>the replaced IEs, otherwise you even increase the amount monitoring data! >> >>As a consequence, reduced-size encoding should be used whenever possible. >> > > > what about changing the text in 8.2 as follows: > > OLD: > In cases where the range of the commonPropertiesID can be restricted, > reduced-size encoding can be applied also to the commonPropertiesID, and > would result in a further bandwidth efficiency gain. > > NEW: > In cases where the range of the commonPropertiesID can be restricted, it > is RECOMMENDED to apply reduced-size encoding to the > commonPropertiesID, to achieve a further bandwidth efficiency gain. Ok. You should add that the length of the commonPropertiesID field has to be shorter than the length of the replaced fields, otherwise the amount of data is increased. You could note that a big difference between the length of the replaced fields and the length of the commonPropertiesID field increases the efficiency gain. >> While the goal of this specification is to reduce the bandwidth, the >> efficiency might be limited. >> >>As I said before, you can even increase the amount of data with the >>proposed method. So I suggest to explain under which conditions the >>approach achieves its goal. >> > > we give guidelines in sections 8.1 and 8.4 for that: > > "The proposed method is most effective using a reliable transport > protocol for the transfer of the Common Properties...." > > and: > > "While the goal of this specification is to reduce the bandwidth, the > efficiency might be limited. Indeed, the efficiency gain is based on > the numerous redundant information in flows. While the Exporting > Process can evaluate the direct gain for the Flow Records to be > exported, it can?t predict whether future Flow Records would contain the > information specified by active commonPropertiesID values. This implies > that the efficiency factor of this specification is higher for specific > applications where filtering is involved, such as one-way delay or > trajectory sampling." > > Are you suggesting to add more conditions (which ones?) or is the text > above not clear? See my suggestions above. >>How many times do I need to refer to the common properties until the >>amount of data is reduced for the first time? >>This should be a simple calculation. Even if this number cannot be >>predicted in advance in pratice, it might be useful to estimate when I >>should use the approach. >> > > that depends on which ones the Common Properties are, and how many they > are, don't you think? Or are you proposing to do this for one of the > examples? A calculation of thumb is: 1) I save X bytes in my flow records (difference between length of replaced fields and length of commonPropertiesID field) 2) I need my Y bytes to send the option record => The amount if data is reduced after Y/X flow records sent This calculation neglects the overhead of additional templates and set headers. But maybe these considerations are more interesting for an academic publication than for a standard document. Regards, Gerhard _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 05 06:28:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrYSW-0001Y1-5S; Tue, 05 Dec 2006 06:27:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrYSV-0001Xt-7U for ipfix@ietf.org; Tue, 05 Dec 2006 06:27:35 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrYST-0000SY-Mn for ipfix@ietf.org; Tue, 05 Dec 2006 06:27:35 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id kB5BRNF12546; Tue, 5 Dec 2006 12:27:23 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [IPFIX] IPv6 care-of and home address Date: Tue, 5 Dec 2006 12:27:21 +0100 Message-ID: <70524A4436C03E43A293958B505008B6568FE6@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] IPv6 care-of and home address Thread-Index: AccUsFFDl8zYBh09TW2n89HijOST4wDrpm9A From: "Schmoll, Carsten" To: "Andrew Johnson" X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Andrew, I think I tend to disagree: Afaik mobile IPv6 explicitely introduced the=20 type 2 routing header for transporting the HoA: "The Type 2 Routing header is different from the Type 0 Routing header = defined in RFC 2460 in that it can only store a single address and is = only specified for use with Mobile IPv6. The Type 0 Routing header can = store multiple addresses and is processed by routers for generalized = source routing. Using a different routing type allows firewalls to treat = source-routed packets differently from packets sent directly by Mobile = IPv6-capable correspondent nodes to mobile nodes that are away from = home." Similarly this is true for the Destinatio Option of Type 201 used in = MIPv6: "The Home Address option in the Destination Options extension header is = used to indicate the home address of the mobile node and is included in = binding updates sent to home agents and packets sent directly to Mobile = IPv6-capable correspondent nodes by a mobile node when it is away from = home when a binding exists." Therefore I would suggest to keep the originally proposed names and in the text for the draft mention explicitely where these HoAs were taken from. Regards, Carsten. > -----Original Message----- > From: Andrew Johnson [mailto:andrjohn@cisco.com]=20 > Sent: Thursday, November 30, 2006 7:49 PM > To: Schmoll, Carsten > Cc: Juergen Quittek; ipfix@ietf.org > Subject: Re: [IPFIX] IPv6 care-of and home address >=20 > Schmoll, Carsten wrote: > > Andrew, > >=20 > > I was wondering what "kind of" IP address my > > collector will receive when there is only=20 > > sourceIPv6Address in the accounting flow record. > >=20 > > But I agree now that we should say that=20 > > in a mobile environment an sourceIPv6Address > > will always denote the care-of address from > > the usual place in the IPv6 header. > >=20 > > We probably want to note this in the info model. > >=20 > > So I change my proposal to just request: > >=20 > > sourceIPv6HomeAddress > > destinationIPv6HomeAddress >=20 > The address from the IPv6 routing header is not specifically > a "Home Address" is it? While the Mobile IPv6 environment > conceptualises it this way, you really are collecting is an > Ipv6RoutingHeaderIpv6Address. >=20 > Similarly for the Destination Extension header. >=20 > I'm not sure about the names there, but you get the idea. >=20 > Cheers >=20 > Andrew >=20 >=20 >=20 > > J=FCrgen: do you agree too? > > May a write some short text for the info model on that? > >=20 > > Best regards, > > Carsten. > > =20 > >=20 > >> -----Original Message----- > >> From: Andrew Johnson [mailto:andrjohn@cisco.com]=20 > >> Sent: Thursday, November 30, 2006 4:08 PM > >> To: Schmoll, Carsten > >> Cc: Juergen Quittek; ipfix@ietf.org > >> Subject: Re: [IPFIX] IPv6 care-of and home address > >> > >> Hi Carsten > >> > >> The Routing EH and Destination EH have the source and > >> destination Home Addresses in them, so new new fields > >> for them make sense. > >> > >> The Care of Addresses are just from the IPv6 header, so > >> why do you need new types for them? > >> > >> regards > >> > >> Andrew > >> > >> > >> Schmoll, Carsten wrote: > >>> Dear all, > >>> > >>> we are currently investigating on a prototype to send > >>> accounted IP flow information in a mobile IPv6 environment. > >>> > >>> For reasons of simplicity and speed we usually export the > >>> care-of address (CoA) and the correspondent node's IP > >>> address as sourceIPv6Address and destinationIPv6Address.=20 > >>> > >>> In case of multiple users on one terminal however (or one > >>> user making use of multiple of his identities) we'll have > >>> to capture and export the home address (HoA) too. The HoA > >>> is embedded in an IPv6 extension header of either type > >>> Routing EH (43) or the Destination Options EH (60). > >>> > >>> This would result then in a flow record with two IPv6 source > >>> addresses. Even though repetition of the sourceIPv6 address > >>> is legal I would like to propose additional IEs to avoid > >>> ambiguity. These could be: > >>> > >>> sourceIPv6CareOfAddress =20 > >>> sourceIPv6HomeAddress > >>> destinationIPv6CareOfAddress =20 > >>> destinationIPv6HomeAddress > >>> > >>> This would also cover the case where both endpoints of a=20 > >>> communication are mobile nodes. > >>> > >>> What do you think? > >>> > >>> Best regards, > >>> Carsten. > >>> > >>> =20 > >>>> -----Original Message----- > >>>> From: Andrew Johnson [mailto:andrjohn@cisco.com]=20 > >>>> Sent: Tuesday, November 07, 2006 11:27 PM > >>>> To: Juergen Quittek > >>>> Cc: Schmoll, Carsten; ipfix@ietf.org > >>>> Subject: Re: [IPFIX] IPv6 care-of and home address > >>>> > >>>> Juergen Quittek wrote: > >>>>> Carsten, > >>>>> > >>>>> I do understand how these addresses are associated with > >>>>> an interface. But how do you think are they associated > >>>>> with a certain flow? > >>>> That really depends on the common properties that define > >>>> Carsten's flow. Perhaps these different properties could > >>>> part of an Option Template Record that provides information > >>>> on an interface. > >>>> > >>>> However, it seems that "The IPv6 source address in the IP > >>>> packet header" is the wrong element to use these and new > >>>> ones should be requested if there is an application in > >>>> mind. > >>>> > >>>> > >>>> regards > >>>> > >>>> Andrew > >>>> > >>>> > >> >=20 >=20 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 05 06:28:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrYSW-0001Y1-5S; Tue, 05 Dec 2006 06:27:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrYSV-0001Xt-7U for ipfix@ietf.org; Tue, 05 Dec 2006 06:27:35 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrYST-0000SY-Mn for ipfix@ietf.org; Tue, 05 Dec 2006 06:27:35 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id kB5BRNF12546; Tue, 5 Dec 2006 12:27:23 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [IPFIX] IPv6 care-of and home address Date: Tue, 5 Dec 2006 12:27:21 +0100 Message-ID: <70524A4436C03E43A293958B505008B6568FE6@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] IPv6 care-of and home address Thread-Index: AccUsFFDl8zYBh09TW2n89HijOST4wDrpm9A From: "Schmoll, Carsten" To: "Andrew Johnson" X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Andrew, I think I tend to disagree: Afaik mobile IPv6 explicitely introduced the=20 type 2 routing header for transporting the HoA: "The Type 2 Routing header is different from the Type 0 Routing header = defined in RFC 2460 in that it can only store a single address and is = only specified for use with Mobile IPv6. The Type 0 Routing header can = store multiple addresses and is processed by routers for generalized = source routing. Using a different routing type allows firewalls to treat = source-routed packets differently from packets sent directly by Mobile = IPv6-capable correspondent nodes to mobile nodes that are away from = home." Similarly this is true for the Destinatio Option of Type 201 used in = MIPv6: "The Home Address option in the Destination Options extension header is = used to indicate the home address of the mobile node and is included in = binding updates sent to home agents and packets sent directly to Mobile = IPv6-capable correspondent nodes by a mobile node when it is away from = home when a binding exists." Therefore I would suggest to keep the originally proposed names and in the text for the draft mention explicitely where these HoAs were taken from. Regards, Carsten. > -----Original Message----- > From: Andrew Johnson [mailto:andrjohn@cisco.com]=20 > Sent: Thursday, November 30, 2006 7:49 PM > To: Schmoll, Carsten > Cc: Juergen Quittek; ipfix@ietf.org > Subject: Re: [IPFIX] IPv6 care-of and home address >=20 > Schmoll, Carsten wrote: > > Andrew, > >=20 > > I was wondering what "kind of" IP address my > > collector will receive when there is only=20 > > sourceIPv6Address in the accounting flow record. > >=20 > > But I agree now that we should say that=20 > > in a mobile environment an sourceIPv6Address > > will always denote the care-of address from > > the usual place in the IPv6 header. > >=20 > > We probably want to note this in the info model. > >=20 > > So I change my proposal to just request: > >=20 > > sourceIPv6HomeAddress > > destinationIPv6HomeAddress >=20 > The address from the IPv6 routing header is not specifically > a "Home Address" is it? While the Mobile IPv6 environment > conceptualises it this way, you really are collecting is an > Ipv6RoutingHeaderIpv6Address. >=20 > Similarly for the Destination Extension header. >=20 > I'm not sure about the names there, but you get the idea. >=20 > Cheers >=20 > Andrew >=20 >=20 >=20 > > J=FCrgen: do you agree too? > > May a write some short text for the info model on that? > >=20 > > Best regards, > > Carsten. > > =20 > >=20 > >> -----Original Message----- > >> From: Andrew Johnson [mailto:andrjohn@cisco.com]=20 > >> Sent: Thursday, November 30, 2006 4:08 PM > >> To: Schmoll, Carsten > >> Cc: Juergen Quittek; ipfix@ietf.org > >> Subject: Re: [IPFIX] IPv6 care-of and home address > >> > >> Hi Carsten > >> > >> The Routing EH and Destination EH have the source and > >> destination Home Addresses in them, so new new fields > >> for them make sense. > >> > >> The Care of Addresses are just from the IPv6 header, so > >> why do you need new types for them? > >> > >> regards > >> > >> Andrew > >> > >> > >> Schmoll, Carsten wrote: > >>> Dear all, > >>> > >>> we are currently investigating on a prototype to send > >>> accounted IP flow information in a mobile IPv6 environment. > >>> > >>> For reasons of simplicity and speed we usually export the > >>> care-of address (CoA) and the correspondent node's IP > >>> address as sourceIPv6Address and destinationIPv6Address.=20 > >>> > >>> In case of multiple users on one terminal however (or one > >>> user making use of multiple of his identities) we'll have > >>> to capture and export the home address (HoA) too. The HoA > >>> is embedded in an IPv6 extension header of either type > >>> Routing EH (43) or the Destination Options EH (60). > >>> > >>> This would result then in a flow record with two IPv6 source > >>> addresses. Even though repetition of the sourceIPv6 address > >>> is legal I would like to propose additional IEs to avoid > >>> ambiguity. These could be: > >>> > >>> sourceIPv6CareOfAddress =20 > >>> sourceIPv6HomeAddress > >>> destinationIPv6CareOfAddress =20 > >>> destinationIPv6HomeAddress > >>> > >>> This would also cover the case where both endpoints of a=20 > >>> communication are mobile nodes. > >>> > >>> What do you think? > >>> > >>> Best regards, > >>> Carsten. > >>> > >>> =20 > >>>> -----Original Message----- > >>>> From: Andrew Johnson [mailto:andrjohn@cisco.com]=20 > >>>> Sent: Tuesday, November 07, 2006 11:27 PM > >>>> To: Juergen Quittek > >>>> Cc: Schmoll, Carsten; ipfix@ietf.org > >>>> Subject: Re: [IPFIX] IPv6 care-of and home address > >>>> > >>>> Juergen Quittek wrote: > >>>>> Carsten, > >>>>> > >>>>> I do understand how these addresses are associated with > >>>>> an interface. But how do you think are they associated > >>>>> with a certain flow? > >>>> That really depends on the common properties that define > >>>> Carsten's flow. Perhaps these different properties could > >>>> part of an Option Template Record that provides information > >>>> on an interface. > >>>> > >>>> However, it seems that "The IPv6 source address in the IP > >>>> packet header" is the wrong element to use these and new > >>>> ones should be requested if there is an application in > >>>> mind. > >>>> > >>>> > >>>> regards > >>>> > >>>> Andrew > >>>> > >>>> > >> >=20 >=20 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 05 07:52:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrZks-0001mZ-P5; Tue, 05 Dec 2006 07:50:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrZkr-0001mU-JQ for ipfix@ietf.org; Tue, 05 Dec 2006 07:50:37 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrZkq-0000Jy-4t for ipfix@ietf.org; Tue, 05 Dec 2006 07:50:37 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB5CoWR00868; Tue, 5 Dec 2006 13:50:32 +0100 (CET) Received: from [10.61.80.100] (ams3-vpn-dhcp4197.cisco.com [10.61.80.100]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB5CoVW28713; Tue, 5 Dec 2006 13:50:31 +0100 (CET) Message-ID: <45756B12.8020109@cisco.com> Date: Tue, 05 Dec 2006 13:50:26 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: ipfix@ietf.org, Elisa Boschi X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Brian, Thanks for your comments. See inline. Note that, for clarity purposes, I only kept a few comments > > > > Second, there appears to be some spurious mention of templates in > section 7, presumably as the cpId management text evolved from > template management text: Trying to keep the parity with [IPFIX-PROTO], I simply adapted the text ... a little bit too quickly :( > > > 7 para 7 OLD: > > If a Collecting Process receives a Common Properties Withdrawal > message, the Collecting Process MUST delete the corresponding Common > Properties associated with the specific SCTP association and specific > Observation Domain, and stop decoding IPFIX Messages that use the > withdrawn Templates. > > 7 para 7 NEW: > > If a Collecting Process receives a Common Properties Withdrawal > message, the Collecting Process MUST delete the corresponding Common > Properties associated with the specific SCTP association and specific > Observation Domain. I would like to add, "and stop decoding IPFIX Messages that use the withdrawn Common Properties" This would be in line with [IPFIX-PROTO] "The Collecting Process's Side" section: If a Collecting Process receives a Template Withdraw Message, the Collecting Process MUST delete the corresponding Template Records associated with the specific SCTP association and specific Observation Domain, and stop decoding IPFIX Messages that use the withdrawn Templates. > > 7.1 para 3 OLD: > > The Collecting Process MUST NOT decode any further Data Records which > are associated with the expired Common Properties. If a Common > Property is refreshed with a Template Record that differs from the > previous received Template Record, the Collecting Process SHOULD log > a warning and replace the previous received Common Property with the > new one. The Template lifetime at the Collecting Process MUST be at > least 3 times higher than the Template refresh timeout configured on > the Exporting Process. > > 7.1 para 3 NEW: > > The Collecting Process MUST NOT decode any further Data Records which > are associated with the expired Common Properties. If a Common > Property is refreshed with a definition that differs from the > previous definition, the Collecting Process SHOULD log > a warning and replace the previous received Common Property with the > new one. The Common Property lifetime at the Collecting Process > MUST be at > least 3 times higher than the Common Property timeout configured on > the Exporting Process. In this case, you insert a new term "Common Property timeout". I propose: The Collecting Process MUST NOT decode any further Data Records which are associated with the expired Common Properties. If a Common Property is refreshed with a definition that differs from the previous definition, the Collecting Process SHOULD log a warning and replace the previous received Common Property with the new one. The Common Property lifetime at the Collecting Process MUST be at least 3 times higher than the refresh timeout of the Template used to export the Common Property definition, configured on the Exporting Process. Regards, Benoit. > > > > > Regards, > > Brian > > On Nov 13, 2006, at 2:17 PM, Juergen Quittek wrote: > >> Dear all, >> >> As agreed at the IPFIX session in San Diego last week >> this is the WG last call on the Internet draft on >> Reducing redundancy in IPFIX and PSAMP reports, >> draft-ietf-ipfix-reducing-redundancy-01.txt. >> >> The WG last call starts today and will be closed on >> December 1st. >> >> Please review the draft and send your comments! Please also >> send a message to the mailing list if you reviewed it and >> have no comment to make! >> >> Thanks, >> >> Juergen >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 05 07:52:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrZks-0001mZ-P5; Tue, 05 Dec 2006 07:50:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrZkr-0001mU-JQ for ipfix@ietf.org; Tue, 05 Dec 2006 07:50:37 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrZkq-0000Jy-4t for ipfix@ietf.org; Tue, 05 Dec 2006 07:50:37 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB5CoWR00868; Tue, 5 Dec 2006 13:50:32 +0100 (CET) Received: from [10.61.80.100] (ams3-vpn-dhcp4197.cisco.com [10.61.80.100]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB5CoVW28713; Tue, 5 Dec 2006 13:50:31 +0100 (CET) Message-ID: <45756B12.8020109@cisco.com> Date: Tue, 05 Dec 2006 13:50:26 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: ipfix@ietf.org, Elisa Boschi X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Brian, Thanks for your comments. See inline. Note that, for clarity purposes, I only kept a few comments > > > > Second, there appears to be some spurious mention of templates in > section 7, presumably as the cpId management text evolved from > template management text: Trying to keep the parity with [IPFIX-PROTO], I simply adapted the text ... a little bit too quickly :( > > > 7 para 7 OLD: > > If a Collecting Process receives a Common Properties Withdrawal > message, the Collecting Process MUST delete the corresponding Common > Properties associated with the specific SCTP association and specific > Observation Domain, and stop decoding IPFIX Messages that use the > withdrawn Templates. > > 7 para 7 NEW: > > If a Collecting Process receives a Common Properties Withdrawal > message, the Collecting Process MUST delete the corresponding Common > Properties associated with the specific SCTP association and specific > Observation Domain. I would like to add, "and stop decoding IPFIX Messages that use the withdrawn Common Properties" This would be in line with [IPFIX-PROTO] "The Collecting Process's Side" section: If a Collecting Process receives a Template Withdraw Message, the Collecting Process MUST delete the corresponding Template Records associated with the specific SCTP association and specific Observation Domain, and stop decoding IPFIX Messages that use the withdrawn Templates. > > 7.1 para 3 OLD: > > The Collecting Process MUST NOT decode any further Data Records which > are associated with the expired Common Properties. If a Common > Property is refreshed with a Template Record that differs from the > previous received Template Record, the Collecting Process SHOULD log > a warning and replace the previous received Common Property with the > new one. The Template lifetime at the Collecting Process MUST be at > least 3 times higher than the Template refresh timeout configured on > the Exporting Process. > > 7.1 para 3 NEW: > > The Collecting Process MUST NOT decode any further Data Records which > are associated with the expired Common Properties. If a Common > Property is refreshed with a definition that differs from the > previous definition, the Collecting Process SHOULD log > a warning and replace the previous received Common Property with the > new one. The Common Property lifetime at the Collecting Process > MUST be at > least 3 times higher than the Common Property timeout configured on > the Exporting Process. In this case, you insert a new term "Common Property timeout". I propose: The Collecting Process MUST NOT decode any further Data Records which are associated with the expired Common Properties. If a Common Property is refreshed with a definition that differs from the previous definition, the Collecting Process SHOULD log a warning and replace the previous received Common Property with the new one. The Common Property lifetime at the Collecting Process MUST be at least 3 times higher than the refresh timeout of the Template used to export the Common Property definition, configured on the Exporting Process. Regards, Benoit. > > > > > Regards, > > Brian > > On Nov 13, 2006, at 2:17 PM, Juergen Quittek wrote: > >> Dear all, >> >> As agreed at the IPFIX session in San Diego last week >> this is the WG last call on the Internet draft on >> Reducing redundancy in IPFIX and PSAMP reports, >> draft-ietf-ipfix-reducing-redundancy-01.txt. >> >> The WG last call starts today and will be closed on >> December 1st. >> >> Please review the draft and send your comments! Please also >> send a message to the mailing list if you reviewed it and >> have no comment to make! >> >> Thanks, >> >> Juergen >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 05 08:32:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GraPB-0006io-0E; Tue, 05 Dec 2006 08:32:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GraP9-0006ii-Vp for ipfix@ietf.org; Tue, 05 Dec 2006 08:32:15 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GraP8-0006br-F3 for ipfix@ietf.org; Tue, 05 Dec 2006 08:32:15 -0500 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kB5DW72I018092 for ; Tue, 5 Dec 2006 08:32:07 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kB5DVKiJ018024 for ; Tue, 5 Dec 2006 08:31:20 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kB5DVJ5U018021; Tue, 05 Dec 2006 08:31:20 -0500 (EST) Received: from [128.237.236.103] (vpn-10-25-4-19.remote.cert.org [10.25.4.19]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.66) with ESMTP id kB5DVJwe019145; Tue, 5 Dec 2006 08:31:19 -0500 In-Reply-To: <45747C2C.4010604@cisco.com> References: <3167F18F59B81B4888A4D4C0A1717DD6670F94@mhdexc02.adhel.hitachi-eu.com> <45747C2C.4010604@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Brian Trammell Date: Tue, 5 Dec 2006 08:30:26 -0500 To: Paul Aitken X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Elisa Boschi , Elisa Boschi , ipfix@ietf.org Subject: [IPFIX] Re: communicating timeouts X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org On Dec 4, 2006, at 2:51 PM, Paul Aitken wrote: > Dear all, > > Elisa wrote: > >> OK. But in the last sentence I'd prefer keeping "refresh timeout" >> instead of just "timeout": >> " The Common Property lifetime at the Collecting Process MUST be >> at least 3 times higher than the Common Property refresh timeout >> configured on the Exporting Process." > > There's a lot of talk about - and reliance on - timeouts in IPFIX. Only when using UDP. When using SCTP or TCP, the Transport Session termination performs the same function as the template/cpId timeouts. > But there's currently no way for exporters to communicate timeouts > to collectors in band; all communication must be done OOB (eg, by > an operator). Indeed. I don't actually see this as much of an impediment, though. Keep in mind this is only a consideration for UDP. In the UDP case, the CP and EP are almost certainly within the same administrative domain, with the same operator. OOB configuration is not quite so bad here because the operator will notice timeout errors in the log during deployment testing and adjust either the CP or EP timeout accordingly. Once such is done, it can be forgotten. A more advanced CP may certainly auto-adjust its expectation of the EP timeouts based on the observed retransmission delay. > It'd be really straightforward to send a template lifetime IE or > common properties ID lifetime IE in an option with the relevant > template ID or CP ID as scope. > > But it's not a very efficient method, since you'd have to repeat > this N times, once per template / CP ID - though we could export > using another IE that scopes a single lifetime to the system as a > whole, or to the transport session. Here you have a circular definition: The transport session for UDP (the only transport for which all this timeout stuff is relevant) is defined in terms of its template timeouts. So you can't set the timeout within a session for a session which is itself defined by the CP's previous estimation of session timeout; at least not with any solid expectation that such will work. However, exporting timeout information scoped to an EP identifier does not have the same issue. > I believe that Brian and Andrew have some ideas about this in the > upcoming managing scope draft. All the above having been said, yes. The managing scope draft, among other things, will propose validFrom and validUntil information elements, which can be scoped to templateIDs or cpIDs, and key the time to the Export Time field in the IPFIX Message header. Cheers, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 05 08:32:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GraPB-0006io-0E; Tue, 05 Dec 2006 08:32:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GraP9-0006ii-Vp for ipfix@ietf.org; Tue, 05 Dec 2006 08:32:15 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GraP8-0006br-F3 for ipfix@ietf.org; Tue, 05 Dec 2006 08:32:15 -0500 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kB5DW72I018092 for ; Tue, 5 Dec 2006 08:32:07 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kB5DVKiJ018024 for ; Tue, 5 Dec 2006 08:31:20 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kB5DVJ5U018021; Tue, 05 Dec 2006 08:31:20 -0500 (EST) Received: from [128.237.236.103] (vpn-10-25-4-19.remote.cert.org [10.25.4.19]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.66) with ESMTP id kB5DVJwe019145; Tue, 5 Dec 2006 08:31:19 -0500 In-Reply-To: <45747C2C.4010604@cisco.com> References: <3167F18F59B81B4888A4D4C0A1717DD6670F94@mhdexc02.adhel.hitachi-eu.com> <45747C2C.4010604@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Brian Trammell Date: Tue, 5 Dec 2006 08:30:26 -0500 To: Paul Aitken X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Elisa Boschi , Elisa Boschi , ipfix@ietf.org Subject: [IPFIX] Re: communicating timeouts X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org On Dec 4, 2006, at 2:51 PM, Paul Aitken wrote: > Dear all, > > Elisa wrote: > >> OK. But in the last sentence I'd prefer keeping "refresh timeout" >> instead of just "timeout": >> " The Common Property lifetime at the Collecting Process MUST be >> at least 3 times higher than the Common Property refresh timeout >> configured on the Exporting Process." > > There's a lot of talk about - and reliance on - timeouts in IPFIX. Only when using UDP. When using SCTP or TCP, the Transport Session termination performs the same function as the template/cpId timeouts. > But there's currently no way for exporters to communicate timeouts > to collectors in band; all communication must be done OOB (eg, by > an operator). Indeed. I don't actually see this as much of an impediment, though. Keep in mind this is only a consideration for UDP. In the UDP case, the CP and EP are almost certainly within the same administrative domain, with the same operator. OOB configuration is not quite so bad here because the operator will notice timeout errors in the log during deployment testing and adjust either the CP or EP timeout accordingly. Once such is done, it can be forgotten. A more advanced CP may certainly auto-adjust its expectation of the EP timeouts based on the observed retransmission delay. > It'd be really straightforward to send a template lifetime IE or > common properties ID lifetime IE in an option with the relevant > template ID or CP ID as scope. > > But it's not a very efficient method, since you'd have to repeat > this N times, once per template / CP ID - though we could export > using another IE that scopes a single lifetime to the system as a > whole, or to the transport session. Here you have a circular definition: The transport session for UDP (the only transport for which all this timeout stuff is relevant) is defined in terms of its template timeouts. So you can't set the timeout within a session for a session which is itself defined by the CP's previous estimation of session timeout; at least not with any solid expectation that such will work. However, exporting timeout information scoped to an EP identifier does not have the same issue. > I believe that Brian and Andrew have some ideas about this in the > upcoming managing scope draft. All the above having been said, yes. The managing scope draft, among other things, will propose validFrom and validUntil information elements, which can be scoped to templateIDs or cpIDs, and key the time to the Export Time field in the IPFIX Message header. Cheers, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 05 11:35:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrdEz-0000M8-J7; Tue, 05 Dec 2006 11:33:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrdEy-0000Lt-6T for ipfix@ietf.org; Tue, 05 Dec 2006 11:33:56 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrdEv-00042C-Jy for ipfix@ietf.org; Tue, 05 Dec 2006 11:33:56 -0500 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kB5GXkQq018836 for ; Tue, 5 Dec 2006 11:33:46 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kB5GW1GU018673 for ; Tue, 5 Dec 2006 11:32:01 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kB5GVxwc018669; Tue, 05 Dec 2006 11:32:01 -0500 (EST) Received: from [128.237.236.103] (vpn-10-25-4-13.remote.cert.org [10.25.4.13]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.66) with ESMTP id kB5GVxv9019478; Tue, 5 Dec 2006 11:31:59 -0500 In-Reply-To: <45756B12.8020109@cisco.com> References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <45756B12.8020109@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A5FB8CC-317C-40A9-A0B3-5E6E97BE370D@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Date: Tue, 5 Dec 2006 11:31:16 -0500 To: Benoit Claise X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: ipfix@ietf.org, Elisa Boschi X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Benoit and all, See inline, as always... On Dec 5, 2006, at 7:50 AM, Benoit Claise wrote: >> 7 para 7 OLD: >> >> If a Collecting Process receives a Common Properties Withdrawal >> message, the Collecting Process MUST delete the corresponding >> Common Properties associated with the specific SCTP association >> and specific Observation Domain, and stop decoding IPFIX Messages >> that use the withdrawn Templates. >> >> 7 para 7 NEW: >> >> If a Collecting Process receives a Common Properties Withdrawal >> message, the Collecting Process MUST delete the corresponding >> Common Properties associated with the specific SCTP association >> and specific Observation Domain. > I would like to add, "and stop decoding IPFIX Messages that use the > withdrawn Common Properties" > This would be in line with [IPFIX-PROTO] "The Collecting Process's > Side" section: > > If a Collecting Process receives a Template Withdraw Message, > the Collecting Process MUST delete the corresponding Template > Records associated with the specific SCTP association and > specific Observation Domain, and stop decoding IPFIX Messages > that use the withdrawn Templates. Hmmm.... I agree with the point, but I'm not sure this is the right language here. A CP would stop decoding Messages (actually, Sets) described by withdrawn Templates because Templates are necessary for decode. Common Properties are a bit higher in the stack - the Sets can be decoded, but some data would be missing for each record. How about something like: "and stop interpreting Data Records referring to those Common Properties. The receipt of Data Records referring to Common Properties that have been withdrawn MUST be ignored and SHOULD be logged by the Collecting Process." >> >> 7.1 para 3 OLD: >> >> The Collecting Process MUST NOT decode any further Data Records >> which >> are associated with the expired Common Properties. If a Common >> Property is refreshed with a Template Record that differs from the >> previous received Template Record, the Collecting Process >> SHOULD log >> a warning and replace the previous received Common Property >> with the >> new one. The Template lifetime at the Collecting Process MUST >> be at >> least 3 times higher than the Template refresh timeout >> configured on >> the Exporting Process. >> >> 7.1 para 3 NEW: >> >> The Collecting Process MUST NOT decode any further Data Records >> which >> are associated with the expired Common Properties. If a Common >> Property is refreshed with a definition that differs from the >> previous definition, the Collecting Process SHOULD log >> a warning and replace the previous received Common Property >> with the >> new one. The Common Property lifetime at the Collecting >> Process MUST be at >> least 3 times higher than the Common Property timeout >> configured on >> the Exporting Process. > In this case, you insert a new term "Common Property timeout". I > propose: > The Collecting Process MUST NOT decode any further Data Records > which > are associated with the expired Common Properties. If a Common > Property is refreshed with a definition that differs from the > previous definition, the Collecting Process SHOULD log > a warning and replace the previous received Common Property with the > new one. The Common Property lifetime at the Collecting Process > MUST be at > least 3 times higher than the refresh timeout of the Template > used to export the > Common Property definition, configured on the Exporting Process. (see previous message where this was clarified to "Common Property refresh timeout") An alternative would be to define the Common Property refresh timeout elsewhere in the document, and refer to it here, as we do with Template refresh in the protocol. Since the Common Property lifetime and the Template lifetime are both scoped to the Transport Session lifetime for connection-oriented transports, there may be no reason to presume that the Template refresh and Common Property refresh timeout should ever be different (indeed, things may break if they are; I've not thought it all the way through); however, I do think it is clearer if the Common Property refresh mechanism has its own terminology rather than tying it directly to the template timeout. Thoughts? Regards, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 05 11:35:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrdEz-0000M8-J7; Tue, 05 Dec 2006 11:33:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrdEy-0000Lt-6T for ipfix@ietf.org; Tue, 05 Dec 2006 11:33:56 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrdEv-00042C-Jy for ipfix@ietf.org; Tue, 05 Dec 2006 11:33:56 -0500 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kB5GXkQq018836 for ; Tue, 5 Dec 2006 11:33:46 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kB5GW1GU018673 for ; Tue, 5 Dec 2006 11:32:01 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kB5GVxwc018669; Tue, 05 Dec 2006 11:32:01 -0500 (EST) Received: from [128.237.236.103] (vpn-10-25-4-13.remote.cert.org [10.25.4.13]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.66) with ESMTP id kB5GVxv9019478; Tue, 5 Dec 2006 11:31:59 -0500 In-Reply-To: <45756B12.8020109@cisco.com> References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <45756B12.8020109@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A5FB8CC-317C-40A9-A0B3-5E6E97BE370D@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Date: Tue, 5 Dec 2006 11:31:16 -0500 To: Benoit Claise X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: ipfix@ietf.org, Elisa Boschi X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Benoit and all, See inline, as always... On Dec 5, 2006, at 7:50 AM, Benoit Claise wrote: >> 7 para 7 OLD: >> >> If a Collecting Process receives a Common Properties Withdrawal >> message, the Collecting Process MUST delete the corresponding >> Common Properties associated with the specific SCTP association >> and specific Observation Domain, and stop decoding IPFIX Messages >> that use the withdrawn Templates. >> >> 7 para 7 NEW: >> >> If a Collecting Process receives a Common Properties Withdrawal >> message, the Collecting Process MUST delete the corresponding >> Common Properties associated with the specific SCTP association >> and specific Observation Domain. > I would like to add, "and stop decoding IPFIX Messages that use the > withdrawn Common Properties" > This would be in line with [IPFIX-PROTO] "The Collecting Process's > Side" section: > > If a Collecting Process receives a Template Withdraw Message, > the Collecting Process MUST delete the corresponding Template > Records associated with the specific SCTP association and > specific Observation Domain, and stop decoding IPFIX Messages > that use the withdrawn Templates. Hmmm.... I agree with the point, but I'm not sure this is the right language here. A CP would stop decoding Messages (actually, Sets) described by withdrawn Templates because Templates are necessary for decode. Common Properties are a bit higher in the stack - the Sets can be decoded, but some data would be missing for each record. How about something like: "and stop interpreting Data Records referring to those Common Properties. The receipt of Data Records referring to Common Properties that have been withdrawn MUST be ignored and SHOULD be logged by the Collecting Process." >> >> 7.1 para 3 OLD: >> >> The Collecting Process MUST NOT decode any further Data Records >> which >> are associated with the expired Common Properties. If a Common >> Property is refreshed with a Template Record that differs from the >> previous received Template Record, the Collecting Process >> SHOULD log >> a warning and replace the previous received Common Property >> with the >> new one. The Template lifetime at the Collecting Process MUST >> be at >> least 3 times higher than the Template refresh timeout >> configured on >> the Exporting Process. >> >> 7.1 para 3 NEW: >> >> The Collecting Process MUST NOT decode any further Data Records >> which >> are associated with the expired Common Properties. If a Common >> Property is refreshed with a definition that differs from the >> previous definition, the Collecting Process SHOULD log >> a warning and replace the previous received Common Property >> with the >> new one. The Common Property lifetime at the Collecting >> Process MUST be at >> least 3 times higher than the Common Property timeout >> configured on >> the Exporting Process. > In this case, you insert a new term "Common Property timeout". I > propose: > The Collecting Process MUST NOT decode any further Data Records > which > are associated with the expired Common Properties. If a Common > Property is refreshed with a definition that differs from the > previous definition, the Collecting Process SHOULD log > a warning and replace the previous received Common Property with the > new one. The Common Property lifetime at the Collecting Process > MUST be at > least 3 times higher than the refresh timeout of the Template > used to export the > Common Property definition, configured on the Exporting Process. (see previous message where this was clarified to "Common Property refresh timeout") An alternative would be to define the Common Property refresh timeout elsewhere in the document, and refer to it here, as we do with Template refresh in the protocol. Since the Common Property lifetime and the Template lifetime are both scoped to the Transport Session lifetime for connection-oriented transports, there may be no reason to presume that the Template refresh and Common Property refresh timeout should ever be different (indeed, things may break if they are; I've not thought it all the way through); however, I do think it is clearer if the Common Property refresh mechanism has its own terminology rather than tying it directly to the template timeout. Thoughts? Regards, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 05 12:33:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gre9Z-0001iD-HJ; Tue, 05 Dec 2006 12:32:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gre9X-0001i4-SM for ipfix@ietf.org; Tue, 05 Dec 2006 12:32:23 -0500 Received: from gatekeeper.hitachi-eu.com ([194.36.128.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gre9S-0005Ar-Dz for ipfix@ietf.org; Tue, 05 Dec 2006 12:32:23 -0500 X-ASG-Debug-ID: 1165339937-5cf100530000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: primary.hitachi-eu.net[193.39.225.234] X-Barracuda-Start-Time: 1165339937 X-ASG-Whitelist: Client Received: from mhd-esafe-int.hitachi-eu.com (primary.hitachi-eu.net [193.39.225.234]) by gatekeeper.hitachi-eu.com (Spam Firewall) with SMTP id 8AB4545A1F for ; Tue, 5 Dec 2006 17:32:17 +0000 (GMT) Received: from MHDEXC99.adhel.hitachi-eu.com ([IP=193.39.227.52]) by eSafe SMTP Relay 1165163447; Tue Dec 5 17:32:17 2006 Received: from mhdexc02.adhel.hitachi-eu.com ([193.39.227.51]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 17:32:16 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Reference to PSAMP in draft-ietf-ipfix-reducing-redundancy-01.txt Date: Tue, 5 Dec 2006 17:32:15 -0000 Message-ID: <3167F18F59B81B4888A4D4C0A1717DD6670F96@mhdexc02.adhel.hitachi-eu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reference to PSAMP in draft-ietf-ipfix-reducing-redundancy-01.txt Thread-Index: AccYk05hldDKoddMTOa5dNaVFymvqw== From: "Boschi, Elisa" To: X-OriginalArrivalTime: 05 Dec 2006 17:32:16.0415 (UTC) FILETIME=[4EC522F0:01C71893] X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: ipfix@ietf.org Subject: [IPFIX] Reference to PSAMP in draft-ietf-ipfix-reducing-redundancy-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1614162956==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1614162956== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71893.4E705C95" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71893.4E705C95 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andrew, all, > > If there are references to PSAMP drafts, doesn't that > block this from becoming an RFC until the PSAMP ones > are RFCs? Do we have to mention PSAMP so much anyway, > as it's just a specialised use case of IPFIX? Only the PSAMP protocol blocks this document. I think that the reference = to PSAMP is important and should be kept, since it is one of the most imp= ortant applications for the reducing redundancy technique (the draft was = initially targeted to PSAMP...). Any other opinions on this matter? Regards, Elisa *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* ------_=_NextPart_001_01C71893.4E705C95 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reference to PSAMP in draft-ietf-ipfix-reducing-redundancy-01.txt<= /TITLE> </HEAD> <BODY> <!-- Converted from text/plain format --> <P><FONT SIZE=3D2>Andrew, all,<BR> <BR> ><BR> > If there are references to PSAMP drafts, doesn't that<BR> > block this from becoming an RFC until the PSAMP ones<BR> > are RFCs?  Do we have to mention PSAMP so much anyway,<BR> > as it's just a specialised use case of IPFIX?<BR> <BR> <BR> Only the PSAMP protocol blocks this document. I think that the reference = to PSAMP is important and should be kept, since it is one of the most imp= ortant applications for the reducing redundancy technique (the draft was = initially targeted to PSAMP...).<BR> <BR> Any other opinions on this matter?<BR> <BR> Regards,<BR> Elisa<BR> <BR> </FONT> </P> <FONT SIZE=3D3 COLOR=3DBLUE><PRE> *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* </PRE></FONT> </BODY> </HTML> ------_=_NextPart_001_01C71893.4E705C95-- --===============1614162956== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1614162956==-- From ipfix-bounces@ietf.org Tue Dec 05 12:33:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gre9Z-0001iD-HJ; Tue, 05 Dec 2006 12:32:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gre9X-0001i4-SM for ipfix@ietf.org; Tue, 05 Dec 2006 12:32:23 -0500 Received: from gatekeeper.hitachi-eu.com ([194.36.128.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gre9S-0005Ar-Dz for ipfix@ietf.org; Tue, 05 Dec 2006 12:32:23 -0500 X-ASG-Debug-ID: 1165339937-5cf100530000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: primary.hitachi-eu.net[193.39.225.234] X-Barracuda-Start-Time: 1165339937 X-ASG-Whitelist: Client Received: from mhd-esafe-int.hitachi-eu.com (primary.hitachi-eu.net [193.39.225.234]) by gatekeeper.hitachi-eu.com (Spam Firewall) with SMTP id 8AB4545A1F for <ipfix@ietf.org>; Tue, 5 Dec 2006 17:32:17 +0000 (GMT) Received: from MHDEXC99.adhel.hitachi-eu.com ([IP=193.39.227.52]) by eSafe SMTP Relay 1165163447; Tue Dec 5 17:32:17 2006 Received: from mhdexc02.adhel.hitachi-eu.com ([193.39.227.51]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 17:32:16 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Reference to PSAMP in draft-ietf-ipfix-reducing-redundancy-01.txt Date: Tue, 5 Dec 2006 17:32:15 -0000 Message-ID: <3167F18F59B81B4888A4D4C0A1717DD6670F96@mhdexc02.adhel.hitachi-eu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reference to PSAMP in draft-ietf-ipfix-reducing-redundancy-01.txt Thread-Index: AccYk05hldDKoddMTOa5dNaVFymvqw== From: "Boschi, Elisa" <Elisa.Boschi@Hitachi-eu.com> To: <andrjohn@cisco.com> X-OriginalArrivalTime: 05 Dec 2006 17:32:16.0415 (UTC) FILETIME=[4EC522F0:01C71893] X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: ipfix@ietf.org Subject: [IPFIX] Reference to PSAMP in draft-ietf-ipfix-reducing-redundancy-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list <ipfix.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ipfix> List-Post: <mailto:ipfix@ietf.org> List-Help: <mailto:ipfix-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1614162956==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1614162956== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71893.4E705C95" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71893.4E705C95 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andrew, all, > > If there are references to PSAMP drafts, doesn't that > block this from becoming an RFC until the PSAMP ones > are RFCs? Do we have to mention PSAMP so much anyway, > as it's just a specialised use case of IPFIX? Only the PSAMP protocol blocks this document. I think that the reference = to PSAMP is important and should be kept, since it is one of the most imp= ortant applications for the reducing redundancy technique (the draft was = initially targeted to PSAMP...). Any other opinions on this matter? Regards, Elisa *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* ------_=_NextPart_001_01C71893.4E705C95 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-885= 9-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7233.6= 9"> <TITLE>Reference to PSAMP in draft-ietf-ipfix-reducing-redundancy-01.txt<= /TITLE> </HEAD> <BODY> <!-- Converted from text/plain format --> <P><FONT SIZE=3D2>Andrew, all,<BR> <BR> ><BR> > If there are references to PSAMP drafts, doesn't that<BR> > block this from becoming an RFC until the PSAMP ones<BR> > are RFCs?  Do we have to mention PSAMP so much anyway,<BR> > as it's just a specialised use case of IPFIX?<BR> <BR> <BR> Only the PSAMP protocol blocks this document. I think that the reference = to PSAMP is important and should be kept, since it is one of the most imp= ortant applications for the reducing redundancy technique (the draft was = initially targeted to PSAMP...).<BR> <BR> Any other opinions on this matter?<BR> <BR> Regards,<BR> Elisa<BR> <BR> </FONT> </P> <FONT SIZE=3D3 COLOR=3DBLUE><PRE> *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* </PRE></FONT> </BODY> </HTML> ------_=_NextPart_001_01C71893.4E705C95-- --===============1614162956== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1614162956==-- From ipfix-bounces@ietf.org Tue Dec 05 17:30:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grimt-00051c-P6; Tue, 05 Dec 2006 17:29:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grims-00051W-KS for ipfix@ietf.org; Tue, 05 Dec 2006 17:29:18 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grimm-0007hE-Dj for ipfix@ietf.org; Tue, 05 Dec 2006 17:29:18 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB5MTBf04102; Tue, 5 Dec 2006 23:29:11 +0100 (CET) Received: from [10.61.65.5] (ams3-vpn-dhcp261.cisco.com [10.61.65.5]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB5MT8W14954; Tue, 5 Dec 2006 23:29:08 +0100 (CET) Message-ID: <4575F2B4.4030806@cisco.com> Date: Tue, 05 Dec 2006 23:29:08 +0100 From: Benoit Claise <bclaise@cisco.com> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Andrew Johnson <andrjohn@cisco.com> Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> In-Reply-To: <455E6A11.2080209@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-bru.cisco.com id kB5MTBf04102 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list <ipfix.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ipfix> List-Post: <mailto:ipfix@ietf.org> List-Help: <mailto:ipfix-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe> Errors-To: ipfix-bounces@ietf.org Hi Andrew, > > > If there are references to PSAMP drafts, doesn't that > block this from becoming an RFC until the PSAMP ones > are RFCs?=20 Sure. > Do we have to mention PSAMP so much anyway, > as it's just a specialised use case of IPFIX? Right, I think that the previous version was somehow lacking some=20 information. Yes we can use this mechanism for all sort of flows, even for: "So the PSAMP export can be seen as special IPFIX Flow Record containing=20 information about a single packet." dixit PSAMP-PROTO However, by having the clear distinctions... 3.1 Per Flow Data Reduction...............................11 =20 3.1.1 Unique Data Reduction..................................11 =20 3.1.2 Multiple Data Reduction................................12 =20 3.2 Per Packet Data Reduction.............................13 ... I believe that we gained in clarity... Maybe not for you, as you=20 know enough about IPFIX and PSAMP to understand how to apply this=20 techniques, but for the rest of the community. > > Since a flow is defined as a group of packets that share > a set of common properties, i.e. key fields, is there > any danger that the commonPropertiesID will be wrongly > assumed to refer to only the complete set of key fields? By definition, I think this is impossible. The flow key definition says=20 "Each of the fields which are used to define a Flow are termed Flow=20 Keys.". So there is nothing in common between flows. However, I=20 understand your concern for novice readers. OLD section 1 "Introduction" Regardless of the fields content, flow records with common =20 properties export the same fields in every single flow record. =20 These common properties may represent values common to a collection = =20 of flows or packets, or values that are invariant over time. The =20 reduction of redundant data from the export stream can result in a =20 significant reduction of the transferred data. NEW section 1 "Introduction" Regardless of the fields content, flow records with common =20 properties export the same fields in every single flow record. =20 These common properties may represent values common to a collection =20 of flows or packets, or values that are invariant over time. Note =20 that the common properties don't represent the list of flow keys, which= =20 are used to define a flow definition: however, the common properties =20 may contain some of the flow keys. The reduction of redundant data from= =20 the export stream can result in a significant reduction of the =20 transferred data. > > Is there any need to define a new term for "Specific > Properties"? These are just part of a normal Data Record. > For example: > "... The rows are then referenced by the Specific Properties > by using the appropriate value for the Common Properties > identifier." > > could simply be: > "... The rows are then referenced by Data Records by > using the appropriate value for the Common Properties > identifier." In your example, the "Data Records" doesn't mean the full data records=20 before applying the redundancy reduction mechanism but only a part of it. So it might be confusing... That's the trick we found. However, I could agree that the draft would work without a formal (upper=20 case) definition.... So do you have the same idea for the Common Properti= es? > > Are option withdrawal messages part of IPFIX? Yes. IPFIX says: "The Set ID field MUST contain the value 2 for Template=20 Set withdrawal and the value 3 for Options Template Set withdrawal." Unless you want to say an option data record withdrawal message? Note: I discovered that the draft still contains: "Option Data Record" This term has been removed from IPFIX-PROTO. So it should be removed in=20 this draft. > Are they meaningful in IPFIX? i.e. per the PROTO will an option > with scope but no data be deemed invalidated by the Collector. > Scope without data is the same as never having recieved the > mapping in the first place. I think that it would be up to the > implementation but it seems like a good idea so if we can't add > it to the PROTO can we put it in the implementation guidelines? > > How do you propose to withdraw common properties when they are > associated with a template rather than the Common Properties index? I don't ;) This is the reason why the use the Common Properties index is=20 a cleaner design. > > > General Comments > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I think, sections 3.1.2, 8.2 and 8.3 would be better grouped > into a 3.2 Advanced Techniques section. > > I think 3.2 Per Packet Data Reduction, should be removed and > any information that is not in section 3.1 should be added to > to the PSAMP example. > I think the the per-packet example is a good example of > per flow reducing redundancy and section 11.1.1 can be removed. See one of my previous remark about: 3.1 Per Flow Data Reduction...............................11 =20 3.1.1 Unique Data Reduction..................................11 =20 3.1.2 Multiple Data Reduction................................12 =20 3.2 Per Packet Data Reduction.............................13 Again, it's because you know the boundary between IPFIX and PSAMP > > Labels for the figures would be better if they were centred. Agreed. > > There is all sorts of extra spacing at the end of the lines. > > > > Specific Comments > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 2. Terminology > Tabbing is inconsistent in definition of "Selector": > (i) the Packet Content; (ii) information derived from the packet's=20 > treatment at the Observation Point; (iii) any selection state that may=20 > be maintained by the Selection Process. > > 3.1.2 Multiple Data Reduction > > I don't think this section is explained very well. From my original > email to Elisa and Lutz (18th Nov 2005): > Andrew Johnson wrote: >> Flows >> =3D=3D=3D=3D=3D >> Flow A: flowId 1, flowId 11, 30 packets, 6000 bytes >> Flow B: flowID 1, flowId 12, 50 packets, 9500 bytes >> Flow C: flowId 2, flowId 11, 60 packets, 8000 bytes >> Flow D: flowID 2, flowId 12, 10 packets, 1500 bytes >> >> Options >> =3D=3D=3D=3D=3D=3D=3D >> flowId 1 - destinationIpv4address 10.0.0.1, destinationTcpPort 80 >> flowId 1 - destinationIpv4address 10.0.0.5, destinationTcpPort 80 >> >> flowId 11 - sourceIpv4address 10.0.1.10, sourceTcpPort 1932 >> flowId 12 - sourceIpv4address 10.0.1.15, sourceTcpPort 1842 > > > This shows how 4 (2+2) options can be expanded to 4 combinations of > Data Record to reduce redundancy without the need to define 4 complete > sets of Common Properties and therefore not save any bandwidth. The > more options you have the better this works. 20 options (10+10) would > give you up to 100 possible pairs common properties. > > This isn't really made clear in the draft text, with only "flow1" > having two indices. I agree the examples in figure 4/5 don't show this. Maybe a new section in section 8 "Export and Evaluation Considerations"? > The example in 11.1.2 doesn't even have any! Agreed. This should be corrected. > > While I agree that using a template that doesn't include the cpID > is a good idea to efficiently communicate flows with not so common > properties, however I would call this an "Advanced Technique" to be > listed in the section I proposed earlier. > > > 3.2 Per Packet Data Reduction > > The text reads: > If filtering is applied to select a series of packets, using the PSAMP=20 > specifications to export per-packet information might be relatively=20 > inefficient if the filtered fields (the common attributes) are=20 > exported in every single record. > > However in section 6.5.2.5 (Property Match Filtering) of PSAMP-PROTO > it is explained how the filter information MUST be sent. This is > designed so that the selector ID will match the one from the Data > Record (via the selectionSequenceId) and perform exactly the function > that is being proposed here for the commonPropertiesId. Good point. I would remove this paragraph and move to this place the one=20 starting with: An example of the per packet data reduction is the measurement of =20 One-Way Delay (OWD), where the exact same specific packet must be =20 observed at the source and destination of the path to be measured. =20 By subtracting ... > > > 4. Specifications for bandwidth saving information export > > What is being specified here that isn't true for ALL options as > described in IPFIX-PROTO? What do you suggest? > > I think section 3 does a better job of explaining how all this > works. I'm really not sure what section 4 adds. The idea was to put the specs in section 4 while the section 3 was the=20 high level solution. > (Aside: figure 9 refers to Common Sroperties). Yep. thanks. > > > 6. commonPropertiesID Management > > The text reads: > The commonPropertiesID values MAY be assigned sequentially, but it=EF=BF= =BDs > It seems the "it's" is using an invalid character rather than an > apostrophe. > > > 7. The Collecting Process Side > > The text reads: > Like TemplateIDs the commonPropertiesIDs are generated dynamically by=20 > the Exporting Process. Hence a restart of the Exporting Process may=20 > imply a renumbering of commonProperiesIDs. > The collector can't know if the Exporter Process restarted, this is > why we rescoped the commonPropertiesID to the Transport Session, so > the above text is now redundant. I know it's redundant, but don't you think it helps. For example, we=20 don't explain anywhere (if I recall correctly) that "the=20 commonPropertiesIDs are generated dynamically by the Exporting Process" > > > The text reads: > Common Properties IDs are unique per SCTP association and per=20 > Observation Domain. If the Collecting Process receives a common=20 > Properties ID which has already been received but which has not=20 > previously been withdrawn (i.e. a commonPropertiesID from the same=20 > Exporter Observation Domain with the same Template ID received on the=20 > SCTP association), then the Collecting Process MUST shutdown the=20 > association. This is similar to [IPFIX-PROTO] Template IDs are unique per SCTP association and per Observation =20 Domain. If the Collecting Process receives a Template which has =20 already been received but which has not previously been withdrawn =20 (i.e. a Template Record from the same Exporter Observation Domain =20 with the same Template ID received on the SCTP association), then=20 the Collecting Process MUST shutdown the association. > > and: > If the Collecting Process receives a Common Properties Withdrawal=20 > message for a Common Properties that it has not received before on=20 > this SCTP assocation, it MUST reset the SCTP association, discard the=20 > IPFIX Message, and SHOULD log the error as it does for malformed IPFIX=20 > Messages. > I think this might go against IPFIX-PROTO. This is similar to [IPFIX-PROTO] If the Collecting Process receives a Template Withdraw message for a =20 Template Record it has not received before on this SCTP assocation, =20 it MUST reset the SCTP association, discard the IPFIX Message, and =20 SHOULD log the error as it does for malformed IPFIX Messages. > > > The text reads: > If the Common Properties are not refreshed before that lifetime has=20 > expired, the Collecting Process MUST discard the corresponding=20 > definition of the commonPropertiesID and any current and future=20 > associated Data Records. In which case, an alarm MUST be logged. > What happened to storing it until the option turned up. Furthermore > you shouldn't dictate the the record is discarded, just because you > can't tell a piece of potentially trivial information about a flow > doesn't mean it's meaningless. The Common Properties in question > could be anything. This is similar to [IPFIX-PROTO] If the Template (or other definition) is not refreshed before that=20 lifetime has =20 expired, the Collecting Process MUST discard that definition and any =20 current and future associated Data Records. In which case, an alarm =20 MUST be logged.=20 > > Besides, we're not changing the protocol here, right? Right. So this is not an IPFIX redundancy reduction issue but an IPFIX=20 protocol issue... as we don't want to change the protocol with this draft. > > > 8.1 Transport Protocol Choice The text reads: > The proposed method is most effective using a reliable transport=20 > protocol for the transfer of the Common Properties. Therefore the use=20 > of SCTP or TCP is recommended. > > Note that SCTP isn't necessarily reliable. SCTP -> PR-SCTP with the reliable mode > > > 8.3 commonPropertiesID vs. TemplateID scope > Additional flow properties can be tied to almost any I.E. For example > a particular interface could be associated with the one IP address it > serves. That's true but I still think the design is cleaner with the Common=20 Properties Id. See the remark about the Common Properties ID withdrawal > > > 8.4 Efficiency Gain > The text reads: > "...it can=EF=BF=BDt predict whether future..." > > Weird apostrophe character again. > > > > Examples: > > 1. There is no padding between records, it's against IPFIX-PROTO, > unless you use the special padding I.E. > 2. The templates define the counts as 4 octets but the records show > them as 2. > 3. Since 11.1.1 and 11.2 don't demonstrate anything different, can > we have just one example? > 4. The tabbing is sometimes a little of on the run though of the I.E.s, > and I think we can loose the commas. e.g. > > OLD > - the source IPv4 Address, sourceIPv4Address [IPFIX-INFO], with a type=20 > of 8 and a length of 4 octets > NEW > - the source IPv4 Address: sourceIPv4Address [IPFIX-INFO] with a type=20 > of 8 and a length of 4 octets > > > 5. What is a packet ID anyway? In general PSAMP uses sampling to gather > detailed information about a small proportion of the network traffic. > In most cases there won't be many common factors between the reports. > The real exception is hash-based filtering, which is what I think the > example uses. > > > 6. Do we have to use enterprise specific things here? What about: > observationTimeMilliseconds (323), > digestHashValue (326), > ipTotalLength (224) > Regards, Benoit. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 05 17:30:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grimt-00051c-P6; Tue, 05 Dec 2006 17:29:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grims-00051W-KS for ipfix@ietf.org; Tue, 05 Dec 2006 17:29:18 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grimm-0007hE-Dj for ipfix@ietf.org; Tue, 05 Dec 2006 17:29:18 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB5MTBf04102; Tue, 5 Dec 2006 23:29:11 +0100 (CET) Received: from [10.61.65.5] (ams3-vpn-dhcp261.cisco.com [10.61.65.5]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB5MT8W14954; Tue, 5 Dec 2006 23:29:08 +0100 (CET) Message-ID: <4575F2B4.4030806@cisco.com> Date: Tue, 05 Dec 2006 23:29:08 +0100 From: Benoit Claise <bclaise@cisco.com> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Andrew Johnson <andrjohn@cisco.com> Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> In-Reply-To: <455E6A11.2080209@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-bru.cisco.com id kB5MTBf04102 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list <ipfix.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ipfix> List-Post: <mailto:ipfix@ietf.org> List-Help: <mailto:ipfix-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe> Errors-To: ipfix-bounces@ietf.org Hi Andrew, > > > If there are references to PSAMP drafts, doesn't that > block this from becoming an RFC until the PSAMP ones > are RFCs?=20 Sure. > Do we have to mention PSAMP so much anyway, > as it's just a specialised use case of IPFIX? Right, I think that the previous version was somehow lacking some=20 information. Yes we can use this mechanism for all sort of flows, even for: "So the PSAMP export can be seen as special IPFIX Flow Record containing=20 information about a single packet." dixit PSAMP-PROTO However, by having the clear distinctions... 3.1 Per Flow Data Reduction...............................11 =20 3.1.1 Unique Data Reduction..................................11 =20 3.1.2 Multiple Data Reduction................................12 =20 3.2 Per Packet Data Reduction.............................13 ... I believe that we gained in clarity... Maybe not for you, as you=20 know enough about IPFIX and PSAMP to understand how to apply this=20 techniques, but for the rest of the community. > > Since a flow is defined as a group of packets that share > a set of common properties, i.e. key fields, is there > any danger that the commonPropertiesID will be wrongly > assumed to refer to only the complete set of key fields? By definition, I think this is impossible. The flow key definition says=20 "Each of the fields which are used to define a Flow are termed Flow=20 Keys.". So there is nothing in common between flows. However, I=20 understand your concern for novice readers. OLD section 1 "Introduction" Regardless of the fields content, flow records with common =20 properties export the same fields in every single flow record. =20 These common properties may represent values common to a collection = =20 of flows or packets, or values that are invariant over time. The =20 reduction of redundant data from the export stream can result in a =20 significant reduction of the transferred data. NEW section 1 "Introduction" Regardless of the fields content, flow records with common =20 properties export the same fields in every single flow record. =20 These common properties may represent values common to a collection =20 of flows or packets, or values that are invariant over time. Note =20 that the common properties don't represent the list of flow keys, which= =20 are used to define a flow definition: however, the common properties =20 may contain some of the flow keys. The reduction of redundant data from= =20 the export stream can result in a significant reduction of the =20 transferred data. > > Is there any need to define a new term for "Specific > Properties"? These are just part of a normal Data Record. > For example: > "... The rows are then referenced by the Specific Properties > by using the appropriate value for the Common Properties > identifier." > > could simply be: > "... The rows are then referenced by Data Records by > using the appropriate value for the Common Properties > identifier." In your example, the "Data Records" doesn't mean the full data records=20 before applying the redundancy reduction mechanism but only a part of it. So it might be confusing... That's the trick we found. However, I could agree that the draft would work without a formal (upper=20 case) definition.... So do you have the same idea for the Common Properti= es? > > Are option withdrawal messages part of IPFIX? Yes. IPFIX says: "The Set ID field MUST contain the value 2 for Template=20 Set withdrawal and the value 3 for Options Template Set withdrawal." Unless you want to say an option data record withdrawal message? Note: I discovered that the draft still contains: "Option Data Record" This term has been removed from IPFIX-PROTO. So it should be removed in=20 this draft. > Are they meaningful in IPFIX? i.e. per the PROTO will an option > with scope but no data be deemed invalidated by the Collector. > Scope without data is the same as never having recieved the > mapping in the first place. I think that it would be up to the > implementation but it seems like a good idea so if we can't add > it to the PROTO can we put it in the implementation guidelines? > > How do you propose to withdraw common properties when they are > associated with a template rather than the Common Properties index? I don't ;) This is the reason why the use the Common Properties index is=20 a cleaner design. > > > General Comments > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I think, sections 3.1.2, 8.2 and 8.3 would be better grouped > into a 3.2 Advanced Techniques section. > > I think 3.2 Per Packet Data Reduction, should be removed and > any information that is not in section 3.1 should be added to > to the PSAMP example. > I think the the per-packet example is a good example of > per flow reducing redundancy and section 11.1.1 can be removed. See one of my previous remark about: 3.1 Per Flow Data Reduction...............................11 =20 3.1.1 Unique Data Reduction..................................11 =20 3.1.2 Multiple Data Reduction................................12 =20 3.2 Per Packet Data Reduction.............................13 Again, it's because you know the boundary between IPFIX and PSAMP > > Labels for the figures would be better if they were centred. Agreed. > > There is all sorts of extra spacing at the end of the lines. > > > > Specific Comments > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 2. Terminology > Tabbing is inconsistent in definition of "Selector": > (i) the Packet Content; (ii) information derived from the packet's=20 > treatment at the Observation Point; (iii) any selection state that may=20 > be maintained by the Selection Process. > > 3.1.2 Multiple Data Reduction > > I don't think this section is explained very well. From my original > email to Elisa and Lutz (18th Nov 2005): > Andrew Johnson wrote: >> Flows >> =3D=3D=3D=3D=3D >> Flow A: flowId 1, flowId 11, 30 packets, 6000 bytes >> Flow B: flowID 1, flowId 12, 50 packets, 9500 bytes >> Flow C: flowId 2, flowId 11, 60 packets, 8000 bytes >> Flow D: flowID 2, flowId 12, 10 packets, 1500 bytes >> >> Options >> =3D=3D=3D=3D=3D=3D=3D >> flowId 1 - destinationIpv4address 10.0.0.1, destinationTcpPort 80 >> flowId 1 - destinationIpv4address 10.0.0.5, destinationTcpPort 80 >> >> flowId 11 - sourceIpv4address 10.0.1.10, sourceTcpPort 1932 >> flowId 12 - sourceIpv4address 10.0.1.15, sourceTcpPort 1842 > > > This shows how 4 (2+2) options can be expanded to 4 combinations of > Data Record to reduce redundancy without the need to define 4 complete > sets of Common Properties and therefore not save any bandwidth. The > more options you have the better this works. 20 options (10+10) would > give you up to 100 possible pairs common properties. > > This isn't really made clear in the draft text, with only "flow1" > having two indices. I agree the examples in figure 4/5 don't show this. Maybe a new section in section 8 "Export and Evaluation Considerations"? > The example in 11.1.2 doesn't even have any! Agreed. This should be corrected. > > While I agree that using a template that doesn't include the cpID > is a good idea to efficiently communicate flows with not so common > properties, however I would call this an "Advanced Technique" to be > listed in the section I proposed earlier. > > > 3.2 Per Packet Data Reduction > > The text reads: > If filtering is applied to select a series of packets, using the PSAMP=20 > specifications to export per-packet information might be relatively=20 > inefficient if the filtered fields (the common attributes) are=20 > exported in every single record. > > However in section 6.5.2.5 (Property Match Filtering) of PSAMP-PROTO > it is explained how the filter information MUST be sent. This is > designed so that the selector ID will match the one from the Data > Record (via the selectionSequenceId) and perform exactly the function > that is being proposed here for the commonPropertiesId. Good point. I would remove this paragraph and move to this place the one=20 starting with: An example of the per packet data reduction is the measurement of =20 One-Way Delay (OWD), where the exact same specific packet must be =20 observed at the source and destination of the path to be measured. =20 By subtracting ... > > > 4. Specifications for bandwidth saving information export > > What is being specified here that isn't true for ALL options as > described in IPFIX-PROTO? What do you suggest? > > I think section 3 does a better job of explaining how all this > works. I'm really not sure what section 4 adds. The idea was to put the specs in section 4 while the section 3 was the=20 high level solution. > (Aside: figure 9 refers to Common Sroperties). Yep. thanks. > > > 6. commonPropertiesID Management > > The text reads: > The commonPropertiesID values MAY be assigned sequentially, but it=EF=BF= =BDs > It seems the "it's" is using an invalid character rather than an > apostrophe. > > > 7. The Collecting Process Side > > The text reads: > Like TemplateIDs the commonPropertiesIDs are generated dynamically by=20 > the Exporting Process. Hence a restart of the Exporting Process may=20 > imply a renumbering of commonProperiesIDs. > The collector can't know if the Exporter Process restarted, this is > why we rescoped the commonPropertiesID to the Transport Session, so > the above text is now redundant. I know it's redundant, but don't you think it helps. For example, we=20 don't explain anywhere (if I recall correctly) that "the=20 commonPropertiesIDs are generated dynamically by the Exporting Process" > > > The text reads: > Common Properties IDs are unique per SCTP association and per=20 > Observation Domain. If the Collecting Process receives a common=20 > Properties ID which has already been received but which has not=20 > previously been withdrawn (i.e. a commonPropertiesID from the same=20 > Exporter Observation Domain with the same Template ID received on the=20 > SCTP association), then the Collecting Process MUST shutdown the=20 > association. This is similar to [IPFIX-PROTO] Template IDs are unique per SCTP association and per Observation =20 Domain. If the Collecting Process receives a Template which has =20 already been received but which has not previously been withdrawn =20 (i.e. a Template Record from the same Exporter Observation Domain =20 with the same Template ID received on the SCTP association), then=20 the Collecting Process MUST shutdown the association. > > and: > If the Collecting Process receives a Common Properties Withdrawal=20 > message for a Common Properties that it has not received before on=20 > this SCTP assocation, it MUST reset the SCTP association, discard the=20 > IPFIX Message, and SHOULD log the error as it does for malformed IPFIX=20 > Messages. > I think this might go against IPFIX-PROTO. This is similar to [IPFIX-PROTO] If the Collecting Process receives a Template Withdraw message for a =20 Template Record it has not received before on this SCTP assocation, =20 it MUST reset the SCTP association, discard the IPFIX Message, and =20 SHOULD log the error as it does for malformed IPFIX Messages. > > > The text reads: > If the Common Properties are not refreshed before that lifetime has=20 > expired, the Collecting Process MUST discard the corresponding=20 > definition of the commonPropertiesID and any current and future=20 > associated Data Records. In which case, an alarm MUST be logged. > What happened to storing it until the option turned up. Furthermore > you shouldn't dictate the the record is discarded, just because you > can't tell a piece of potentially trivial information about a flow > doesn't mean it's meaningless. The Common Properties in question > could be anything. This is similar to [IPFIX-PROTO] If the Template (or other definition) is not refreshed before that=20 lifetime has =20 expired, the Collecting Process MUST discard that definition and any =20 current and future associated Data Records. In which case, an alarm =20 MUST be logged.=20 > > Besides, we're not changing the protocol here, right? Right. So this is not an IPFIX redundancy reduction issue but an IPFIX=20 protocol issue... as we don't want to change the protocol with this draft. > > > 8.1 Transport Protocol Choice The text reads: > The proposed method is most effective using a reliable transport=20 > protocol for the transfer of the Common Properties. Therefore the use=20 > of SCTP or TCP is recommended. > > Note that SCTP isn't necessarily reliable. SCTP -> PR-SCTP with the reliable mode > > > 8.3 commonPropertiesID vs. TemplateID scope > Additional flow properties can be tied to almost any I.E. For example > a particular interface could be associated with the one IP address it > serves. That's true but I still think the design is cleaner with the Common=20 Properties Id. See the remark about the Common Properties ID withdrawal > > > 8.4 Efficiency Gain > The text reads: > "...it can=EF=BF=BDt predict whether future..." > > Weird apostrophe character again. > > > > Examples: > > 1. There is no padding between records, it's against IPFIX-PROTO, > unless you use the special padding I.E. > 2. The templates define the counts as 4 octets but the records show > them as 2. > 3. Since 11.1.1 and 11.2 don't demonstrate anything different, can > we have just one example? > 4. The tabbing is sometimes a little of on the run though of the I.E.s, > and I think we can loose the commas. e.g. > > OLD > - the source IPv4 Address, sourceIPv4Address [IPFIX-INFO], with a type=20 > of 8 and a length of 4 octets > NEW > - the source IPv4 Address: sourceIPv4Address [IPFIX-INFO] with a type=20 > of 8 and a length of 4 octets > > > 5. What is a packet ID anyway? In general PSAMP uses sampling to gather > detailed information about a small proportion of the network traffic. > In most cases there won't be many common factors between the reports. > The real exception is hash-based filtering, which is what I think the > example uses. > > > 6. Do we have to use enterprise specific things here? What about: > observationTimeMilliseconds (323), > digestHashValue (326), > ipTotalLength (224) > Regards, Benoit. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 05 19:22:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrkWf-0005mx-K7; Tue, 05 Dec 2006 19:20:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrkWe-0005ms-9s for ipfix@ietf.org; Tue, 05 Dec 2006 19:20:40 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrkWb-0003HF-MR for ipfix@ietf.org; Tue, 05 Dec 2006 19:20:40 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Dec 2006 01:20:36 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB60KYCh023365; Wed, 6 Dec 2006 01:20:34 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB60KTAJ008080; Wed, 6 Dec 2006 01:20:29 +0100 (MET) Received: from [10.61.64.53] (ams3-vpn-dhcp53.cisco.com [10.61.64.53]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id AAA16695; Wed, 6 Dec 2006 00:20:27 GMT Message-ID: <45760CAC.7000808@cisco.com> Date: Wed, 06 Dec 2006 00:19:56 +0000 From: Andrew Johnson <andrjohn@cisco.com> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Schmoll, Carsten" <Carsten.Schmoll@fokus.fraunhofer.de> Subject: Re: [IPFIX] IPv6 care-of and home address References: <70524A4436C03E43A293958B505008B6568FE6@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: <70524A4436C03E43A293958B505008B6568FE6@EXCHSRV.fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6053; t=1165364434; x=1166228434; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20<andrjohn@cisco.com> |Subject:=20Re=3A=20[IPFIX]=20IPv6=20care-of=20and=20home=20address |Sender:=20; bh=KjtDTq4fqGlLJawDuAbatvFayBPY7r6dh1THX3Az0Uk=; b=c4G9BLcbSXxugnIMNty1HE4rkpmut6iRgmLhXdIXRHAe5p40Atmy1Xq94Xci8ZjlQn3qcZ24 Un7MpOID+SrmJFPw3ftdWAWx6EeJtp0TwTCDHTW0TYzd3/qDsmOF9TMV; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list <ipfix.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ipfix> List-Post: <mailto:ipfix@ietf.org> List-Help: <mailto:ipfix-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe> Errors-To: ipfix-bounces@ietf.org Hi Carsten Schmoll, Carsten wrote: > Dear Andrew, > > I think I tend to disagree: I'm not that familiar with the specifics of MIPv6 so the questions I had weren't rhetorical. You've answered them rather well below though. > Afaik mobile IPv6 explicitely introduced the > type 2 routing header for transporting the HoA: > > "The Type 2 Routing header is different from the Type 0 Routing > header defined in RFC 2460 in that it can only store a single address > and is only specified for use with Mobile IPv6. The Type 0 Routing > header can store multiple addresses and is processed by routers for > generalized source routing. Using a different routing type allows > firewalls to treat source-routed packets differently from packets > sent directly by Mobile IPv6-capable correspondent nodes to mobile > nodes that are away from home." > > Similarly this is true for the Destinatio Option of Type 201 used in MIPv6: > > "The Home Address option in the Destination Options extension header is > used to indicate the home address of the mobile node and is included in > binding updates sent to home agents and packets sent directly to Mobile > IPv6-capable correspondent nodes by a mobile node when it is away from > home when a binding exists." > > Therefore I would suggest to keep the originally proposed names and > in the text for the draft mention explicitely where these HoAs > were taken from. OK. As long as there definitions specifically restrict the elements to be taken from Type 0 and Type 201 variants of these headers then that seems fine. You may want to consider a more general purpose element and a separate element for the type, but it seems you're monitoring a pretty specialised environment. regards Andrew >> -----Original Message----- >> From: Andrew Johnson [mailto:andrjohn@cisco.com] >> Sent: Thursday, November 30, 2006 7:49 PM >> To: Schmoll, Carsten >> Cc: Juergen Quittek; ipfix@ietf.org >> Subject: Re: [IPFIX] IPv6 care-of and home address >> >> Schmoll, Carsten wrote: >>> Andrew, >>> >>> I was wondering what "kind of" IP address my >>> collector will receive when there is only >>> sourceIPv6Address in the accounting flow record. >>> >>> But I agree now that we should say that >>> in a mobile environment an sourceIPv6Address >>> will always denote the care-of address from >>> the usual place in the IPv6 header. >>> >>> We probably want to note this in the info model. >>> >>> So I change my proposal to just request: >>> >>> sourceIPv6HomeAddress >>> destinationIPv6HomeAddress >> The address from the IPv6 routing header is not specifically >> a "Home Address" is it? While the Mobile IPv6 environment >> conceptualises it this way, you really are collecting is an >> Ipv6RoutingHeaderIpv6Address. >> >> Similarly for the Destination Extension header. >> >> I'm not sure about the names there, but you get the idea. >> >> Cheers >> >> Andrew >> >> >> >>> Jürgen: do you agree too? >>> May a write some short text for the info model on that? >>> >>> Best regards, >>> Carsten. >>> >>> >>>> -----Original Message----- >>>> From: Andrew Johnson [mailto:andrjohn@cisco.com] >>>> Sent: Thursday, November 30, 2006 4:08 PM >>>> To: Schmoll, Carsten >>>> Cc: Juergen Quittek; ipfix@ietf.org >>>> Subject: Re: [IPFIX] IPv6 care-of and home address >>>> >>>> Hi Carsten >>>> >>>> The Routing EH and Destination EH have the source and >>>> destination Home Addresses in them, so new new fields >>>> for them make sense. >>>> >>>> The Care of Addresses are just from the IPv6 header, so >>>> why do you need new types for them? >>>> >>>> regards >>>> >>>> Andrew >>>> >>>> >>>> Schmoll, Carsten wrote: >>>>> Dear all, >>>>> >>>>> we are currently investigating on a prototype to send >>>>> accounted IP flow information in a mobile IPv6 environment. >>>>> >>>>> For reasons of simplicity and speed we usually export the >>>>> care-of address (CoA) and the correspondent node's IP >>>>> address as sourceIPv6Address and destinationIPv6Address. >>>>> >>>>> In case of multiple users on one terminal however (or one >>>>> user making use of multiple of his identities) we'll have >>>>> to capture and export the home address (HoA) too. The HoA >>>>> is embedded in an IPv6 extension header of either type >>>>> Routing EH (43) or the Destination Options EH (60). >>>>> >>>>> This would result then in a flow record with two IPv6 source >>>>> addresses. Even though repetition of the sourceIPv6 address >>>>> is legal I would like to propose additional IEs to avoid >>>>> ambiguity. These could be: >>>>> >>>>> sourceIPv6CareOfAddress >>>>> sourceIPv6HomeAddress >>>>> destinationIPv6CareOfAddress >>>>> destinationIPv6HomeAddress >>>>> >>>>> This would also cover the case where both endpoints of a >>>>> communication are mobile nodes. >>>>> >>>>> What do you think? >>>>> >>>>> Best regards, >>>>> Carsten. >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Andrew Johnson [mailto:andrjohn@cisco.com] >>>>>> Sent: Tuesday, November 07, 2006 11:27 PM >>>>>> To: Juergen Quittek >>>>>> Cc: Schmoll, Carsten; ipfix@ietf.org >>>>>> Subject: Re: [IPFIX] IPv6 care-of and home address >>>>>> >>>>>> Juergen Quittek wrote: >>>>>>> Carsten, >>>>>>> >>>>>>> I do understand how these addresses are associated with >>>>>>> an interface. But how do you think are they associated >>>>>>> with a certain flow? >>>>>> That really depends on the common properties that define >>>>>> Carsten's flow. Perhaps these different properties could >>>>>> part of an Option Template Record that provides information >>>>>> on an interface. >>>>>> >>>>>> However, it seems that "The IPv6 source address in the IP >>>>>> packet header" is the wrong element to use these and new >>>>>> ones should be requested if there is an application in >>>>>> mind. >>>>>> >>>>>> >>>>>> regards >>>>>> >>>>>> Andrew >>>>>> >>>>>> >> _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 05 19:22:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrkWf-0005mx-K7; Tue, 05 Dec 2006 19:20:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrkWe-0005ms-9s for ipfix@ietf.org; Tue, 05 Dec 2006 19:20:40 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrkWb-0003HF-MR for ipfix@ietf.org; Tue, 05 Dec 2006 19:20:40 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Dec 2006 01:20:36 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB60KYCh023365; Wed, 6 Dec 2006 01:20:34 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB60KTAJ008080; Wed, 6 Dec 2006 01:20:29 +0100 (MET) Received: from [10.61.64.53] (ams3-vpn-dhcp53.cisco.com [10.61.64.53]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id AAA16695; Wed, 6 Dec 2006 00:20:27 GMT Message-ID: <45760CAC.7000808@cisco.com> Date: Wed, 06 Dec 2006 00:19:56 +0000 From: Andrew Johnson <andrjohn@cisco.com> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Schmoll, Carsten" <Carsten.Schmoll@fokus.fraunhofer.de> Subject: Re: [IPFIX] IPv6 care-of and home address References: <70524A4436C03E43A293958B505008B6568FE6@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: <70524A4436C03E43A293958B505008B6568FE6@EXCHSRV.fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6053; t=1165364434; x=1166228434; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20<andrjohn@cisco.com> |Subject:=20Re=3A=20[IPFIX]=20IPv6=20care-of=20and=20home=20address |Sender:=20; bh=KjtDTq4fqGlLJawDuAbatvFayBPY7r6dh1THX3Az0Uk=; b=c4G9BLcbSXxugnIMNty1HE4rkpmut6iRgmLhXdIXRHAe5p40Atmy1Xq94Xci8ZjlQn3qcZ24 Un7MpOID+SrmJFPw3ftdWAWx6EeJtp0TwTCDHTW0TYzd3/qDsmOF9TMV; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list <ipfix.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ipfix> List-Post: <mailto:ipfix@ietf.org> List-Help: <mailto:ipfix-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe> Errors-To: ipfix-bounces@ietf.org Hi Carsten Schmoll, Carsten wrote: > Dear Andrew, > > I think I tend to disagree: I'm not that familiar with the specifics of MIPv6 so the questions I had weren't rhetorical. You've answered them rather well below though. > Afaik mobile IPv6 explicitely introduced the > type 2 routing header for transporting the HoA: > > "The Type 2 Routing header is different from the Type 0 Routing > header defined in RFC 2460 in that it can only store a single address > and is only specified for use with Mobile IPv6. The Type 0 Routing > header can store multiple addresses and is processed by routers for > generalized source routing. Using a different routing type allows > firewalls to treat source-routed packets differently from packets > sent directly by Mobile IPv6-capable correspondent nodes to mobile > nodes that are away from home." > > Similarly this is true for the Destinatio Option of Type 201 used in MIPv6: > > "The Home Address option in the Destination Options extension header is > used to indicate the home address of the mobile node and is included in > binding updates sent to home agents and packets sent directly to Mobile > IPv6-capable correspondent nodes by a mobile node when it is away from > home when a binding exists." > > Therefore I would suggest to keep the originally proposed names and > in the text for the draft mention explicitely where these HoAs > were taken from. OK. As long as there definitions specifically restrict the elements to be taken from Type 0 and Type 201 variants of these headers then that seems fine. You may want to consider a more general purpose element and a separate element for the type, but it seems you're monitoring a pretty specialised environment. regards Andrew >> -----Original Message----- >> From: Andrew Johnson [mailto:andrjohn@cisco.com] >> Sent: Thursday, November 30, 2006 7:49 PM >> To: Schmoll, Carsten >> Cc: Juergen Quittek; ipfix@ietf.org >> Subject: Re: [IPFIX] IPv6 care-of and home address >> >> Schmoll, Carsten wrote: >>> Andrew, >>> >>> I was wondering what "kind of" IP address my >>> collector will receive when there is only >>> sourceIPv6Address in the accounting flow record. >>> >>> But I agree now that we should say that >>> in a mobile environment an sourceIPv6Address >>> will always denote the care-of address from >>> the usual place in the IPv6 header. >>> >>> We probably want to note this in the info model. >>> >>> So I change my proposal to just request: >>> >>> sourceIPv6HomeAddress >>> destinationIPv6HomeAddress >> The address from the IPv6 routing header is not specifically >> a "Home Address" is it? While the Mobile IPv6 environment >> conceptualises it this way, you really are collecting is an >> Ipv6RoutingHeaderIpv6Address. >> >> Similarly for the Destination Extension header. >> >> I'm not sure about the names there, but you get the idea. >> >> Cheers >> >> Andrew >> >> >> >>> Jürgen: do you agree too? >>> May a write some short text for the info model on that? >>> >>> Best regards, >>> Carsten. >>> >>> >>>> -----Original Message----- >>>> From: Andrew Johnson [mailto:andrjohn@cisco.com] >>>> Sent: Thursday, November 30, 2006 4:08 PM >>>> To: Schmoll, Carsten >>>> Cc: Juergen Quittek; ipfix@ietf.org >>>> Subject: Re: [IPFIX] IPv6 care-of and home address >>>> >>>> Hi Carsten >>>> >>>> The Routing EH and Destination EH have the source and >>>> destination Home Addresses in them, so new new fields >>>> for them make sense. >>>> >>>> The Care of Addresses are just from the IPv6 header, so >>>> why do you need new types for them? >>>> >>>> regards >>>> >>>> Andrew >>>> >>>> >>>> Schmoll, Carsten wrote: >>>>> Dear all, >>>>> >>>>> we are currently investigating on a prototype to send >>>>> accounted IP flow information in a mobile IPv6 environment. >>>>> >>>>> For reasons of simplicity and speed we usually export the >>>>> care-of address (CoA) and the correspondent node's IP >>>>> address as sourceIPv6Address and destinationIPv6Address. >>>>> >>>>> In case of multiple users on one terminal however (or one >>>>> user making use of multiple of his identities) we'll have >>>>> to capture and export the home address (HoA) too. The HoA >>>>> is embedded in an IPv6 extension header of either type >>>>> Routing EH (43) or the Destination Options EH (60). >>>>> >>>>> This would result then in a flow record with two IPv6 source >>>>> addresses. Even though repetition of the sourceIPv6 address >>>>> is legal I would like to propose additional IEs to avoid >>>>> ambiguity. These could be: >>>>> >>>>> sourceIPv6CareOfAddress >>>>> sourceIPv6HomeAddress >>>>> destinationIPv6CareOfAddress >>>>> destinationIPv6HomeAddress >>>>> >>>>> This would also cover the case where both endpoints of a >>>>> communication are mobile nodes. >>>>> >>>>> What do you think? >>>>> >>>>> Best regards, >>>>> Carsten. >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Andrew Johnson [mailto:andrjohn@cisco.com] >>>>>> Sent: Tuesday, November 07, 2006 11:27 PM >>>>>> To: Juergen Quittek >>>>>> Cc: Schmoll, Carsten; ipfix@ietf.org >>>>>> Subject: Re: [IPFIX] IPv6 care-of and home address >>>>>> >>>>>> Juergen Quittek wrote: >>>>>>> Carsten, >>>>>>> >>>>>>> I do understand how these addresses are associated with >>>>>>> an interface. But how do you think are they associated >>>>>>> with a certain flow? >>>>>> That really depends on the common properties that define >>>>>> Carsten's flow. Perhaps these different properties could >>>>>> part of an Option Template Record that provides information >>>>>> on an interface. >>>>>> >>>>>> However, it seems that "The IPv6 source address in the IP >>>>>> packet header" is the wrong element to use these and new >>>>>> ones should be requested if there is an application in >>>>>> mind. >>>>>> >>>>>> >>>>>> regards >>>>>> >>>>>> Andrew >>>>>> >>>>>> >> _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 05 19:41:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grkqv-0007VP-4L; Tue, 05 Dec 2006 19:41:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grkqu-0007VF-EC for ipfix@ietf.org; Tue, 05 Dec 2006 19:41:36 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grkqs-00071V-Rf for ipfix@ietf.org; Tue, 05 Dec 2006 19:41:36 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Dec 2006 01:41:34 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB60fYiK030060; Wed, 6 Dec 2006 01:41:34 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB60fXAJ015646; Wed, 6 Dec 2006 01:41:33 +0100 (MET) Received: from [10.61.64.53] (ams3-vpn-dhcp53.cisco.com [10.61.64.53]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id AAA18102; Wed, 6 Dec 2006 00:41:32 GMT Message-ID: <4576119D.3090007@cisco.com> Date: Wed, 06 Dec 2006 00:41:01 +0000 From: Andrew Johnson <andrjohn@cisco.com> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Brian Trammell <bht@cert.org> Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <CDF26EC0-6097-468D-A26E-258392170B5D@cert.org> <45756B12.8020109@cisco.com> <5A5FB8CC-317C-40A9-A0B3-5E6E97BE370D@cert.org> In-Reply-To: <5A5FB8CC-317C-40A9-A0B3-5E6E97BE370D@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6051; t=1165365694; x=1166229694; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20<andrjohn@cisco.com> |Subject:=20Re=3A=20[IPFIX]=20WG=20last=20call=20on=20draft-ietf-ipfix-re ducing-redundancy-01.txt=0A=20until=20December=201st |Sender:=20; bh=jJ8SEQWAKF98+TCwewN4iDH61C9Aoc5S5GQw3hEuMpM=; b=C41lM39f6IXKwLsefxFYKS3oqEJ1/u0+33b/oEbG+vJBMXt0Pd8DgKO98rCulKCyFOQ3t5mn 4WfiLWU3kx643mPUq9XOFWrveweK75Zh4EwJifW50601xrBOTFV64Yp9; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Elisa Boschi <boschie@tik.ee.ethz.ch>, ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list <ipfix.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ipfix> List-Post: <mailto:ipfix@ietf.org> List-Help: <mailto:ipfix-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe> Errors-To: ipfix-bounces@ietf.org Hi all, some comments inline: Brian Trammell wrote: > Benoit and all, > > See inline, as always... > > On Dec 5, 2006, at 7:50 AM, Benoit Claise wrote: > >>> 7 para 7 OLD: >>> >>> If a Collecting Process receives a Common Properties Withdrawal >>> message, the Collecting Process MUST delete the corresponding Common >>> Properties associated with the specific SCTP association and specific >>> Observation Domain, and stop decoding IPFIX Messages that use the >>> withdrawn Templates. >>> >>> 7 para 7 NEW: >>> >>> If a Collecting Process receives a Common Properties Withdrawal >>> message, the Collecting Process MUST delete the corresponding Common >>> Properties associated with the specific SCTP association and specific >>> Observation Domain. >> >> I would like to add, "and stop decoding IPFIX Messages that use the >> withdrawn Common Properties" >> This would be in line with [IPFIX-PROTO] "The Collecting Process's >> Side" section: >> >> If a Collecting Process receives a Template Withdraw Message, the >> Collecting Process MUST delete the corresponding Template Records >> associated with the specific SCTP association and specific >> Observation Domain, and stop decoding IPFIX Messages that use the >> withdrawn Templates. > > Hmmm.... I agree with the point, but I'm not sure this is the right > language here. A CP would stop decoding Messages (actually, Sets) > described by withdrawn Templates because Templates are necessary for > decode. Common Properties are a bit higher in the stack - the Sets can > be decoded, but some data would be missing for each record. How about > something like: > > "and stop interpreting Data Records referring to those Common > Properties. The receipt of Data Records referring to Common Properties > that have been withdrawn MUST be ignored and SHOULD be logged by the > Collecting Process." I think even this is in danger of putting demands on a collector that go beyond what the IPFIX specifies. I think Common Properties should be expected to work with a collector that is compliant with what IPFIX PROTO says today, and this is something new. I agree that a flow with a CPid that doesn't map to anything is a bit meaningless and a collector COULD be configured to throw away meaningless flows. However, in general I would expect a collector to keep flows even without the associated data that can be gleaned from options. >>> 7.1 para 3 OLD: >>> >>> The Collecting Process MUST NOT decode any further Data Records which >>> are associated with the expired Common Properties. If a Common >>> Property is refreshed with a Template Record that differs from the >>> previous received Template Record, the Collecting Process SHOULD log >>> a warning and replace the previous received Common Property with the >>> new one. The Template lifetime at the Collecting Process MUST be at >>> least 3 times higher than the Template refresh timeout configured on >>> the Exporting Process. >>> >>> 7.1 para 3 NEW: >>> >>> The Collecting Process MUST NOT decode any further Data Records which >>> are associated with the expired Common Properties. If a Common >>> Property is refreshed with a definition that differs from the >>> previous definition, the Collecting Process SHOULD log >>> a warning and replace the previous received Common Property with the >>> new one. The Common Property lifetime at the Collecting Process >>> MUST be at >>> least 3 times higher than the Common Property timeout configured on >>> the Exporting Process. >> >> In this case, you insert a new term "Common Property timeout". I propose: >> The Collecting Process MUST NOT decode any further Data Records which >> are associated with the expired Common Properties. If a Common >> Property is refreshed with a definition that differs from the >> previous definition, the Collecting Process SHOULD log >> a warning and replace the previous received Common Property with the >> new one. The Common Property lifetime at the Collecting Process >> MUST be at >> least 3 times higher than the refresh timeout of the Template used >> to export the >> Common Property definition, configured on the Exporting Process. > > (see previous message where this was clarified to "Common Property > refresh timeout") > > An alternative would be to define the Common Property refresh timeout > elsewhere in the document, and refer to it here, as we do with Template > refresh in the protocol. Since the Common Property lifetime and the > Template lifetime are both scoped to the Transport Session lifetime for > connection-oriented transports, there may be no reason to presume that > the Template refresh and Common Property refresh timeout should ever be > different (indeed, things may break if they are; I've not thought it all > the way through); however, I do think it is clearer if the Common > Property refresh mechanism has its own terminology rather than tying it > directly to the template timeout. > > Thoughts? Again I am concerned that Reducing Redundancy is making demands of the protocol beyond what is expected today. I don't think options are particularly well dealt with and I agree that treating them in a similar way to templates is probably the best approach, but a collector that is written without Reducing Redundancy in mind should be expected to work with these additional requirements. That means that we can't add some new lifetime for CP, or even a more general one that covers all options. That said, it would be fair to add additional requirements on the Exporter to implement the scheme, and resending the options data regularly be a good thing. Since the the timeout values for the template and common properties will be based on the expected reliability of the UDP stream, then it makes sense to me that they would be the same. Cheers Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 05 19:41:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grkqv-0007VP-4L; Tue, 05 Dec 2006 19:41:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grkqu-0007VF-EC for ipfix@ietf.org; Tue, 05 Dec 2006 19:41:36 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grkqs-00071V-Rf for ipfix@ietf.org; Tue, 05 Dec 2006 19:41:36 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Dec 2006 01:41:34 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB60fYiK030060; Wed, 6 Dec 2006 01:41:34 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB60fXAJ015646; Wed, 6 Dec 2006 01:41:33 +0100 (MET) Received: from [10.61.64.53] (ams3-vpn-dhcp53.cisco.com [10.61.64.53]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id AAA18102; Wed, 6 Dec 2006 00:41:32 GMT Message-ID: <4576119D.3090007@cisco.com> Date: Wed, 06 Dec 2006 00:41:01 +0000 From: Andrew Johnson <andrjohn@cisco.com> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Brian Trammell <bht@cert.org> Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <CDF26EC0-6097-468D-A26E-258392170B5D@cert.org> <45756B12.8020109@cisco.com> <5A5FB8CC-317C-40A9-A0B3-5E6E97BE370D@cert.org> In-Reply-To: <5A5FB8CC-317C-40A9-A0B3-5E6E97BE370D@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6051; t=1165365694; x=1166229694; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20<andrjohn@cisco.com> |Subject:=20Re=3A=20[IPFIX]=20WG=20last=20call=20on=20draft-ietf-ipfix-re ducing-redundancy-01.txt=0A=20until=20December=201st |Sender:=20; bh=jJ8SEQWAKF98+TCwewN4iDH61C9Aoc5S5GQw3hEuMpM=; b=C41lM39f6IXKwLsefxFYKS3oqEJ1/u0+33b/oEbG+vJBMXt0Pd8DgKO98rCulKCyFOQ3t5mn 4WfiLWU3kx643mPUq9XOFWrveweK75Zh4EwJifW50601xrBOTFV64Yp9; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Elisa Boschi <boschie@tik.ee.ethz.ch>, ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list <ipfix.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ipfix> List-Post: <mailto:ipfix@ietf.org> List-Help: <mailto:ipfix-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe> Errors-To: ipfix-bounces@ietf.org Hi all, some comments inline: Brian Trammell wrote: > Benoit and all, > > See inline, as always... > > On Dec 5, 2006, at 7:50 AM, Benoit Claise wrote: > >>> 7 para 7 OLD: >>> >>> If a Collecting Process receives a Common Properties Withdrawal >>> message, the Collecting Process MUST delete the corresponding Common >>> Properties associated with the specific SCTP association and specific >>> Observation Domain, and stop decoding IPFIX Messages that use the >>> withdrawn Templates. >>> >>> 7 para 7 NEW: >>> >>> If a Collecting Process receives a Common Properties Withdrawal >>> message, the Collecting Process MUST delete the corresponding Common >>> Properties associated with the specific SCTP association and specific >>> Observation Domain. >> >> I would like to add, "and stop decoding IPFIX Messages that use the >> withdrawn Common Properties" >> This would be in line with [IPFIX-PROTO] "The Collecting Process's >> Side" section: >> >> If a Collecting Process receives a Template Withdraw Message, the >> Collecting Process MUST delete the corresponding Template Records >> associated with the specific SCTP association and specific >> Observation Domain, and stop decoding IPFIX Messages that use the >> withdrawn Templates. > > Hmmm.... I agree with the point, but I'm not sure this is the right > language here. A CP would stop decoding Messages (actually, Sets) > described by withdrawn Templates because Templates are necessary for > decode. Common Properties are a bit higher in the stack - the Sets can > be decoded, but some data would be missing for each record. How about > something like: > > "and stop interpreting Data Records referring to those Common > Properties. The receipt of Data Records referring to Common Properties > that have been withdrawn MUST be ignored and SHOULD be logged by the > Collecting Process." I think even this is in danger of putting demands on a collector that go beyond what the IPFIX specifies. I think Common Properties should be expected to work with a collector that is compliant with what IPFIX PROTO says today, and this is something new. I agree that a flow with a CPid that doesn't map to anything is a bit meaningless and a collector COULD be configured to throw away meaningless flows. However, in general I would expect a collector to keep flows even without the associated data that can be gleaned from options. >>> 7.1 para 3 OLD: >>> >>> The Collecting Process MUST NOT decode any further Data Records which >>> are associated with the expired Common Properties. If a Common >>> Property is refreshed with a Template Record that differs from the >>> previous received Template Record, the Collecting Process SHOULD log >>> a warning and replace the previous received Common Property with the >>> new one. The Template lifetime at the Collecting Process MUST be at >>> least 3 times higher than the Template refresh timeout configured on >>> the Exporting Process. >>> >>> 7.1 para 3 NEW: >>> >>> The Collecting Process MUST NOT decode any further Data Records which >>> are associated with the expired Common Properties. If a Common >>> Property is refreshed with a definition that differs from the >>> previous definition, the Collecting Process SHOULD log >>> a warning and replace the previous received Common Property with the >>> new one. The Common Property lifetime at the Collecting Process >>> MUST be at >>> least 3 times higher than the Common Property timeout configured on >>> the Exporting Process. >> >> In this case, you insert a new term "Common Property timeout". I propose: >> The Collecting Process MUST NOT decode any further Data Records which >> are associated with the expired Common Properties. If a Common >> Property is refreshed with a definition that differs from the >> previous definition, the Collecting Process SHOULD log >> a warning and replace the previous received Common Property with the >> new one. The Common Property lifetime at the Collecting Process >> MUST be at >> least 3 times higher than the refresh timeout of the Template used >> to export the >> Common Property definition, configured on the Exporting Process. > > (see previous message where this was clarified to "Common Property > refresh timeout") > > An alternative would be to define the Common Property refresh timeout > elsewhere in the document, and refer to it here, as we do with Template > refresh in the protocol. Since the Common Property lifetime and the > Template lifetime are both scoped to the Transport Session lifetime for > connection-oriented transports, there may be no reason to presume that > the Template refresh and Common Property refresh timeout should ever be > different (indeed, things may break if they are; I've not thought it all > the way through); however, I do think it is clearer if the Common > Property refresh mechanism has its own terminology rather than tying it > directly to the template timeout. > > Thoughts? Again I am concerned that Reducing Redundancy is making demands of the protocol beyond what is expected today. I don't think options are particularly well dealt with and I agree that treating them in a similar way to templates is probably the best approach, but a collector that is written without Reducing Redundancy in mind should be expected to work with these additional requirements. That means that we can't add some new lifetime for CP, or even a more general one that covers all options. That said, it would be fair to add additional requirements on the Exporter to implement the scheme, and resending the options data regularly be a good thing. Since the the timeout values for the template and common properties will be based on the expected reliability of the UDP stream, then it makes sense to me that they would be the same. Cheers Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 05 20:47:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrlrK-0002DO-17; Tue, 05 Dec 2006 20:46:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrlrI-0002DJ-Q0 for ipfix@ietf.org; Tue, 05 Dec 2006 20:46:04 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrlrH-0004yT-R2 for ipfix@ietf.org; Tue, 05 Dec 2006 20:46:04 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Dec 2006 02:45:59 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB61jwU5009434; Wed, 6 Dec 2006 02:45:58 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB61jwAJ012180; Wed, 6 Dec 2006 02:45:58 +0100 (MET) Received: from [10.61.64.53] (ams3-vpn-dhcp53.cisco.com [10.61.64.53]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id BAA22083; Wed, 6 Dec 2006 01:45:55 GMT Message-ID: <457620B4.3080800@cisco.com> Date: Wed, 06 Dec 2006 01:45:24 +0000 From: Andrew Johnson <andrjohn@cisco.com> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Benoit Claise <bclaise@cisco.com> Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> In-Reply-To: <4575F2B4.4030806@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=18837; t=1165369558; x=1166233558; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20<andrjohn@cisco.com> |Subject:=20Re=3A=20[IPFIX]=20WG=20last=20call=20on=20draft-ietf-ipfix-re ducing-redundancy-01.txt=0A=20until=20December=201st |Sender:=20; bh=oq0uO1tFi9e4jBdPA5IFPJYy9y24dDAgp14Sp/Tua5E=; b=Jdm3ivhPNoZZDSnkSJ6LtBrSNSIbtpTRqKAr5YGnBF7i4EGFFSFaExv5Twnj40+anhQo0UvX oqHwwbqX4vKKMoSYscPibifmjWayD9uBcf27XY5mAwOIZ+jmfllab2oi; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list <ipfix.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ipfix> List-Post: <mailto:ipfix@ietf.org> List-Help: <mailto:ipfix-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe> Errors-To: ipfix-bounces@ietf.org Benoit Claise wrote: > Hi Andrew, >> >> >> If there are references to PSAMP drafts, doesn't that >> block this from becoming an RFC until the PSAMP ones >> are RFCs? > > Sure. OK. >> Do we have to mention PSAMP so much anyway, >> as it's just a specialised use case of IPFIX? > > Right, I think that the previous version was somehow lacking some > information. > Yes we can use this mechanism for all sort of flows, even for: > "So the PSAMP export can be seen as special IPFIX Flow Record containing > information about a single packet." dixit PSAMP-PROTO > However, by having the clear distinctions... > > 3.1 Per Flow Data Reduction...............................11 > 3.1.1 Unique Data Reduction..................................11 > 3.1.2 Multiple Data Reduction................................12 > 3.2 Per Packet Data Reduction.............................13 > ... I believe that we gained in clarity... Maybe not for you, as you > know enough about IPFIX and PSAMP to understand how to apply this > techniques, but for the rest of the community. It seems that 3.2 doesn't add anything to 3.1.1 other than providing another example. Perhaps remove the per-packet stuff from the main part of the draft but keep it as a detailed example at the end. >> Since a flow is defined as a group of packets that share >> a set of common properties, i.e. key fields, is there >> any danger that the commonPropertiesID will be wrongly >> assumed to refer to only the complete set of key fields? > > By definition, I think this is impossible. The flow key definition says > "Each of the fields which are used to define a Flow are termed Flow > Keys.". So there is nothing in common between flows. However, I > understand your concern for novice readers. > > OLD section 1 "Introduction" > > Regardless of the fields content, flow records with common > properties export the same fields in every single flow record. > These common properties may represent values common to a collection > of flows or packets, or values that are invariant over time. The > reduction of redundant data from the export stream can result in a > significant reduction of the transferred data. > > NEW section 1 "Introduction" > > Regardless of the fields content, flow records with common properties > export the same fields in every single flow record. These common > properties may represent values common to a collection of flows or > packets, or values that are invariant over time. Note that the common > properties don't represent the list of flow keys, which are used to > define a flow definition: however, the common properties may contain > some of the flow keys. The reduction of redundant data from the export > stream can result in a significant reduction of the transferred data. My concern wasn't really directed at the draft itself, but just the name "common properties". From IPFIX-PROTO: "A Flow is defined as a set of IP packets passing an Observation Point in the network during a certain time interval. All packets belonging to a particular Flow have a set of common properties." And then from IPFIX-INFO: Description of commonPropertiesId: An identifier of a set of common properties that is unique per Observation Domain. Typically, this Information Element is used to link to information reported in separate records. The terminology is almost identical. The commonPropertiesId refers to "a set of common properties" that is quite different from ones that determine a Flow. >> Is there any need to define a new term for "Specific >> Properties"? These are just part of a normal Data Record. >> For example: >> "... The rows are then referenced by the Specific Properties >> by using the appropriate value for the Common Properties >> identifier." >> >> could simply be: >> "... The rows are then referenced by Data Records by >> using the appropriate value for the Common Properties >> identifier." > > In your example, the "Data Records" doesn't mean the full data records > before applying the redundancy reduction mechanism but only a part of it. > So it might be confusing... That's the trick we found. > > However, I could agree that the draft would work without a formal (upper > case) definition.... So do you have the same idea for the Common > Properties? Considering there is a commonPropertiesID, I am quite happy with you referring to Common Properties. There seems to be a bit of a conceptual difference here though. You seem to imagine that an Exporting Process has a set of IPFIX Data Records which it then applies some processing to to get some new special IPFIX Data Records and some Common Property options. The original set of Data Records may never actually exist, depending on how the scheme is implemented. For me, the only set of IPFIX Data Records to consider are the ones which are actually sent. >> Are option withdrawal messages part of IPFIX? > Yes. IPFIX says: "The Set ID field MUST contain the value 2 for Template > Set withdrawal and the value 3 for Options Template Set withdrawal." > Unless you want to say an option data record withdrawal message? There is a distinct difference between withdrawing the template and withdrawing the data record associated with an option template. I think that the concept works though, although perhaps not by design. > Note: I discovered that the draft still contains: "Option Data Record" > This term has been removed from IPFIX-PROTO. So it should be removed in > this draft. > >> Are they meaningful in IPFIX? i.e. per the PROTO will an option >> with scope but no data be deemed invalidated by the Collector. >> Scope without data is the same as never having recieved the >> mapping in the first place. I think that it would be up to the >> implementation but it seems like a good idea so if we can't add >> it to the PROTO can we put it in the implementation guidelines? >> >> How do you propose to withdraw common properties when they are >> associated with a template rather than the Common Properties index? > > I don't ;) This is the reason why the use the Common Properties index is > a cleaner design. I think withdrawal messages should work in general for options data, so why not send an empty record with the template as scope? >> General Comments >> ================ >> I think, sections 3.1.2, 8.2 and 8.3 would be better grouped >> into a 3.2 Advanced Techniques section. >> >> I think 3.2 Per Packet Data Reduction, should be removed and >> any information that is not in section 3.1 should be added to >> to the PSAMP example. >> I think the the per-packet example is a good example of >> per flow reducing redundancy and section 11.1.1 can be removed. > See one of my previous remark about: > > 3.1 Per Flow Data Reduction...............................11 > 3.1.1 Unique Data Reduction..................................11 > 3.1.2 Multiple Data Reduction................................12 > 3.2 Per Packet Data Reduction.............................13 > > Again, it's because you know the boundary between IPFIX and PSAMP I just don't think the repetition is necessary. Per-packet is just a good example of the technique, the Per Packet section doesn't seem to add any new information. >> Labels for the figures would be better if they were centred. > Agreed. >> >> There is all sorts of extra spacing at the end of the lines. >> >> >> >> Specific Comments >> ================= >> 2. Terminology >> Tabbing is inconsistent in definition of "Selector": >> (i) the Packet Content; (ii) information derived from the packet's >> treatment at the Observation Point; (iii) any selection state that may >> be maintained by the Selection Process. >> >> 3.1.2 Multiple Data Reduction >> >> I don't think this section is explained very well. From my original >> email to Elisa and Lutz (18th Nov 2005): >> Andrew Johnson wrote: >>> Flows >>> ===== >>> Flow A: flowId 1, flowId 11, 30 packets, 6000 bytes >>> Flow B: flowID 1, flowId 12, 50 packets, 9500 bytes >>> Flow C: flowId 2, flowId 11, 60 packets, 8000 bytes >>> Flow D: flowID 2, flowId 12, 10 packets, 1500 bytes >>> >>> Options >>> ======= >>> flowId 1 - destinationIpv4address 10.0.0.1, destinationTcpPort 80 >>> flowId 1 - destinationIpv4address 10.0.0.5, destinationTcpPort 80 >>> >>> flowId 11 - sourceIpv4address 10.0.1.10, sourceTcpPort 1932 >>> flowId 12 - sourceIpv4address 10.0.1.15, sourceTcpPort 1842 >> >> >> This shows how 4 (2+2) options can be expanded to 4 combinations of >> Data Record to reduce redundancy without the need to define 4 complete >> sets of Common Properties and therefore not save any bandwidth. The >> more options you have the better this works. 20 options (10+10) would >> give you up to 100 possible pairs common properties. >> >> This isn't really made clear in the draft text, with only "flow1" >> having two indices. > I agree the examples in figure 4/5 don't show this. > Maybe a new section in section 8 "Export and Evaluation Considerations"? >> The example in 11.1.2 doesn't even have any! > Agreed. This should be corrected. >> >> While I agree that using a template that doesn't include the cpID >> is a good idea to efficiently communicate flows with not so common >> properties, however I would call this an "Advanced Technique" to be >> listed in the section I proposed earlier. >> >> >> 3.2 Per Packet Data Reduction >> >> The text reads: >> If filtering is applied to select a series of packets, using the PSAMP >> specifications to export per-packet information might be relatively >> inefficient if the filtered fields (the common attributes) are >> exported in every single record. >> >> However in section 6.5.2.5 (Property Match Filtering) of PSAMP-PROTO >> it is explained how the filter information MUST be sent. This is >> designed so that the selector ID will match the one from the Data >> Record (via the selectionSequenceId) and perform exactly the function >> that is being proposed here for the commonPropertiesId. > Good point. I would remove this paragraph and move to this place the one > starting with: > > An example of the per packet data reduction is the measurement of > One-Way Delay (OWD), where the exact same specific packet must be > observed at the source and destination of the path to be measured. By > subtracting ... > >> >> >> 4. Specifications for bandwidth saving information export >> >> What is being specified here that isn't true for ALL options as >> described in IPFIX-PROTO? > > What do you suggest? Well it seems that section three really explains almost the same thing 3 times. The section 4 explains most of it again (with a bit more info) another 3 times. I would prefer section 3 to simply explain the technique. Walk through how the information from a Flow is split into two parts, and then add the bit from section 4 how these two parts are exported. Using more than one CPid in a record should be part of the advanced techniques once the basics are made clear. Per packet should just be a detailed example at the end. >> I think section 3 does a better job of explaining how all this >> works. I'm really not sure what section 4 adds. > > The idea was to put the specs in section 4 while the section 3 was the > high level solution. Rereading it, I see that now, but there seems to be a fair amount of repetition. >> (Aside: figure 9 refers to Common Sroperties). > Yep. thanks. >> >> >> 6. commonPropertiesID Management >> >> The text reads: >> The commonPropertiesID values MAY be assigned sequentially, but it�s >> It seems the "it's" is using an invalid character rather than an >> apostrophe. >> >> >> 7. The Collecting Process Side >> >> The text reads: >> Like TemplateIDs the commonPropertiesIDs are generated dynamically by >> the Exporting Process. Hence a restart of the Exporting Process may >> imply a renumbering of commonProperiesIDs. >> The collector can't know if the Exporter Process restarted, this is >> why we rescoped the commonPropertiesID to the Transport Session, so >> the above text is now redundant. > > I know it's redundant, but don't you think it helps. For example, we > don't explain anywhere (if I recall correctly) that "the > commonPropertiesIDs are generated dynamically by the Exporting Process" The commonPropertiesIDs are unique within the transport session. If the session is restarted then you've lost that scope and therefore can't keep using the same commonPropertiesID mappings. I don't see why the commonPropertiesIDs have to be dynamically generated by the Exporting Process. The could be shared between several EPs or pre-calculated based in historical data from that Observation Domain. >> The text reads: >> Common Properties IDs are unique per SCTP association and per >> Observation Domain. If the Collecting Process receives a common >> Properties ID which has already been received but which has not >> previously been withdrawn (i.e. a commonPropertiesID from the same >> Exporter Observation Domain with the same Template ID received on the >> SCTP association), then the Collecting Process MUST shutdown the >> association. > This is similar to [IPFIX-PROTO] > > Template IDs are unique per SCTP association and per Observation > Domain. If the Collecting Process receives a Template which has > already been received but which has not previously been withdrawn > (i.e. a Template Record from the same Exporter Observation Domain > with the same Template ID received on the SCTP association), then the > Collecting Process MUST shutdown the association. > >> >> and: >> If the Collecting Process receives a Common Properties Withdrawal >> message for a Common Properties that it has not received before on >> this SCTP assocation, it MUST reset the SCTP association, discard the >> IPFIX Message, and SHOULD log the error as it does for malformed IPFIX >> Messages. >> I think this might go against IPFIX-PROTO. > This is similar to [IPFIX-PROTO] These are similar to what IPFIX-PROTO says about templates, but that doesn't mean the text can just be used to talk about Data Records sent for Options Templates. Option data withdrawal messages are not mentioned in IPFIX-PROTO, although I think they can work. However, in general options data with the same scope as an earlier record will just overwrite the older record. > If the Collecting Process receives a Template Withdraw message for a > Template Record it has not received before on this SCTP assocation, > it MUST reset the SCTP association, discard the IPFIX Message, and > SHOULD log the error as it does for malformed IPFIX Messages. >> >> >> The text reads: >> If the Common Properties are not refreshed before that lifetime has >> expired, the Collecting Process MUST discard the corresponding >> definition of the commonPropertiesID and any current and future >> associated Data Records. In which case, an alarm MUST be logged. >> What happened to storing it until the option turned up. Furthermore >> you shouldn't dictate the the record is discarded, just because you >> can't tell a piece of potentially trivial information about a flow >> doesn't mean it's meaningless. The Common Properties in question >> could be anything. >> > This is similar to [IPFIX-PROTO] > > If the Template (or other definition) is not refreshed before that > lifetime has expired, the Collecting Process MUST discard that > definition and any current and future associated Data Records. In > which case, an alarm MUST be logged. This "(or other definition)" stuff is only mentioned for the Collecting Process and it really isn't clear if it should apply to Common Properties. However, storing the data records in a queue awaiting the decode information is really only something that is expected to be done at the start of the session. Is it mentioned in this draft? >> Besides, we're not changing the protocol here, right? > Right. So this is not an IPFIX redundancy reduction issue but an IPFIX > protocol issue... as we don't want to change the protocol with this draft. What's a protocol issue? I think applying all the requirements of templates to all options is changing the protocol. >> 8.1 Transport Protocol Choice The text reads: >> The proposed method is most effective using a reliable transport >> protocol for the transfer of the Common Properties. Therefore the use >> of SCTP or TCP is recommended. >> >> Note that SCTP isn't necessarily reliable. > SCTP -> PR-SCTP with the reliable mode >> >> >> 8.3 commonPropertiesID vs. TemplateID scope >> Additional flow properties can be tied to almost any I.E. For example >> a particular interface could be associated with the one IP address it >> serves. > That's true but I still think the design is cleaner with the Common > Properties Id. > See the remark about the Common Properties ID withdrawal You can withdraw any option record, so I don't think it's a big deal. >> 8.4 Efficiency Gain >> The text reads: >> "...it can�t predict whether future..." >> >> Weird apostrophe character again. >> >> >> >> Examples: >> >> 1. There is no padding between records, it's against IPFIX-PROTO, >> unless you use the special padding I.E. >> 2. The templates define the counts as 4 octets but the records show >> them as 2. >> 3. Since 11.1.1 and 11.2 don't demonstrate anything different, can >> we have just one example? >> 4. The tabbing is sometimes a little of on the run though of the I.E.s, >> and I think we can loose the commas. e.g. >> >> OLD >> - the source IPv4 Address, sourceIPv4Address [IPFIX-INFO], with a type >> of 8 and a length of 4 octets >> NEW >> - the source IPv4 Address: sourceIPv4Address [IPFIX-INFO] with a type >> of 8 and a length of 4 octets >> >> >> 5. What is a packet ID anyway? In general PSAMP uses sampling to gather >> detailed information about a small proportion of the network traffic. >> In most cases there won't be many common factors between the reports. >> The real exception is hash-based filtering, which is what I think the >> example uses. >> >> >> 6. Do we have to use enterprise specific things here? What about: >> observationTimeMilliseconds (323), >> digestHashValue (326), >> ipTotalLength (224) >> > Regards, Benoit. Regards Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 05 20:47:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrlrK-0002DO-17; Tue, 05 Dec 2006 20:46:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrlrI-0002DJ-Q0 for ipfix@ietf.org; Tue, 05 Dec 2006 20:46:04 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrlrH-0004yT-R2 for ipfix@ietf.org; Tue, 05 Dec 2006 20:46:04 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Dec 2006 02:45:59 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB61jwU5009434; Wed, 6 Dec 2006 02:45:58 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB61jwAJ012180; Wed, 6 Dec 2006 02:45:58 +0100 (MET) Received: from [10.61.64.53] (ams3-vpn-dhcp53.cisco.com [10.61.64.53]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id BAA22083; Wed, 6 Dec 2006 01:45:55 GMT Message-ID: <457620B4.3080800@cisco.com> Date: Wed, 06 Dec 2006 01:45:24 +0000 From: Andrew Johnson <andrjohn@cisco.com> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Benoit Claise <bclaise@cisco.com> Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> In-Reply-To: <4575F2B4.4030806@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=18837; t=1165369558; x=1166233558; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20<andrjohn@cisco.com> |Subject:=20Re=3A=20[IPFIX]=20WG=20last=20call=20on=20draft-ietf-ipfix-re ducing-redundancy-01.txt=0A=20until=20December=201st |Sender:=20; bh=oq0uO1tFi9e4jBdPA5IFPJYy9y24dDAgp14Sp/Tua5E=; b=Jdm3ivhPNoZZDSnkSJ6LtBrSNSIbtpTRqKAr5YGnBF7i4EGFFSFaExv5Twnj40+anhQo0UvX oqHwwbqX4vKKMoSYscPibifmjWayD9uBcf27XY5mAwOIZ+jmfllab2oi; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list <ipfix.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ipfix> List-Post: <mailto:ipfix@ietf.org> List-Help: <mailto:ipfix-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe> Errors-To: ipfix-bounces@ietf.org Benoit Claise wrote: > Hi Andrew, >> >> >> If there are references to PSAMP drafts, doesn't that >> block this from becoming an RFC until the PSAMP ones >> are RFCs? > > Sure. OK. >> Do we have to mention PSAMP so much anyway, >> as it's just a specialised use case of IPFIX? > > Right, I think that the previous version was somehow lacking some > information. > Yes we can use this mechanism for all sort of flows, even for: > "So the PSAMP export can be seen as special IPFIX Flow Record containing > information about a single packet." dixit PSAMP-PROTO > However, by having the clear distinctions... > > 3.1 Per Flow Data Reduction...............................11 > 3.1.1 Unique Data Reduction..................................11 > 3.1.2 Multiple Data Reduction................................12 > 3.2 Per Packet Data Reduction.............................13 > ... I believe that we gained in clarity... Maybe not for you, as you > know enough about IPFIX and PSAMP to understand how to apply this > techniques, but for the rest of the community. It seems that 3.2 doesn't add anything to 3.1.1 other than providing another example. Perhaps remove the per-packet stuff from the main part of the draft but keep it as a detailed example at the end. >> Since a flow is defined as a group of packets that share >> a set of common properties, i.e. key fields, is there >> any danger that the commonPropertiesID will be wrongly >> assumed to refer to only the complete set of key fields? > > By definition, I think this is impossible. The flow key definition says > "Each of the fields which are used to define a Flow are termed Flow > Keys.". So there is nothing in common between flows. However, I > understand your concern for novice readers. > > OLD section 1 "Introduction" > > Regardless of the fields content, flow records with common > properties export the same fields in every single flow record. > These common properties may represent values common to a collection > of flows or packets, or values that are invariant over time. The > reduction of redundant data from the export stream can result in a > significant reduction of the transferred data. > > NEW section 1 "Introduction" > > Regardless of the fields content, flow records with common properties > export the same fields in every single flow record. These common > properties may represent values common to a collection of flows or > packets, or values that are invariant over time. Note that the common > properties don't represent the list of flow keys, which are used to > define a flow definition: however, the common properties may contain > some of the flow keys. The reduction of redundant data from the export > stream can result in a significant reduction of the transferred data. My concern wasn't really directed at the draft itself, but just the name "common properties". From IPFIX-PROTO: "A Flow is defined as a set of IP packets passing an Observation Point in the network during a certain time interval. All packets belonging to a particular Flow have a set of common properties." And then from IPFIX-INFO: Description of commonPropertiesId: An identifier of a set of common properties that is unique per Observation Domain. Typically, this Information Element is used to link to information reported in separate records. The terminology is almost identical. The commonPropertiesId refers to "a set of common properties" that is quite different from ones that determine a Flow. >> Is there any need to define a new term for "Specific >> Properties"? These are just part of a normal Data Record. >> For example: >> "... The rows are then referenced by the Specific Properties >> by using the appropriate value for the Common Properties >> identifier." >> >> could simply be: >> "... The rows are then referenced by Data Records by >> using the appropriate value for the Common Properties >> identifier." > > In your example, the "Data Records" doesn't mean the full data records > before applying the redundancy reduction mechanism but only a part of it. > So it might be confusing... That's the trick we found. > > However, I could agree that the draft would work without a formal (upper > case) definition.... So do you have the same idea for the Common > Properties? Considering there is a commonPropertiesID, I am quite happy with you referring to Common Properties. There seems to be a bit of a conceptual difference here though. You seem to imagine that an Exporting Process has a set of IPFIX Data Records which it then applies some processing to to get some new special IPFIX Data Records and some Common Property options. The original set of Data Records may never actually exist, depending on how the scheme is implemented. For me, the only set of IPFIX Data Records to consider are the ones which are actually sent. >> Are option withdrawal messages part of IPFIX? > Yes. IPFIX says: "The Set ID field MUST contain the value 2 for Template > Set withdrawal and the value 3 for Options Template Set withdrawal." > Unless you want to say an option data record withdrawal message? There is a distinct difference between withdrawing the template and withdrawing the data record associated with an option template. I think that the concept works though, although perhaps not by design. > Note: I discovered that the draft still contains: "Option Data Record" > This term has been removed from IPFIX-PROTO. So it should be removed in > this draft. > >> Are they meaningful in IPFIX? i.e. per the PROTO will an option >> with scope but no data be deemed invalidated by the Collector. >> Scope without data is the same as never having recieved the >> mapping in the first place. I think that it would be up to the >> implementation but it seems like a good idea so if we can't add >> it to the PROTO can we put it in the implementation guidelines? >> >> How do you propose to withdraw common properties when they are >> associated with a template rather than the Common Properties index? > > I don't ;) This is the reason why the use the Common Properties index is > a cleaner design. I think withdrawal messages should work in general for options data, so why not send an empty record with the template as scope? >> General Comments >> ================ >> I think, sections 3.1.2, 8.2 and 8.3 would be better grouped >> into a 3.2 Advanced Techniques section. >> >> I think 3.2 Per Packet Data Reduction, should be removed and >> any information that is not in section 3.1 should be added to >> to the PSAMP example. >> I think the the per-packet example is a good example of >> per flow reducing redundancy and section 11.1.1 can be removed. > See one of my previous remark about: > > 3.1 Per Flow Data Reduction...............................11 > 3.1.1 Unique Data Reduction..................................11 > 3.1.2 Multiple Data Reduction................................12 > 3.2 Per Packet Data Reduction.............................13 > > Again, it's because you know the boundary between IPFIX and PSAMP I just don't think the repetition is necessary. Per-packet is just a good example of the technique, the Per Packet section doesn't seem to add any new information. >> Labels for the figures would be better if they were centred. > Agreed. >> >> There is all sorts of extra spacing at the end of the lines. >> >> >> >> Specific Comments >> ================= >> 2. Terminology >> Tabbing is inconsistent in definition of "Selector": >> (i) the Packet Content; (ii) information derived from the packet's >> treatment at the Observation Point; (iii) any selection state that may >> be maintained by the Selection Process. >> >> 3.1.2 Multiple Data Reduction >> >> I don't think this section is explained very well. From my original >> email to Elisa and Lutz (18th Nov 2005): >> Andrew Johnson wrote: >>> Flows >>> ===== >>> Flow A: flowId 1, flowId 11, 30 packets, 6000 bytes >>> Flow B: flowID 1, flowId 12, 50 packets, 9500 bytes >>> Flow C: flowId 2, flowId 11, 60 packets, 8000 bytes >>> Flow D: flowID 2, flowId 12, 10 packets, 1500 bytes >>> >>> Options >>> ======= >>> flowId 1 - destinationIpv4address 10.0.0.1, destinationTcpPort 80 >>> flowId 1 - destinationIpv4address 10.0.0.5, destinationTcpPort 80 >>> >>> flowId 11 - sourceIpv4address 10.0.1.10, sourceTcpPort 1932 >>> flowId 12 - sourceIpv4address 10.0.1.15, sourceTcpPort 1842 >> >> >> This shows how 4 (2+2) options can be expanded to 4 combinations of >> Data Record to reduce redundancy without the need to define 4 complete >> sets of Common Properties and therefore not save any bandwidth. The >> more options you have the better this works. 20 options (10+10) would >> give you up to 100 possible pairs common properties. >> >> This isn't really made clear in the draft text, with only "flow1" >> having two indices. > I agree the examples in figure 4/5 don't show this. > Maybe a new section in section 8 "Export and Evaluation Considerations"? >> The example in 11.1.2 doesn't even have any! > Agreed. This should be corrected. >> >> While I agree that using a template that doesn't include the cpID >> is a good idea to efficiently communicate flows with not so common >> properties, however I would call this an "Advanced Technique" to be >> listed in the section I proposed earlier. >> >> >> 3.2 Per Packet Data Reduction >> >> The text reads: >> If filtering is applied to select a series of packets, using the PSAMP >> specifications to export per-packet information might be relatively >> inefficient if the filtered fields (the common attributes) are >> exported in every single record. >> >> However in section 6.5.2.5 (Property Match Filtering) of PSAMP-PROTO >> it is explained how the filter information MUST be sent. This is >> designed so that the selector ID will match the one from the Data >> Record (via the selectionSequenceId) and perform exactly the function >> that is being proposed here for the commonPropertiesId. > Good point. I would remove this paragraph and move to this place the one > starting with: > > An example of the per packet data reduction is the measurement of > One-Way Delay (OWD), where the exact same specific packet must be > observed at the source and destination of the path to be measured. By > subtracting ... > >> >> >> 4. Specifications for bandwidth saving information export >> >> What is being specified here that isn't true for ALL options as >> described in IPFIX-PROTO? > > What do you suggest? Well it seems that section three really explains almost the same thing 3 times. The section 4 explains most of it again (with a bit more info) another 3 times. I would prefer section 3 to simply explain the technique. Walk through how the information from a Flow is split into two parts, and then add the bit from section 4 how these two parts are exported. Using more than one CPid in a record should be part of the advanced techniques once the basics are made clear. Per packet should just be a detailed example at the end. >> I think section 3 does a better job of explaining how all this >> works. I'm really not sure what section 4 adds. > > The idea was to put the specs in section 4 while the section 3 was the > high level solution. Rereading it, I see that now, but there seems to be a fair amount of repetition. >> (Aside: figure 9 refers to Common Sroperties). > Yep. thanks. >> >> >> 6. commonPropertiesID Management >> >> The text reads: >> The commonPropertiesID values MAY be assigned sequentially, but it�s >> It seems the "it's" is using an invalid character rather than an >> apostrophe. >> >> >> 7. The Collecting Process Side >> >> The text reads: >> Like TemplateIDs the commonPropertiesIDs are generated dynamically by >> the Exporting Process. Hence a restart of the Exporting Process may >> imply a renumbering of commonProperiesIDs. >> The collector can't know if the Exporter Process restarted, this is >> why we rescoped the commonPropertiesID to the Transport Session, so >> the above text is now redundant. > > I know it's redundant, but don't you think it helps. For example, we > don't explain anywhere (if I recall correctly) that "the > commonPropertiesIDs are generated dynamically by the Exporting Process" The commonPropertiesIDs are unique within the transport session. If the session is restarted then you've lost that scope and therefore can't keep using the same commonPropertiesID mappings. I don't see why the commonPropertiesIDs have to be dynamically generated by the Exporting Process. The could be shared between several EPs or pre-calculated based in historical data from that Observation Domain. >> The text reads: >> Common Properties IDs are unique per SCTP association and per >> Observation Domain. If the Collecting Process receives a common >> Properties ID which has already been received but which has not >> previously been withdrawn (i.e. a commonPropertiesID from the same >> Exporter Observation Domain with the same Template ID received on the >> SCTP association), then the Collecting Process MUST shutdown the >> association. > This is similar to [IPFIX-PROTO] > > Template IDs are unique per SCTP association and per Observation > Domain. If the Collecting Process receives a Template which has > already been received but which has not previously been withdrawn > (i.e. a Template Record from the same Exporter Observation Domain > with the same Template ID received on the SCTP association), then the > Collecting Process MUST shutdown the association. > >> >> and: >> If the Collecting Process receives a Common Properties Withdrawal >> message for a Common Properties that it has not received before on >> this SCTP assocation, it MUST reset the SCTP association, discard the >> IPFIX Message, and SHOULD log the error as it does for malformed IPFIX >> Messages. >> I think this might go against IPFIX-PROTO. > This is similar to [IPFIX-PROTO] These are similar to what IPFIX-PROTO says about templates, but that doesn't mean the text can just be used to talk about Data Records sent for Options Templates. Option data withdrawal messages are not mentioned in IPFIX-PROTO, although I think they can work. However, in general options data with the same scope as an earlier record will just overwrite the older record. > If the Collecting Process receives a Template Withdraw message for a > Template Record it has not received before on this SCTP assocation, > it MUST reset the SCTP association, discard the IPFIX Message, and > SHOULD log the error as it does for malformed IPFIX Messages. >> >> >> The text reads: >> If the Common Properties are not refreshed before that lifetime has >> expired, the Collecting Process MUST discard the corresponding >> definition of the commonPropertiesID and any current and future >> associated Data Records. In which case, an alarm MUST be logged. >> What happened to storing it until the option turned up. Furthermore >> you shouldn't dictate the the record is discarded, just because you >> can't tell a piece of potentially trivial information about a flow >> doesn't mean it's meaningless. The Common Properties in question >> could be anything. >> > This is similar to [IPFIX-PROTO] > > If the Template (or other definition) is not refreshed before that > lifetime has expired, the Collecting Process MUST discard that > definition and any current and future associated Data Records. In > which case, an alarm MUST be logged. This "(or other definition)" stuff is only mentioned for the Collecting Process and it really isn't clear if it should apply to Common Properties. However, storing the data records in a queue awaiting the decode information is really only something that is expected to be done at the start of the session. Is it mentioned in this draft? >> Besides, we're not changing the protocol here, right? > Right. So this is not an IPFIX redundancy reduction issue but an IPFIX > protocol issue... as we don't want to change the protocol with this draft. What's a protocol issue? I think applying all the requirements of templates to all options is changing the protocol. >> 8.1 Transport Protocol Choice The text reads: >> The proposed method is most effective using a reliable transport >> protocol for the transfer of the Common Properties. Therefore the use >> of SCTP or TCP is recommended. >> >> Note that SCTP isn't necessarily reliable. > SCTP -> PR-SCTP with the reliable mode >> >> >> 8.3 commonPropertiesID vs. TemplateID scope >> Additional flow properties can be tied to almost any I.E. For example >> a particular interface could be associated with the one IP address it >> serves. > That's true but I still think the design is cleaner with the Common > Properties Id. > See the remark about the Common Properties ID withdrawal You can withdraw any option record, so I don't think it's a big deal. >> 8.4 Efficiency Gain >> The text reads: >> "...it can�t predict whether future..." >> >> Weird apostrophe character again. >> >> >> >> Examples: >> >> 1. There is no padding between records, it's against IPFIX-PROTO, >> unless you use the special padding I.E. >> 2. The templates define the counts as 4 octets but the records show >> them as 2. >> 3. Since 11.1.1 and 11.2 don't demonstrate anything different, can >> we have just one example? >> 4. The tabbing is sometimes a little of on the run though of the I.E.s, >> and I think we can loose the commas. e.g. >> >> OLD >> - the source IPv4 Address, sourceIPv4Address [IPFIX-INFO], with a type >> of 8 and a length of 4 octets >> NEW >> - the source IPv4 Address: sourceIPv4Address [IPFIX-INFO] with a type >> of 8 and a length of 4 octets >> >> >> 5. What is a packet ID anyway? In general PSAMP uses sampling to gather >> detailed information about a small proportion of the network traffic. >> In most cases there won't be many common factors between the reports. >> The real exception is hash-based filtering, which is what I think the >> example uses. >> >> >> 6. Do we have to use enterprise specific things here? What about: >> observationTimeMilliseconds (323), >> digestHashValue (326), >> ipTotalLength (224) >> > Regards, Benoit. Regards Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Dec 06 05:59:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruTQ-0007oN-9x; Wed, 06 Dec 2006 05:58:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruTP-0007o2-IG for ipfix@ietf.org; Wed, 06 Dec 2006 05:57:59 -0500 Received: from gatekeeper.hitachi-eu.com ([194.36.128.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GruTK-0004ks-Bm for ipfix@ietf.org; Wed, 06 Dec 2006 05:57:59 -0500 X-ASG-Debug-ID: 1165402672-457a004b0000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: primary.hitachi-eu.net[193.39.225.234] X-Barracuda-Start-Time: 1165402672 X-ASG-Whitelist: Client Received: from mhd-esafe-int.hitachi-eu.com (primary.hitachi-eu.net [193.39.225.234]) by gatekeeper.hitachi-eu.com (Spam Firewall) with SMTP id E1A2847463 for <ipfix@ietf.org>; Wed, 6 Dec 2006 10:57:52 +0000 (GMT) Received: from MHDEXC99.adhel.hitachi-eu.com ([IP=193.39.227.52]) by eSafe SMTP Relay 1165163447; Wed Dec 6 10:57:52 2006 Received: from mhdexc02.adhel.hitachi-eu.com ([193.39.227.51]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 10:57:51 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [IPFIX] WG last call ondraft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Subject: Re: [IPFIX] WG last call ondraft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Date: Wed, 6 Dec 2006 10:57:50 -0000 Message-ID: <3167F18F59B81B4888A4D4C0A1717DD6670F97@mhdexc02.adhel.hitachi-eu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] WG last call ondraft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Thread-Index: AccZJD3++1fjKdl7R6+cUKcYX45Wzg== From: "Boschi, Elisa" <Elisa.Boschi@Hitachi-eu.com> To: <andrjohn@cisco.com> X-OriginalArrivalTime: 06 Dec 2006 10:57:51.0986 (UTC) FILETIME=[60159520:01C71925] X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 3f4d1621eb481886fab661da14b05487 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list <ipfix.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ipfix> List-Post: <mailto:ipfix@ietf.org> List-Help: <mailto:ipfix-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1640350191==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1640350191== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71925.5F1CB4BA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71925.5F1CB4BA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andrew, Benoit, all, Comments, as usual, inline... Andrew Johnson wrote: >>> Since a flow is defined as a group of packets that share >>> a set of common properties, i.e. key fields, is there >>> any danger that the commonPropertiesID will be wrongly >>> assumed to refer to only the complete set of key fields? >> >> >> By definition, I think this is impossible. The flow key=20 >> definition says "Each of the fields which are used to define=20 >> a Flow are termed Flow Keys.". So there is nothing in common=20 >> between flows. However, I understand your concern for novice readers. >> >> OLD section 1 "Introduction" >> >> Regardless of the fields content, flow records with common =20 >> properties export the same fields in every single flow record. =20 >> These common properties may represent values common to a collection=20 >> of flows or packets, or values that are invariant over time.=20 >> The reduction of redundant data from the export stream can result=20 >> in a significant reduction of the transferred data. >> >> NEW section 1 "Introduction" >> >> Regardless of the fields content, flow records with common properties=20 >> export the same fields in every single flow record. =20 >> These common properties may represent values common to a collection=20 >> of flows or packets, or values that are invariant over time. =20 >> Note that the common properties don't represent the list of flow keys,= =20 >> which are used to define a flow definition: however, the common=20 >> properties may contain some of the flow keys. The reduction of redunda= nt=20 >> data from the export stream can result in a significant reduction of=20 >> the transferred data. > > > My concern wasn't really directed at the draft itself, but just the=20 > name "common properties". =20 > From IPFIX-PROTO: > "A Flow is defined as a set of IP packets passing an Observation =20 > Point in the network during a certain time interval. All packets =20 > belonging to a particular Flow have a set of common properties." > > And then from IPFIX-INFO: > Description of commonPropertiesId: > An identifier of a set of common properties that is unique per > Observation Domain. Typically, this Information Element is used > to link to information reported in separate records. > > The terminology is almost identical. The commonPropertiesId refers > to "a set of common properties" that is quite different from ones > that determine a Flow. so maybe the text proposed by Benoit helps clarifying things. I agree wit= h adding it > >>> Is there any need to define a new term for "Specific >>> Properties"? These are just part of a normal Data Record. >>> For example: >>> "... The rows are then referenced by the Specific Properties >>> by using the appropriate value for the Common Properties >>> identifier." >>> >>> could simply be: >>> "... The rows are then referenced by Data Records by >>> using the appropriate value for the Common Properties >>> identifier." >> >> >> In your example, the "Data Records" doesn't mean the full data=20 >> records before applying the redundancy reduction mechanism but only a = part of it. >> So it might be confusing... That's the trick we found. > The Specific Properties are "what is left" of the Data Record when the Co= mmon Properties have been defined. In your example above using Data Recor= ds is wrong... Using the term Specific Properties seems clearer... (and i= t seemed intuitive after the term Common Properties had been used) >>> >>> >>> How do you propose to withdraw common properties when they are >>> associated with a template rather than the Common Properties index? >> >> >> I don't ;) This is the reason why the use the Common Properties index = is a cleaner design. > > > I think withdrawal messages should work in general for options > data, so why not send an empty record with the template as scope? yes we should add a sentence on that. Maybe in 8.3 (CommonProertiesID vs.= TemplatedID scope). Something like: Note that, if templateIDs are used, and similarly to commonPropertiesID m= anagement, templateIDs that are not used anymore SHOULD be withdrawn. The= withdrawal message is an Option Data Record consisting of only one scope= field namely the templateID to be withdrawn =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID =3D 3 | Length =3D 14 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID N | Field Count =3D 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field count =3D 1 |0| templateID =3D X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Field Length =3D 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Figure 12: templateID Withdrawal Message >>> General Comments >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> I think, sections 3.1.2, 8.2 and 8.3 would be better grouped >>> into a 3.2 Advanced Techniques section. > I am not sure I would call 8.2 and 8.3 advanced techniques... they really= seem more an evaluation thing... Like recommending using reduced size en= coding for commonPropertiesId whenever possible for increased data reduct= ion(in 8.2) >>> >>> I think 3.2 Per Packet Data Reduction, should be removed and >>> any information that is not in section 3.1 should be added to >>> to the PSAMP example. >>> I think the the per-packet example is a good example of >>> per flow reducing redundancy and section 11.1.1 can be removed. >> >> See one of my previous remark about: >> >> 3.1 Per Flow Data Reduction...............................11 >> 3.1.1 Unique Data Reduction..................................11 >> 3.1.2 Multiple Data Reduction................................12 >> 3.2 Per Packet Data Reduction.............................13 >> >> Again, it's because you know the boundary between IPFIX and PSAMP > > > I just don't think the repetition is necessary. Per-packet is > just a good example of the technique, the Per Packet section > doesn't seem to add any new information.=20 see my proposal below > >>> 3.1.2 Multiple Data Reduction >>> >>> I don't think this section is explained very well. From my original >>> email to Elisa and Lutz (18th Nov 2005): >>> Andrew Johnson wrote: >>> >>>> Flows >>>> =3D=3D=3D=3D=3D >>>> Flow A: flowId 1, flowId 11, 30 packets, 6000 bytes >>>> Flow B: flowID 1, flowId 12, 50 packets, 9500 bytes >>>> Flow C: flowId 2, flowId 11, 60 packets, 8000 bytes >>>> Flow D: flowID 2, flowId 12, 10 packets, 1500 bytes >>>> >>>> Options >>>> =3D=3D=3D=3D=3D=3D=3D >>>> flowId 1 - destinationIpv4address 10.0.0.1, destinationTcpPort 80 >>>> flowId 1 - destinationIpv4address 10.0.0.5, destinationTcpPort 80 >>>> >>>> flowId 11 - sourceIpv4address 10.0.1.10, sourceTcpPort 1932 >>>> flowId 12 - sourceIpv4address 10.0.1.15, sourceTcpPort 1842 >>> >>> >>> This shows how 4 (2+2) options can be expanded to 4 combinations of >>> Data Record to reduce redundancy without the need to define 4 complet= e >>> sets of Common Properties and therefore not save any bandwidth. The >>> more options you have the better this works. 20 options (10+10) would >>> give you up to 100 possible pairs common properties. >>> >>> This isn't really made clear in the draft text, with only "flow1" >>> having two indices. >> >> I agree the examples in figure 4/5 don't show this. >> Maybe a new section in section 8 "Export and Evaluation Considerations= "? > Agreed. But I think it should be addressed in section 3 >>> The example in 11.1.2 doesn't even have any! >> >> Agreed. This should be corrected. >> >>> >>> While I agree that using a template that doesn't include the cpID >>> is a good idea to efficiently communicate flows with not so common >>> properties, however I would call this an "Advanced Technique" to be >>> listed in the section I proposed earlier. > do you mean using the templateID instead of the CommonPopertiesID? >>> >>> >>> 3.2 Per Packet Data Reduction >>> >>> The text reads: >>> If filtering is applied to select a series of packets, using the PSAM= P specifications to export per-packet information might be relatively ine= fficient if the filtered fields (the common attributes) are exported in e= very single record. >>> >>> However in section 6.5.2.5 (Property Match Filtering) of PSAMP-PROTO >>> it is explained how the filter information MUST be sent. This is >>> designed so that the selector ID will match the one from the Data >>> Record (via the selectionSequenceId) and perform exactly the function >>> that is being proposed here for the commonPropertiesId. >> >> Good point. I would remove this paragraph and move to this place the=20 >> one starting with: >> >> An example of the per packet data reduction is the measurement of =20 >> One-Way Delay (OWD), where the exact same specific packet must be =20 >> observed at the source and destination of the path to be measured. =20 >> By subtracting ... > Remember that section 3 explains the general solution...It doesn't seem t= o be a good idea to have in the general specification just the descriptio= n of one example application, such as OWD. See my proposal below >>> >>> 4. Specifications for bandwidth saving information export >>> >>> What is being specified here that isn't true for ALL options as >>> described in IPFIX-PROTO? >> >> >> What do you suggest? > > > Well it seems that section three really explains almost the same > thing 3 times. The section 4 explains most of it again (with a > bit more info) another 3 times. > I would prefer section 3 to simply explain the technique. Walk > through how the information from a Flow is split into two parts, > and then add the bit from section 4 how these two parts are > exported. > > Using more than one CPid in a record should be part of the > advanced techniques once the basics are made clear. Per packet > should just be a detailed example at the end. I propose the following change: section three is split in just two sections: uique data reduction and mul= tiple data reduction. In the introductory part of section three we write = something like: The PSAMP specifications are used for the export of per-packet informatio= n, exporting the specific observed packet in an IPFIX Flow Record. This = can be considered as a special Flow Record case, composed of a single pac= ket. Therefore, the method described in this document is applicable to pe= r packet data reduction, e.g. for export of One Way Delay (OWD) measureme= nts (see Appendix), trajectory sampling, etc. The text on OWD can be moved to the Appendix, where we describe in detail= the OWD example. Regards, Elisa *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* ------_=_NextPart_001_01C71925.5F1CB4BA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-885= 9-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7233.6= 9"> <TITLE>Re: [IPFIX] WG last call ondraft-ietf-ipfix-reducing-redundancy-01= =2Etxt until December 1st

Andrew, Benoit, all,

Comments, as usual, inline...

Andrew Johnson wrote:

>>> Since a flow is defined as a group of packets that share
>>> a set of common properties, i.e. key fields, is there
>>> any danger that the commonPropertiesID will be wrongly
>>> assumed to refer to only the complete set of key fields?
>>
>>
>> By definition, I think this is impossible. The flow key
>> definition says "Each of the fields which are used to defin= e
>> a Flow are termed Flow Keys.". So there is nothing in commo= n
>> between flows. However, I understand your concern for novice rea= ders.
>>
>> OLD section 1 "Introduction"
>>
>> Regardless of the fields content, flow records with common =
>> properties export the same fields in every single flow record.&n= bsp;
>> These common properties may represent values common to a collect= ion
>> of flows or packets, or values that are invariant over time.
>> The reduction of redundant data from the export stream can resul= t
>> in a significant reduction of the transferred data.
>>
>> NEW section 1 "Introduction"
>>
>> Regardless of the fields content, flow records with common prope= rties
>> export the same fields in every single flow record. 
>> These common properties may represent values common to a collect= ion
>> of flows or packets, or values that are invariant over time.&nbs= p;
>> Note that the common properties don't represent the list of flow= keys,
>> which are used to define a flow definition: however, the common<= BR> >> properties may contain some of the flow keys. The reduction of r= edundant
>> data from the export stream can result in a significant reductio= n of
>> the transferred data.
>
>
> My concern wasn't really directed at the draft itself, but just the<= BR> > name "common properties". 
> From IPFIX-PROTO:
>  "A Flow is defined as a set of IP packets passing an Obse= rvation  
> Point in the network during a certain time interval.  All packe= ts  
> belonging to a particular Flow have a set of common properties."= ;
>
> And then from IPFIX-INFO:
>   Description of commonPropertiesId:
>      An identifier of a set of common prope= rties that is unique per
>      Observation Domain.  Typically, t= his Information Element is used
>      to link to information reported in sep= arate records.
>
> The terminology is almost identical.  The commonPropertiesId re= fers
> to "a set of common properties" that is quite different fr= om ones
> that determine a Flow.


so maybe the text proposed by Benoit helps clarifying things. I agree wit= h adding it


>
>>> Is there any need to define a new term for "Specific >>> Properties"? These are just part of a normal Data Recor= d.
>>> For example:
>>> "... The rows are then referenced by the Specific Prope= rties
>>> by using the appropriate value for the Common Properties
>>> identifier."
>>>
>>> could simply be:
>>> "... The rows are then referenced by Data Records by >>> using the appropriate value for the Common Properties
>>> identifier."
>>
>>
>> In your example, the "Data Records" doesn't mean the f= ull data
>> records before applying the redundancy reduction mechanism but o= nly a part of it.
>> So it might be confusing... That's the trick we found.
>

The Specific Properties are "what is left" of the Data Record w= hen the Common Properties have been defined. In your example above using = Data Records is wrong... Using the term Specific Properties seems clearer= =2E.. (and it seemed intuitive after the term Common Properties had been = used)

>>>
>>>
>>> How do you propose to withdraw common properties when they a= re
>>> associated with a template rather than the Common Properties= index?
>>
>>
>> I don't ;) This is the reason why the use the Common Properties = index is a cleaner design.
>
>
> I think withdrawal messages should work in general for options
> data, so why not send an empty record with the template as scope?

yes we should add a sentence on that. Maybe in 8.3 (CommonProertiesID vs.= TemplatedID scope). Something like:

Note that, if templateIDs are used, and similarly to commonPropertiesID m= anagement, templateIDs that are not used anymore SHOULD be withdrawn. The= withdrawal message is an Option Data Record consisting of only one scope= field namely the templateID to be withdrawn

0            =        1      = ;            = 2            = ;       3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Set ID =3D 3  = ;          |  &nbs= p;   Length =3D 14 octets       |=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Template ID N   &nbs= p;       |     &nb= sp; Field Count =3D 1         | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Scope Field count =3D 1   = |0|     templateID =3D  X   &nbs= p;     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Scope 1 Field Length =3D 8     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 12: templateID Withdrawal Message


>>> General Comments
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> I think, sections 3.1.2, 8.2 and 8.3 would be better grouped=
>>> into a 3.2 Advanced Techniques section.
>


I am not sure I would call 8.2 and 8.3 advanced techniques... they really= seem more an evaluation thing... Like recommending using reduced size en= coding for commonPropertiesId whenever possible for increased data reduct= ion(in 8.2)


>>>
>>> I think 3.2 Per Packet Data Reduction, should be removed and=
>>> any information that is not in section 3.1 should be added t= o
>>> to the PSAMP example.
>>> I think the the per-packet example is a good example of
>>> per flow reducing redundancy and section 11.1.1 can be remov= ed.
>>
>> See one of my previous remark about:
>>
>>  3.1    Per Flow Data Reduction.............= =2E.................11
>>  3.1.1 Unique Data Reduction...............................= =2E..11
>>  3.1.2 Multiple Data Reduction.............................= =2E..12
>>  3.2    Per Packet Data Reduction...........= =2E.................13
>>
>> Again, it's because you know the boundary between IPFIX and PSAM= P
>
>
> I just don't think the repetition is necessary.  Per-packet is<= BR> > just a good example of the technique, the Per Packet section
> doesn't seem to add any new information.


see my proposal below

>
>>> 3.1.2 Multiple Data Reduction
>>>
>>> I don't think this section is explained very well. From my o= riginal
>>> email to Elisa and Lutz (18th Nov 2005):
>>> Andrew Johnson wrote:
>>>
>>>> Flows
>>>> =3D=3D=3D=3D=3D
>>>> Flow A: flowId 1, flowId 11, 30 packets, 6000 bytes
>>>> Flow B: flowID 1, flowId 12, 50 packets, 9500 bytes
>>>> Flow C: flowId 2, flowId 11, 60 packets, 8000 bytes
>>>> Flow D: flowID 2, flowId 12, 10 packets, 1500 bytes
>>>>
>>>> Options
>>>> =3D=3D=3D=3D=3D=3D=3D
>>>> flowId 1 - destinationIpv4address 10.0.0.1, destinationT= cpPort 80
>>>> flowId 1 - destinationIpv4address 10.0.0.5, destinationT= cpPort 80
>>>>
>>>> flowId 11 - sourceIpv4address 10.0.1.10, sourceTcpPort 1= 932
>>>> flowId 12 - sourceIpv4address 10.0.1.15, sourceTcpPort 1= 842
>>>
>>>
>>> This shows how 4 (2+2) options can be expanded to 4 combinat= ions of
>>> Data Record to reduce redundancy without the need to define = 4 complete
>>> sets of Common Properties and therefore not save any bandwid= th. The
>>> more options you have the better this works. 20 options (10+= 10) would
>>> give you up to 100 possible pairs common properties.
>>>
>>> This isn't really made clear in the draft text, with only &q= uot;flow1"
>>> having two indices.
>>
>> I agree the examples in figure 4/5 don't show this.
>> Maybe a new section in section 8 "Export and Evaluation Con= siderations"?
>


Agreed. But I think it should be addressed in section 3


>>> The example in 11.1.2 doesn't even have any!
>>
>> Agreed. This should be corrected.
>>
>>>
>>> While I agree that using a template that doesn't include the= cpID
>>> is a good idea to efficiently communicate flows with not so = common
>>> properties, however I would call this an "Advanced Tech= nique" to be
>>> listed in the section I proposed earlier.
>

do you mean using the templateID instead of the CommonPopertiesID?

>>>
>>>
>>> 3.2 Per Packet Data Reduction
>>>
>>> The text reads:
>>> If filtering is applied to select a series of packets, using= the PSAMP specifications to export per-packet information might be relat= ively inefficient if the filtered fields (the common attributes) are expo= rted in every single record.
>>>
>>> However in section 6.5.2.5 (Property Match Filtering) of PSA= MP-PROTO
>>> it is explained how the filter information MUST be sent. Thi= s is
>>> designed so that the selector ID will match the one from the= Data
>>> Record (via the selectionSequenceId) and perform exactly the= function
>>> that is being proposed here for the commonPropertiesId.
>>
>> Good point. I would remove this paragraph and move to this place= the
>> one starting with:
>>
>>  An example of the per packet data reduction is the measure= ment of 
>> One-Way Delay (OWD), where the exact same specific packet must b= e  
>> observed at the source and destination of the path to be measure= d.  
>> By subtracting ...
>


Remember that section 3 explains the general solution...It doesn't seem t= o be a good idea to have in the general specification just the descriptio= n of one example application, such as OWD.
See my proposal below

>>>
>>> 4. Specifications for bandwidth saving information export >>>
>>> What is being specified here that isn't true for ALL options= as
>>> described in IPFIX-PROTO?
>>
>>
>> What do you suggest?
>
>
> Well it seems that section three really explains almost the same
> thing 3 times.  The section 4 explains most of it again (with a=
> bit more info) another 3 times.
> I would prefer section 3 to simply explain the technique.  Walk=
> through how the information from a Flow is split into two parts,
> and then add the bit from section 4 how these two parts are
> exported.
>
> Using more than one CPid in a record should be part of the
> advanced techniques once the basics are made clear.  Per packet=
> should just be a detailed example at the end.



I propose the following change:

section three is split in just two sections: uique data reduction and mul= tiple data reduction. In the introductory part of section three we write = something like:

The PSAMP specifications are used for the export of per-packet informatio= n, exporting the specific observed packet in an IPFIX Flow Record.  = This can be considered as a special Flow Record case, composed of a singl= e packet. Therefore, the method described in this document is applicable = to per packet data reduction, e.g. for export of One Way Delay (OWD) meas= urements (see Appendix), trajectory sampling, etc.

The text on OWD can be moved to the Appendix, where we describe in detail= the OWD example.


Regards,
Elisa
 

*************************************************************************=
*************************
=20
 E-mail Confidentiality Notice and Disclaimer.
=20
  This email and any files transmitted with it are confidential and are i=
ntended solely for=20
the use of the individual or entity to which they are addressed. Access t=
o this e-mail by=20
anyone else is unauthorised. If you are not the intended recipient, any d=
isclosure,=20
copying, distribution or any action taken or omitted to be taken in relia=
nce on it, is=20
prohibited.=20
  E-mail messages are not necessarily secure.  Hitachi does not accept re=
sponsibility=20
for any changes made to this message after it was sent.=20
  Please note that Hitachi checks outgoing e-mail messages for the presen=
ce of=20
computer viruses.

*************************************************************************=
*************************
------_=_NextPart_001_01C71925.5F1CB4BA-- --===============1640350191== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1640350191==-- From ipfix-bounces@ietf.org Wed Dec 06 05:59:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruUP-0007rv-SB; Wed, 06 Dec 2006 05:59:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruUP-0007rq-78 for ipfix@ietf.org; Wed, 06 Dec 2006 05:59:01 -0500 Received: from gatekeeper.hitachi-eu.com ([194.36.128.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GruUN-0004qP-NR for ipfix@ietf.org; Wed, 06 Dec 2006 05:59:01 -0500 X-ASG-Debug-ID: 1165402739-456b00530000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: primary.hitachi-eu.net[193.39.225.234] X-Barracuda-Start-Time: 1165402739 X-ASG-Whitelist: Client Received: from mhd-esafe-int.hitachi-eu.com (primary.hitachi-eu.net [193.39.225.234]) by gatekeeper.hitachi-eu.com (Spam Firewall) with SMTP id 00DA347634 for ; Wed, 6 Dec 2006 10:58:59 +0000 (GMT) Received: from MHDEXC99.adhel.hitachi-eu.com ([IP=193.39.227.52]) by eSafe SMTP Relay 1165163447; Wed Dec 6 10:58:58 2006 Received: from mhdexc02.adhel.hitachi-eu.com ([193.39.227.51]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 10:58:58 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [IPFIX] An advanced for Reducing Redundancy Subject: Re: [IPFIX] An advanced for Reducing Redundancy Date: Wed, 6 Dec 2006 10:58:28 -0000 Message-ID: <3167F18F59B81B4888A4D4C0A1717DD6670F98@mhdexc02.adhel.hitachi-eu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] An advanced for Reducing Redundancy Thread-Index: AccZJXXtle8avAFwQ9KDju/VABTsgw== From: "Boschi, Elisa" To: X-OriginalArrivalTime: 06 Dec 2006 10:58:58.0486 (UTC) FILETIME=[87B8AD60:01C71925] X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1197022142==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1197022142== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71925.87690309" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71925.87690309 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul, Andrew, >> One more that might be a bit obtuse. The technique for >> defining separate cpIds for source and destination Common >> Properties is mentioned in the draft. For common combinations >> a third category of cpId could be used which maps to two other >> cpIds. >> >> i.e.: >> cpID C -> cpID A + cpID B >> cpID A -> source address A, source port A >> cpID B -> destination address B, source port B > > > Which raises the question of what duplicate cpID means, eg: > > cpID D -> cpID C + cpID A > > > Also, we need to be careful to avoid circular definitions, eg: > > cpID E -> cpID F [ + cpID ... ] > cpID F -> cpID E [ + cpID ... ] > > > Probably an exporter SHOULD NOT send these, and a collector MUST detect= and discard them, and log. > Agree, but I propose a SHOULD instead of a MUST: "An Exporter SHOULD NOT send Common Properties defined in terms of other = Common Properties (i.e. when one of the properties is a CommonPropertiesI= D), and a Collector SHOULD detect and discard them and log." Regards, Elisa *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* ------_=_NextPart_001_01C71925.87690309 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [IPFIX] An advanced for Reducing Redundancy

Paul, Andrew,

>> One more that might be a bit obtuse.  The technique for
>> defining separate cpIds for source and destination Common
>> Properties is mentioned in the draft.  For common combinati= ons
>> a third category of cpId could be used which maps to two other >> cpIds.
>>
>> i.e.:
>>  cpID C -> cpID A + cpID B
>>  cpID A -> source address A, source port A
>>  cpID B -> destination address B, source port B
>
>
> Which raises the question of what duplicate cpID means, eg:
>
>   cpID D -> cpID C + cpID A
>
>
> Also, we need to be careful to avoid circular definitions, eg:
>
>   cpID E -> cpID F [ + cpID ... ]
>   cpID F -> cpID E [ + cpID ... ]
>
>
> Probably an exporter SHOULD NOT send these, and a collector MUST det= ect and discard them, and log.
>
Agree, but I propose a SHOULD instead of a MUST:

"An Exporter SHOULD NOT send Common Properties defined in terms of o= ther Common Properties (i.e. when one of the properties is a CommonProper= tiesID), and a Collector SHOULD detect and discard them and log."


Regards,
Elisa

 

*************************************************************************=
*************************
=20
 E-mail Confidentiality Notice and Disclaimer.
=20
  This email and any files transmitted with it are confidential and are i=
ntended solely for=20
the use of the individual or entity to which they are addressed. Access t=
o this e-mail by=20
anyone else is unauthorised. If you are not the intended recipient, any d=
isclosure,=20
copying, distribution or any action taken or omitted to be taken in relia=
nce on it, is=20
prohibited.=20
  E-mail messages are not necessarily secure.  Hitachi does not accept re=
sponsibility=20
for any changes made to this message after it was sent.=20
  Please note that Hitachi checks outgoing e-mail messages for the presen=
ce of=20
computer viruses.

*************************************************************************=
*************************
------_=_NextPart_001_01C71925.87690309-- --===============1197022142== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1197022142==-- From ipfix-bounces@ietf.org Wed Dec 06 05:59:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruTQ-0007oN-9x; Wed, 06 Dec 2006 05:58:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruTP-0007o2-IG for ipfix@ietf.org; Wed, 06 Dec 2006 05:57:59 -0500 Received: from gatekeeper.hitachi-eu.com ([194.36.128.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GruTK-0004ks-Bm for ipfix@ietf.org; Wed, 06 Dec 2006 05:57:59 -0500 X-ASG-Debug-ID: 1165402672-457a004b0000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: primary.hitachi-eu.net[193.39.225.234] X-Barracuda-Start-Time: 1165402672 X-ASG-Whitelist: Client Received: from mhd-esafe-int.hitachi-eu.com (primary.hitachi-eu.net [193.39.225.234]) by gatekeeper.hitachi-eu.com (Spam Firewall) with SMTP id E1A2847463 for ; Wed, 6 Dec 2006 10:57:52 +0000 (GMT) Received: from MHDEXC99.adhel.hitachi-eu.com ([IP=193.39.227.52]) by eSafe SMTP Relay 1165163447; Wed Dec 6 10:57:52 2006 Received: from mhdexc02.adhel.hitachi-eu.com ([193.39.227.51]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 10:57:51 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [IPFIX] WG last call ondraft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Subject: Re: [IPFIX] WG last call ondraft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Date: Wed, 6 Dec 2006 10:57:50 -0000 Message-ID: <3167F18F59B81B4888A4D4C0A1717DD6670F97@mhdexc02.adhel.hitachi-eu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] WG last call ondraft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Thread-Index: AccZJD3++1fjKdl7R6+cUKcYX45Wzg== From: "Boschi, Elisa" To: X-OriginalArrivalTime: 06 Dec 2006 10:57:51.0986 (UTC) FILETIME=[60159520:01C71925] X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 3f4d1621eb481886fab661da14b05487 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1640350191==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1640350191== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71925.5F1CB4BA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71925.5F1CB4BA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andrew, Benoit, all, Comments, as usual, inline... Andrew Johnson wrote: >>> Since a flow is defined as a group of packets that share >>> a set of common properties, i.e. key fields, is there >>> any danger that the commonPropertiesID will be wrongly >>> assumed to refer to only the complete set of key fields? >> >> >> By definition, I think this is impossible. The flow key=20 >> definition says "Each of the fields which are used to define=20 >> a Flow are termed Flow Keys.". So there is nothing in common=20 >> between flows. However, I understand your concern for novice readers. >> >> OLD section 1 "Introduction" >> >> Regardless of the fields content, flow records with common =20 >> properties export the same fields in every single flow record. =20 >> These common properties may represent values common to a collection=20 >> of flows or packets, or values that are invariant over time.=20 >> The reduction of redundant data from the export stream can result=20 >> in a significant reduction of the transferred data. >> >> NEW section 1 "Introduction" >> >> Regardless of the fields content, flow records with common properties=20 >> export the same fields in every single flow record. =20 >> These common properties may represent values common to a collection=20 >> of flows or packets, or values that are invariant over time. =20 >> Note that the common properties don't represent the list of flow keys,= =20 >> which are used to define a flow definition: however, the common=20 >> properties may contain some of the flow keys. The reduction of redunda= nt=20 >> data from the export stream can result in a significant reduction of=20 >> the transferred data. > > > My concern wasn't really directed at the draft itself, but just the=20 > name "common properties". =20 > From IPFIX-PROTO: > "A Flow is defined as a set of IP packets passing an Observation =20 > Point in the network during a certain time interval. All packets =20 > belonging to a particular Flow have a set of common properties." > > And then from IPFIX-INFO: > Description of commonPropertiesId: > An identifier of a set of common properties that is unique per > Observation Domain. Typically, this Information Element is used > to link to information reported in separate records. > > The terminology is almost identical. The commonPropertiesId refers > to "a set of common properties" that is quite different from ones > that determine a Flow. so maybe the text proposed by Benoit helps clarifying things. I agree wit= h adding it > >>> Is there any need to define a new term for "Specific >>> Properties"? These are just part of a normal Data Record. >>> For example: >>> "... The rows are then referenced by the Specific Properties >>> by using the appropriate value for the Common Properties >>> identifier." >>> >>> could simply be: >>> "... The rows are then referenced by Data Records by >>> using the appropriate value for the Common Properties >>> identifier." >> >> >> In your example, the "Data Records" doesn't mean the full data=20 >> records before applying the redundancy reduction mechanism but only a = part of it. >> So it might be confusing... That's the trick we found. > The Specific Properties are "what is left" of the Data Record when the Co= mmon Properties have been defined. In your example above using Data Recor= ds is wrong... Using the term Specific Properties seems clearer... (and i= t seemed intuitive after the term Common Properties had been used) >>> >>> >>> How do you propose to withdraw common properties when they are >>> associated with a template rather than the Common Properties index? >> >> >> I don't ;) This is the reason why the use the Common Properties index = is a cleaner design. > > > I think withdrawal messages should work in general for options > data, so why not send an empty record with the template as scope? yes we should add a sentence on that. Maybe in 8.3 (CommonProertiesID vs.= TemplatedID scope). Something like: Note that, if templateIDs are used, and similarly to commonPropertiesID m= anagement, templateIDs that are not used anymore SHOULD be withdrawn. The= withdrawal message is an Option Data Record consisting of only one scope= field namely the templateID to be withdrawn =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID =3D 3 | Length =3D 14 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID N | Field Count =3D 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field count =3D 1 |0| templateID =3D X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Field Length =3D 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Figure 12: templateID Withdrawal Message >>> General Comments >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> I think, sections 3.1.2, 8.2 and 8.3 would be better grouped >>> into a 3.2 Advanced Techniques section. > I am not sure I would call 8.2 and 8.3 advanced techniques... they really= seem more an evaluation thing... Like recommending using reduced size en= coding for commonPropertiesId whenever possible for increased data reduct= ion(in 8.2) >>> >>> I think 3.2 Per Packet Data Reduction, should be removed and >>> any information that is not in section 3.1 should be added to >>> to the PSAMP example. >>> I think the the per-packet example is a good example of >>> per flow reducing redundancy and section 11.1.1 can be removed. >> >> See one of my previous remark about: >> >> 3.1 Per Flow Data Reduction...............................11 >> 3.1.1 Unique Data Reduction..................................11 >> 3.1.2 Multiple Data Reduction................................12 >> 3.2 Per Packet Data Reduction.............................13 >> >> Again, it's because you know the boundary between IPFIX and PSAMP > > > I just don't think the repetition is necessary. Per-packet is > just a good example of the technique, the Per Packet section > doesn't seem to add any new information.=20 see my proposal below > >>> 3.1.2 Multiple Data Reduction >>> >>> I don't think this section is explained very well. From my original >>> email to Elisa and Lutz (18th Nov 2005): >>> Andrew Johnson wrote: >>> >>>> Flows >>>> =3D=3D=3D=3D=3D >>>> Flow A: flowId 1, flowId 11, 30 packets, 6000 bytes >>>> Flow B: flowID 1, flowId 12, 50 packets, 9500 bytes >>>> Flow C: flowId 2, flowId 11, 60 packets, 8000 bytes >>>> Flow D: flowID 2, flowId 12, 10 packets, 1500 bytes >>>> >>>> Options >>>> =3D=3D=3D=3D=3D=3D=3D >>>> flowId 1 - destinationIpv4address 10.0.0.1, destinationTcpPort 80 >>>> flowId 1 - destinationIpv4address 10.0.0.5, destinationTcpPort 80 >>>> >>>> flowId 11 - sourceIpv4address 10.0.1.10, sourceTcpPort 1932 >>>> flowId 12 - sourceIpv4address 10.0.1.15, sourceTcpPort 1842 >>> >>> >>> This shows how 4 (2+2) options can be expanded to 4 combinations of >>> Data Record to reduce redundancy without the need to define 4 complet= e >>> sets of Common Properties and therefore not save any bandwidth. The >>> more options you have the better this works. 20 options (10+10) would >>> give you up to 100 possible pairs common properties. >>> >>> This isn't really made clear in the draft text, with only "flow1" >>> having two indices. >> >> I agree the examples in figure 4/5 don't show this. >> Maybe a new section in section 8 "Export and Evaluation Considerations= "? > Agreed. But I think it should be addressed in section 3 >>> The example in 11.1.2 doesn't even have any! >> >> Agreed. This should be corrected. >> >>> >>> While I agree that using a template that doesn't include the cpID >>> is a good idea to efficiently communicate flows with not so common >>> properties, however I would call this an "Advanced Technique" to be >>> listed in the section I proposed earlier. > do you mean using the templateID instead of the CommonPopertiesID? >>> >>> >>> 3.2 Per Packet Data Reduction >>> >>> The text reads: >>> If filtering is applied to select a series of packets, using the PSAM= P specifications to export per-packet information might be relatively ine= fficient if the filtered fields (the common attributes) are exported in e= very single record. >>> >>> However in section 6.5.2.5 (Property Match Filtering) of PSAMP-PROTO >>> it is explained how the filter information MUST be sent. This is >>> designed so that the selector ID will match the one from the Data >>> Record (via the selectionSequenceId) and perform exactly the function >>> that is being proposed here for the commonPropertiesId. >> >> Good point. I would remove this paragraph and move to this place the=20 >> one starting with: >> >> An example of the per packet data reduction is the measurement of =20 >> One-Way Delay (OWD), where the exact same specific packet must be =20 >> observed at the source and destination of the path to be measured. =20 >> By subtracting ... > Remember that section 3 explains the general solution...It doesn't seem t= o be a good idea to have in the general specification just the descriptio= n of one example application, such as OWD. See my proposal below >>> >>> 4. Specifications for bandwidth saving information export >>> >>> What is being specified here that isn't true for ALL options as >>> described in IPFIX-PROTO? >> >> >> What do you suggest? > > > Well it seems that section three really explains almost the same > thing 3 times. The section 4 explains most of it again (with a > bit more info) another 3 times. > I would prefer section 3 to simply explain the technique. Walk > through how the information from a Flow is split into two parts, > and then add the bit from section 4 how these two parts are > exported. > > Using more than one CPid in a record should be part of the > advanced techniques once the basics are made clear. Per packet > should just be a detailed example at the end. I propose the following change: section three is split in just two sections: uique data reduction and mul= tiple data reduction. In the introductory part of section three we write = something like: The PSAMP specifications are used for the export of per-packet informatio= n, exporting the specific observed packet in an IPFIX Flow Record. This = can be considered as a special Flow Record case, composed of a single pac= ket. Therefore, the method described in this document is applicable to pe= r packet data reduction, e.g. for export of One Way Delay (OWD) measureme= nts (see Appendix), trajectory sampling, etc. The text on OWD can be moved to the Appendix, where we describe in detail= the OWD example. Regards, Elisa *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* ------_=_NextPart_001_01C71925.5F1CB4BA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [IPFIX] WG last call ondraft-ietf-ipfix-reducing-redundancy-01= =2Etxt until December 1st

Andrew, Benoit, all,

Comments, as usual, inline...

Andrew Johnson wrote:

>>> Since a flow is defined as a group of packets that share
>>> a set of common properties, i.e. key fields, is there
>>> any danger that the commonPropertiesID will be wrongly
>>> assumed to refer to only the complete set of key fields?
>>
>>
>> By definition, I think this is impossible. The flow key
>> definition says "Each of the fields which are used to defin= e
>> a Flow are termed Flow Keys.". So there is nothing in commo= n
>> between flows. However, I understand your concern for novice rea= ders.
>>
>> OLD section 1 "Introduction"
>>
>> Regardless of the fields content, flow records with common =
>> properties export the same fields in every single flow record.&n= bsp;
>> These common properties may represent values common to a collect= ion
>> of flows or packets, or values that are invariant over time.
>> The reduction of redundant data from the export stream can resul= t
>> in a significant reduction of the transferred data.
>>
>> NEW section 1 "Introduction"
>>
>> Regardless of the fields content, flow records with common prope= rties
>> export the same fields in every single flow record. 
>> These common properties may represent values common to a collect= ion
>> of flows or packets, or values that are invariant over time.&nbs= p;
>> Note that the common properties don't represent the list of flow= keys,
>> which are used to define a flow definition: however, the common<= BR> >> properties may contain some of the flow keys. The reduction of r= edundant
>> data from the export stream can result in a significant reductio= n of
>> the transferred data.
>
>
> My concern wasn't really directed at the draft itself, but just the<= BR> > name "common properties". 
> From IPFIX-PROTO:
>  "A Flow is defined as a set of IP packets passing an Obse= rvation  
> Point in the network during a certain time interval.  All packe= ts  
> belonging to a particular Flow have a set of common properties."= ;
>
> And then from IPFIX-INFO:
>   Description of commonPropertiesId:
>      An identifier of a set of common prope= rties that is unique per
>      Observation Domain.  Typically, t= his Information Element is used
>      to link to information reported in sep= arate records.
>
> The terminology is almost identical.  The commonPropertiesId re= fers
> to "a set of common properties" that is quite different fr= om ones
> that determine a Flow.


so maybe the text proposed by Benoit helps clarifying things. I agree wit= h adding it


>
>>> Is there any need to define a new term for "Specific >>> Properties"? These are just part of a normal Data Recor= d.
>>> For example:
>>> "... The rows are then referenced by the Specific Prope= rties
>>> by using the appropriate value for the Common Properties
>>> identifier."
>>>
>>> could simply be:
>>> "... The rows are then referenced by Data Records by >>> using the appropriate value for the Common Properties
>>> identifier."
>>
>>
>> In your example, the "Data Records" doesn't mean the f= ull data
>> records before applying the redundancy reduction mechanism but o= nly a part of it.
>> So it might be confusing... That's the trick we found.
>

The Specific Properties are "what is left" of the Data Record w= hen the Common Properties have been defined. In your example above using = Data Records is wrong... Using the term Specific Properties seems clearer= =2E.. (and it seemed intuitive after the term Common Properties had been = used)

>>>
>>>
>>> How do you propose to withdraw common properties when they a= re
>>> associated with a template rather than the Common Properties= index?
>>
>>
>> I don't ;) This is the reason why the use the Common Properties = index is a cleaner design.
>
>
> I think withdrawal messages should work in general for options
> data, so why not send an empty record with the template as scope?

yes we should add a sentence on that. Maybe in 8.3 (CommonProertiesID vs.= TemplatedID scope). Something like:

Note that, if templateIDs are used, and similarly to commonPropertiesID m= anagement, templateIDs that are not used anymore SHOULD be withdrawn. The= withdrawal message is an Option Data Record consisting of only one scope= field namely the templateID to be withdrawn

0            =        1      = ;            = 2            = ;       3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Set ID =3D 3  = ;          |  &nbs= p;   Length =3D 14 octets       |=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Template ID N   &nbs= p;       |     &nb= sp; Field Count =3D 1         | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Scope Field count =3D 1   = |0|     templateID =3D  X   &nbs= p;     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Scope 1 Field Length =3D 8     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 12: templateID Withdrawal Message


>>> General Comments
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> I think, sections 3.1.2, 8.2 and 8.3 would be better grouped=
>>> into a 3.2 Advanced Techniques section.
>


I am not sure I would call 8.2 and 8.3 advanced techniques... they really= seem more an evaluation thing... Like recommending using reduced size en= coding for commonPropertiesId whenever possible for increased data reduct= ion(in 8.2)


>>>
>>> I think 3.2 Per Packet Data Reduction, should be removed and=
>>> any information that is not in section 3.1 should be added t= o
>>> to the PSAMP example.
>>> I think the the per-packet example is a good example of
>>> per flow reducing redundancy and section 11.1.1 can be remov= ed.
>>
>> See one of my previous remark about:
>>
>>  3.1    Per Flow Data Reduction.............= =2E.................11
>>  3.1.1 Unique Data Reduction...............................= =2E..11
>>  3.1.2 Multiple Data Reduction.............................= =2E..12
>>  3.2    Per Packet Data Reduction...........= =2E.................13
>>
>> Again, it's because you know the boundary between IPFIX and PSAM= P
>
>
> I just don't think the repetition is necessary.  Per-packet is<= BR> > just a good example of the technique, the Per Packet section
> doesn't seem to add any new information.


see my proposal below

>
>>> 3.1.2 Multiple Data Reduction
>>>
>>> I don't think this section is explained very well. From my o= riginal
>>> email to Elisa and Lutz (18th Nov 2005):
>>> Andrew Johnson wrote:
>>>
>>>> Flows
>>>> =3D=3D=3D=3D=3D
>>>> Flow A: flowId 1, flowId 11, 30 packets, 6000 bytes
>>>> Flow B: flowID 1, flowId 12, 50 packets, 9500 bytes
>>>> Flow C: flowId 2, flowId 11, 60 packets, 8000 bytes
>>>> Flow D: flowID 2, flowId 12, 10 packets, 1500 bytes
>>>>
>>>> Options
>>>> =3D=3D=3D=3D=3D=3D=3D
>>>> flowId 1 - destinationIpv4address 10.0.0.1, destinationT= cpPort 80
>>>> flowId 1 - destinationIpv4address 10.0.0.5, destinationT= cpPort 80
>>>>
>>>> flowId 11 - sourceIpv4address 10.0.1.10, sourceTcpPort 1= 932
>>>> flowId 12 - sourceIpv4address 10.0.1.15, sourceTcpPort 1= 842
>>>
>>>
>>> This shows how 4 (2+2) options can be expanded to 4 combinat= ions of
>>> Data Record to reduce redundancy without the need to define = 4 complete
>>> sets of Common Properties and therefore not save any bandwid= th. The
>>> more options you have the better this works. 20 options (10+= 10) would
>>> give you up to 100 possible pairs common properties.
>>>
>>> This isn't really made clear in the draft text, with only &q= uot;flow1"
>>> having two indices.
>>
>> I agree the examples in figure 4/5 don't show this.
>> Maybe a new section in section 8 "Export and Evaluation Con= siderations"?
>


Agreed. But I think it should be addressed in section 3


>>> The example in 11.1.2 doesn't even have any!
>>
>> Agreed. This should be corrected.
>>
>>>
>>> While I agree that using a template that doesn't include the= cpID
>>> is a good idea to efficiently communicate flows with not so = common
>>> properties, however I would call this an "Advanced Tech= nique" to be
>>> listed in the section I proposed earlier.
>

do you mean using the templateID instead of the CommonPopertiesID?

>>>
>>>
>>> 3.2 Per Packet Data Reduction
>>>
>>> The text reads:
>>> If filtering is applied to select a series of packets, using= the PSAMP specifications to export per-packet information might be relat= ively inefficient if the filtered fields (the common attributes) are expo= rted in every single record.
>>>
>>> However in section 6.5.2.5 (Property Match Filtering) of PSA= MP-PROTO
>>> it is explained how the filter information MUST be sent. Thi= s is
>>> designed so that the selector ID will match the one from the= Data
>>> Record (via the selectionSequenceId) and perform exactly the= function
>>> that is being proposed here for the commonPropertiesId.
>>
>> Good point. I would remove this paragraph and move to this place= the
>> one starting with:
>>
>>  An example of the per packet data reduction is the measure= ment of 
>> One-Way Delay (OWD), where the exact same specific packet must b= e  
>> observed at the source and destination of the path to be measure= d.  
>> By subtracting ...
>


Remember that section 3 explains the general solution...It doesn't seem t= o be a good idea to have in the general specification just the descriptio= n of one example application, such as OWD.
See my proposal below

>>>
>>> 4. Specifications for bandwidth saving information export >>>
>>> What is being specified here that isn't true for ALL options= as
>>> described in IPFIX-PROTO?
>>
>>
>> What do you suggest?
>
>
> Well it seems that section three really explains almost the same
> thing 3 times.  The section 4 explains most of it again (with a=
> bit more info) another 3 times.
> I would prefer section 3 to simply explain the technique.  Walk=
> through how the information from a Flow is split into two parts,
> and then add the bit from section 4 how these two parts are
> exported.
>
> Using more than one CPid in a record should be part of the
> advanced techniques once the basics are made clear.  Per packet=
> should just be a detailed example at the end.



I propose the following change:

section three is split in just two sections: uique data reduction and mul= tiple data reduction. In the introductory part of section three we write = something like:

The PSAMP specifications are used for the export of per-packet informatio= n, exporting the specific observed packet in an IPFIX Flow Record.  = This can be considered as a special Flow Record case, composed of a singl= e packet. Therefore, the method described in this document is applicable = to per packet data reduction, e.g. for export of One Way Delay (OWD) meas= urements (see Appendix), trajectory sampling, etc.

The text on OWD can be moved to the Appendix, where we describe in detail= the OWD example.


Regards,
Elisa
 

*************************************************************************=
*************************
=20
 E-mail Confidentiality Notice and Disclaimer.
=20
  This email and any files transmitted with it are confidential and are i=
ntended solely for=20
the use of the individual or entity to which they are addressed. Access t=
o this e-mail by=20
anyone else is unauthorised. If you are not the intended recipient, any d=
isclosure,=20
copying, distribution or any action taken or omitted to be taken in relia=
nce on it, is=20
prohibited.=20
  E-mail messages are not necessarily secure.  Hitachi does not accept re=
sponsibility=20
for any changes made to this message after it was sent.=20
  Please note that Hitachi checks outgoing e-mail messages for the presen=
ce of=20
computer viruses.

*************************************************************************=
*************************
------_=_NextPart_001_01C71925.5F1CB4BA-- --===============1640350191== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1640350191==-- From ipfix-bounces@ietf.org Wed Dec 06 05:59:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruUP-0007rv-SB; Wed, 06 Dec 2006 05:59:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruUP-0007rq-78 for ipfix@ietf.org; Wed, 06 Dec 2006 05:59:01 -0500 Received: from gatekeeper.hitachi-eu.com ([194.36.128.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GruUN-0004qP-NR for ipfix@ietf.org; Wed, 06 Dec 2006 05:59:01 -0500 X-ASG-Debug-ID: 1165402739-456b00530000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: primary.hitachi-eu.net[193.39.225.234] X-Barracuda-Start-Time: 1165402739 X-ASG-Whitelist: Client Received: from mhd-esafe-int.hitachi-eu.com (primary.hitachi-eu.net [193.39.225.234]) by gatekeeper.hitachi-eu.com (Spam Firewall) with SMTP id 00DA347634 for ; Wed, 6 Dec 2006 10:58:59 +0000 (GMT) Received: from MHDEXC99.adhel.hitachi-eu.com ([IP=193.39.227.52]) by eSafe SMTP Relay 1165163447; Wed Dec 6 10:58:58 2006 Received: from mhdexc02.adhel.hitachi-eu.com ([193.39.227.51]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 10:58:58 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [IPFIX] An advanced for Reducing Redundancy Subject: Re: [IPFIX] An advanced for Reducing Redundancy Date: Wed, 6 Dec 2006 10:58:28 -0000 Message-ID: <3167F18F59B81B4888A4D4C0A1717DD6670F98@mhdexc02.adhel.hitachi-eu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] An advanced for Reducing Redundancy Thread-Index: AccZJXXtle8avAFwQ9KDju/VABTsgw== From: "Boschi, Elisa" To: X-OriginalArrivalTime: 06 Dec 2006 10:58:58.0486 (UTC) FILETIME=[87B8AD60:01C71925] X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1197022142==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1197022142== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71925.87690309" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71925.87690309 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul, Andrew, >> One more that might be a bit obtuse. The technique for >> defining separate cpIds for source and destination Common >> Properties is mentioned in the draft. For common combinations >> a third category of cpId could be used which maps to two other >> cpIds. >> >> i.e.: >> cpID C -> cpID A + cpID B >> cpID A -> source address A, source port A >> cpID B -> destination address B, source port B > > > Which raises the question of what duplicate cpID means, eg: > > cpID D -> cpID C + cpID A > > > Also, we need to be careful to avoid circular definitions, eg: > > cpID E -> cpID F [ + cpID ... ] > cpID F -> cpID E [ + cpID ... ] > > > Probably an exporter SHOULD NOT send these, and a collector MUST detect= and discard them, and log. > Agree, but I propose a SHOULD instead of a MUST: "An Exporter SHOULD NOT send Common Properties defined in terms of other = Common Properties (i.e. when one of the properties is a CommonPropertiesI= D), and a Collector SHOULD detect and discard them and log." Regards, Elisa *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* ------_=_NextPart_001_01C71925.87690309 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [IPFIX] An advanced for Reducing Redundancy

Paul, Andrew,

>> One more that might be a bit obtuse.  The technique for
>> defining separate cpIds for source and destination Common
>> Properties is mentioned in the draft.  For common combinati= ons
>> a third category of cpId could be used which maps to two other >> cpIds.
>>
>> i.e.:
>>  cpID C -> cpID A + cpID B
>>  cpID A -> source address A, source port A
>>  cpID B -> destination address B, source port B
>
>
> Which raises the question of what duplicate cpID means, eg:
>
>   cpID D -> cpID C + cpID A
>
>
> Also, we need to be careful to avoid circular definitions, eg:
>
>   cpID E -> cpID F [ + cpID ... ]
>   cpID F -> cpID E [ + cpID ... ]
>
>
> Probably an exporter SHOULD NOT send these, and a collector MUST det= ect and discard them, and log.
>
Agree, but I propose a SHOULD instead of a MUST:

"An Exporter SHOULD NOT send Common Properties defined in terms of o= ther Common Properties (i.e. when one of the properties is a CommonProper= tiesID), and a Collector SHOULD detect and discard them and log."


Regards,
Elisa

 

*************************************************************************=
*************************
=20
 E-mail Confidentiality Notice and Disclaimer.
=20
  This email and any files transmitted with it are confidential and are i=
ntended solely for=20
the use of the individual or entity to which they are addressed. Access t=
o this e-mail by=20
anyone else is unauthorised. If you are not the intended recipient, any d=
isclosure,=20
copying, distribution or any action taken or omitted to be taken in relia=
nce on it, is=20
prohibited.=20
  E-mail messages are not necessarily secure.  Hitachi does not accept re=
sponsibility=20
for any changes made to this message after it was sent.=20
  Please note that Hitachi checks outgoing e-mail messages for the presen=
ce of=20
computer viruses.

*************************************************************************=
*************************
------_=_NextPart_001_01C71925.87690309-- --===============1197022142== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1197022142==-- From ipfix-bounces@ietf.org Wed Dec 06 10:08:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GryMe-0006gV-DR; Wed, 06 Dec 2006 10:07:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GryMc-0006gC-MH for ipfix@ietf.org; Wed, 06 Dec 2006 10:07:14 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GryMa-0002Bg-Bc for ipfix@ietf.org; Wed, 06 Dec 2006 10:07:14 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Dec 2006 16:07:12 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB6F7AAs002059; Wed, 6 Dec 2006 16:07:10 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB6F7AAJ026031; Wed, 6 Dec 2006 16:07:10 +0100 (MET) Received: from [144.254.153.27] (dhcp-144-254-153-27.cisco.com [144.254.153.27]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA18544; Wed, 6 Dec 2006 15:07:09 GMT Message-ID: <4576DC9D.7090101@cisco.com> Date: Wed, 06 Dec 2006 15:07:09 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Boschi, Elisa" Subject: Re: [IPFIX] An advanced for Reducing Redundancy References: <3167F18F59B81B4888A4D4C0A1717DD6670F98@mhdexc02.adhel.hitachi-eu.com> In-Reply-To: <3167F18F59B81B4888A4D4C0A1717DD6670F98@mhdexc02.adhel.hitachi-eu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1430; t=1165417630; x=1166281630; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20An=20advanced=20for=20Reducing=20Redundancy |Sender:=20; bh=dEVz45T0EnAJjTdhRcNI9Rbrd7zVdOz6WuVBrTSgS1U=; b=EvFke99F1CfO7AVhqdnsmU3cwIhqWrylRU/Z3LaZRYdtdN1MK7Xbm9h3l99zotnxxZxeYzRm ZMoU/fxyIlSKdHqYKmEPaF8Non1PF8WZqU8r65TqH/g1gVOwcakNUZAK; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Boschi, Elisa wrote: > Paul, Andrew, > > >> One more that might be a bit obtuse. The technique for > >> defining separate cpIds for source and destination Common > >> Properties is mentioned in the draft. For common combinations > >> a third category of cpId could be used which maps to two other > >> cpIds. > >> > >> i.e.: > >> cpID C -> cpID A + cpID B > >> cpID A -> source address A, source port A > >> cpID B -> destination address B, source port B > > > > > > Which raises the question of what duplicate cpID means, eg: > > > > cpID D -> cpID C + cpID A > > > > > > Also, we need to be careful to avoid circular definitions, eg: > > > > cpID E -> cpID F [ + cpID ... ] > > cpID F -> cpID E [ + cpID ... ] > > > > > > Probably an exporter SHOULD NOT send these, and a collector MUST > > detect and discard them, and log. > > > Agree, but I propose a SHOULD instead of a MUST: > > "An Exporter SHOULD NOT send Common Properties defined in terms of other > Common Properties (i.e. when one of the properties is a > CommonPropertiesID), and a Collector SHOULD detect and discard them and > log." I think you misunderstand Paul's position. I believe Paul thinks that the collector should catch circular definitions. The idea of defining common Properties in terms of other common properties seems completely valid to me. regards Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Dec 06 10:08:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GryMe-0006gV-DR; Wed, 06 Dec 2006 10:07:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GryMc-0006gC-MH for ipfix@ietf.org; Wed, 06 Dec 2006 10:07:14 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GryMa-0002Bg-Bc for ipfix@ietf.org; Wed, 06 Dec 2006 10:07:14 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Dec 2006 16:07:12 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB6F7AAs002059; Wed, 6 Dec 2006 16:07:10 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB6F7AAJ026031; Wed, 6 Dec 2006 16:07:10 +0100 (MET) Received: from [144.254.153.27] (dhcp-144-254-153-27.cisco.com [144.254.153.27]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA18544; Wed, 6 Dec 2006 15:07:09 GMT Message-ID: <4576DC9D.7090101@cisco.com> Date: Wed, 06 Dec 2006 15:07:09 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Boschi, Elisa" Subject: Re: [IPFIX] An advanced for Reducing Redundancy References: <3167F18F59B81B4888A4D4C0A1717DD6670F98@mhdexc02.adhel.hitachi-eu.com> In-Reply-To: <3167F18F59B81B4888A4D4C0A1717DD6670F98@mhdexc02.adhel.hitachi-eu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1430; t=1165417630; x=1166281630; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20An=20advanced=20for=20Reducing=20Redundancy |Sender:=20; bh=dEVz45T0EnAJjTdhRcNI9Rbrd7zVdOz6WuVBrTSgS1U=; b=EvFke99F1CfO7AVhqdnsmU3cwIhqWrylRU/Z3LaZRYdtdN1MK7Xbm9h3l99zotnxxZxeYzRm ZMoU/fxyIlSKdHqYKmEPaF8Non1PF8WZqU8r65TqH/g1gVOwcakNUZAK; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Boschi, Elisa wrote: > Paul, Andrew, > > >> One more that might be a bit obtuse. The technique for > >> defining separate cpIds for source and destination Common > >> Properties is mentioned in the draft. For common combinations > >> a third category of cpId could be used which maps to two other > >> cpIds. > >> > >> i.e.: > >> cpID C -> cpID A + cpID B > >> cpID A -> source address A, source port A > >> cpID B -> destination address B, source port B > > > > > > Which raises the question of what duplicate cpID means, eg: > > > > cpID D -> cpID C + cpID A > > > > > > Also, we need to be careful to avoid circular definitions, eg: > > > > cpID E -> cpID F [ + cpID ... ] > > cpID F -> cpID E [ + cpID ... ] > > > > > > Probably an exporter SHOULD NOT send these, and a collector MUST > > detect and discard them, and log. > > > Agree, but I propose a SHOULD instead of a MUST: > > "An Exporter SHOULD NOT send Common Properties defined in terms of other > Common Properties (i.e. when one of the properties is a > CommonPropertiesID), and a Collector SHOULD detect and discard them and > log." I think you misunderstand Paul's position. I believe Paul thinks that the collector should catch circular definitions. The idea of defining common Properties in terms of other common properties seems completely valid to me. regards Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Dec 06 12:08:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs0Er-0005Qw-Ow; Wed, 06 Dec 2006 12:07:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs0Ep-0005ON-Ox for ipfix@ietf.org; Wed, 06 Dec 2006 12:07:19 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs0Em-0005jq-SQ for ipfix@ietf.org; Wed, 06 Dec 2006 12:07:19 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Dec 2006 18:07:17 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB6H7Fss016737; Wed, 6 Dec 2006 18:07:15 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB6H7FAJ026008; Wed, 6 Dec 2006 18:07:15 +0100 (MET) Received: from [10.61.65.220] (ams3-vpn-dhcp476.cisco.com [10.61.65.220]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA02320; Wed, 6 Dec 2006 17:07:14 GMT Message-ID: <4576F8A7.6000604@cisco.com> Date: Wed, 06 Dec 2006 17:06:47 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: "Boschi, Elisa" Subject: Re: [IPFIX] An advanced for Reducing Redundancy References: <3167F18F59B81B4888A4D4C0A1717DD6670F98@mhdexc02.adhel.hitachi-eu.com> <4576DC9D.7090101@cisco.com> In-Reply-To: <4576DC9D.7090101@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1658; t=1165424836; x=1166288836; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20An=20advanced=20for=20Reducing=20Redundancy |Sender:=20; bh=zCaj6R7WX2WgvHncXMohX7oUJ/wE8SOYBaqLMzPvpvU=; b=MWHa2MbYm0pHhsZJcpdDULDNx60VSRUOucUhqDO60Dezp9DHqWFdELtPFjLD5AjWt/oXCQba 5DSbNgd79P0zaK96yToo3LS9584yqTfz4zrN5CMh/KLWXOzssINUX/IX; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Elisa, >> Paul, Andrew, >> >> >> One more that might be a bit obtuse. The technique for >> >> defining separate cpIds for source and destination Common >> >> Properties is mentioned in the draft. For common combinations >> >> a third category of cpId could be used which maps to two other >> >> cpIds. >> >> >> >> i.e.: >> >> cpID C -> cpID A + cpID B >> >> cpID A -> source address A, source port A >> >> cpID B -> destination address B, source port B >> > >> > >> > Which raises the question of what duplicate cpID means, eg: >> > >> > cpID D -> cpID C + cpID A >> > >> > >> > Also, we need to be careful to avoid circular definitions, eg: >> > >> > cpID E -> cpID F [ + cpID ... ] >> > cpID F -> cpID E [ + cpID ... ] >> > >> > >> > Probably an exporter SHOULD NOT send these, and a collector MUST >> > detect and discard them, and log. >> >> Agree, but I propose a SHOULD instead of a MUST: >> >> "An Exporter SHOULD NOT send Common Properties defined in terms of >> other Common Properties (i.e. when one of the properties is a >> CommonPropertiesID), and a Collector SHOULD detect and discard them >> and log." Awww man, nooooo! I want to be able to build CP ID trees without having to create CommonCommonProperties or CommonCommonPropertiesProperties! > I think you misunderstand Paul's position. I believe Paul thinks that > the collector should catch circular definitions. The idea of defining > common Properties in terms of other common properties seems completely > valid to me. Exactly. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Dec 06 12:08:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs0Er-0005Qw-Ow; Wed, 06 Dec 2006 12:07:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs0Ep-0005ON-Ox for ipfix@ietf.org; Wed, 06 Dec 2006 12:07:19 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs0Em-0005jq-SQ for ipfix@ietf.org; Wed, 06 Dec 2006 12:07:19 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Dec 2006 18:07:17 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB6H7Fss016737; Wed, 6 Dec 2006 18:07:15 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB6H7FAJ026008; Wed, 6 Dec 2006 18:07:15 +0100 (MET) Received: from [10.61.65.220] (ams3-vpn-dhcp476.cisco.com [10.61.65.220]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA02320; Wed, 6 Dec 2006 17:07:14 GMT Message-ID: <4576F8A7.6000604@cisco.com> Date: Wed, 06 Dec 2006 17:06:47 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: "Boschi, Elisa" Subject: Re: [IPFIX] An advanced for Reducing Redundancy References: <3167F18F59B81B4888A4D4C0A1717DD6670F98@mhdexc02.adhel.hitachi-eu.com> <4576DC9D.7090101@cisco.com> In-Reply-To: <4576DC9D.7090101@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1658; t=1165424836; x=1166288836; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20An=20advanced=20for=20Reducing=20Redundancy |Sender:=20; bh=zCaj6R7WX2WgvHncXMohX7oUJ/wE8SOYBaqLMzPvpvU=; b=MWHa2MbYm0pHhsZJcpdDULDNx60VSRUOucUhqDO60Dezp9DHqWFdELtPFjLD5AjWt/oXCQba 5DSbNgd79P0zaK96yToo3LS9584yqTfz4zrN5CMh/KLWXOzssINUX/IX; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Elisa, >> Paul, Andrew, >> >> >> One more that might be a bit obtuse. The technique for >> >> defining separate cpIds for source and destination Common >> >> Properties is mentioned in the draft. For common combinations >> >> a third category of cpId could be used which maps to two other >> >> cpIds. >> >> >> >> i.e.: >> >> cpID C -> cpID A + cpID B >> >> cpID A -> source address A, source port A >> >> cpID B -> destination address B, source port B >> > >> > >> > Which raises the question of what duplicate cpID means, eg: >> > >> > cpID D -> cpID C + cpID A >> > >> > >> > Also, we need to be careful to avoid circular definitions, eg: >> > >> > cpID E -> cpID F [ + cpID ... ] >> > cpID F -> cpID E [ + cpID ... ] >> > >> > >> > Probably an exporter SHOULD NOT send these, and a collector MUST >> > detect and discard them, and log. >> >> Agree, but I propose a SHOULD instead of a MUST: >> >> "An Exporter SHOULD NOT send Common Properties defined in terms of >> other Common Properties (i.e. when one of the properties is a >> CommonPropertiesID), and a Collector SHOULD detect and discard them >> and log." Awww man, nooooo! I want to be able to build CP ID trees without having to create CommonCommonProperties or CommonCommonPropertiesProperties! > I think you misunderstand Paul's position. I believe Paul thinks that > the collector should catch circular definitions. The idea of defining > common Properties in terms of other common properties seems completely > valid to me. Exactly. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Dec 06 13:40:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs1fu-0000D1-Bu; Wed, 06 Dec 2006 13:39:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs1ft-0000Cw-1f for ipfix@ietf.org; Wed, 06 Dec 2006 13:39:21 -0500 Received: from gatekeeper.hitachi-eu.com ([194.36.128.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs1fn-0003tL-Ds for ipfix@ietf.org; Wed, 06 Dec 2006 13:39:21 -0500 X-ASG-Debug-ID: 1165430354-386f00040000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: primary.hitachi-eu.net[193.39.225.234] X-Barracuda-Start-Time: 1165430354 X-ASG-Whitelist: Client Received: from mhd-esafe-int.hitachi-eu.com (primary.hitachi-eu.net [193.39.225.234]) by gatekeeper.hitachi-eu.com (Spam Firewall) with SMTP id 2B5D92A919 for ; Wed, 6 Dec 2006 18:39:14 +0000 (GMT) Received: from MHDEXC99.adhel.hitachi-eu.com ([IP=193.39.227.52]) by eSafe SMTP Relay 1165411933; Wed Dec 6 18:39:14 2006 Received: from mhdexc02.adhel.hitachi-eu.com ([193.39.227.51]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 18:39:13 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [IPFIX] An advanced for Reducing Redundancy Subject: Re: [IPFIX] An advanced for Reducing Redundancy Date: Wed, 6 Dec 2006 18:37:11 -0000 Message-ID: <3167F18F59B81B4888A4D4C0A1717DD6670F99@mhdexc02.adhel.hitachi-eu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] An advanced for Reducing Redundancy Thread-Index: AccZZYrwKQWhAVPITiG6c782aiWpDg== X-Priority: 5 Priority: Non-Urgent Importance: low From: "Boschi, Elisa" To: X-OriginalArrivalTime: 06 Dec 2006 18:39:13.0656 (UTC) FILETIME=[D3A53780:01C71965] X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com X-Spam-Score: 0.1 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0026840619==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0026840619== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71965.D35053BD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71965.D35053BD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul, >> One more that might be a bit obtuse. The technique for=20 >> defining separate cpIds for source and destination Common=20 >> Properties is mentioned in the draft. For common combinations=20 >> a third category of cpId could be used which maps to two other=20 >> cpIds.=20 >>=20 >> i.e.:=20 >> cpID C -> cpID A + cpID B=20 >> cpID A -> source address A, source port A=20 >> cpID B -> destination address B, source port B=20 >=20 >=20 > Which raises the question of what duplicate cpID means, eg:=20 >=20 > cpID D -> cpID C + cpID A=20 >=20 >=20 > Also, we need to be careful to avoid circular definitions, eg:=20 >=20 > cpID E -> cpID F [ + cpID ... ]=20 > cpID F -> cpID E [ + cpID ... ]=20 >=20 >=20 > Probably an exporter SHOULD NOT send these, and a collector MUST=20 > detect and discard them, and log.=20 =09 >>> Agree, but I propose a SHOULD instead of a MUST:=20 =09 >>> "An Exporter SHOULD NOT send Common Properties defined in >>> term= s of other Common Properties (i.e. when one of the properties >>> is a Co= mmonPropertiesID), and a Collector SHOULD detect and >>> discard them and= log."=20 =09 =09 > Awww man, nooooo!=20 =09 > I want to be able to build CP ID trees without having to create Common= CommonProperties or CommonCommonPropertiesProperties!=20 =09 so to avoid that you propose to define CommonProperties in terms of other= Common Properties which in turn are defined in terms of CommonProperties= which... Is it really better? If we allow trees, there are a few things more to worry about that should= be addressed in the draft. For example:=20 duplication (as also written by Andrew) cpID A --> src addr A, src port A cpID B --> src addr A, cpID A collision cpID A --> src addr A, src port A cpID A --> src addr B, cpID A withdrawal what happens to a node in the tree if one of its children (or a node in i= ts subtree) is a cpID and is withdrawn? Does the collecting process need = to search for all the CP that are defined in terms of it and invalidate t= hem too? >> I think you misunderstand Paul's position. I believe Paul thinks th= at=20 >> the collector should catch circular definitions. The idea of defini= ng=20 >> common Properties in terms of other common properties seems complete= ly=20 >> valid to me.=20 =09 > Exactly.=20 =09 *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* ------_=_NextPart_001_01C71965.D35053BD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Paul,

 >> One more that might be a= bit=20 obtuse.  The technique for
 >> defining separat= e cpIds=20 for source and destination Common
 >> Properties is=20 mentioned in the draft.  For common combinations
 >= ;> a=20 third category of cpId could be used which maps to two other=20
 >> cpIds.
 >>
 >> i.e= =2E:=20
 >>  cpID C -> cpID A + cpID B=20
 >>  cpID A -> source address A, source port= A=20
 >>  cpID B -> destination address B, source= port B=20
 >
 >
 > Which raises the quest= ion of=20 what duplicate cpID means, eg:
 >
 > &= nbsp;=20 cpID D -> cpID C + cpID A
 >
 >
&nbs= p;>=20 Also, we need to be careful to avoid circular definitions, eg:=20
 >
 >   cpID E -> cpID F [ + c= pID ...=20 ]
 >   cpID F -> cpID E [ + cpID ... ]=20
 >
 >
 > Probably an exporter S= HOULD=20 NOT send these, and a collector MUST
 > detect and disc= ard=20 them, and log.

>>> Agree, but I propose a SHOULD i= nstead=20 of a MUST:

>>> "An Exporter SHOULD NOT send Common= =20 Properties defined in >>> terms of other Common Properties= (i.e.=20 when one of the properties >>> is a CommonPropertiesID), a= nd a=20 Collector SHOULD detect and >>> discard them and log."=20


> Awww man, nooooo!

> I want to be able to build C= P ID=20 trees without having to create CommonCommonProperties or=20 CommonCommonPropertiesProperties!

so to avoid that you propose to define CommonProperties in terms of = other=20 Common Properties which in turn are defined in terms of CommonProperties=20 which...
Is it really better?

If we allow trees, there are a fe= w=20 things more to worry about that should be addressed in the draft.

= For=20 example:

duplication (as also written by Andrew)

cpID A --= >=20 src addr A, src port A
cpID B --> src addr A, cpID=20 A

collision

cpID A --> src addr A, src port A
cpID A = -->=20 src addr B, cpID A

withdrawal

what happens to a node in the= tree=20 if one of its children (or a node in its subtree) is a cpID and is withdr= awn?=20 Does the collecting process need to search for all the CP that are define= d in=20 terms of it and invalidate them too?


>> I think you misunderstand Paul's=20 position.  I believe Paul thinks that
>> the collector= should=20 catch circular definitions.  The idea of defining
>> c= ommon=20 Properties in terms of other common properties seems completely
&= gt;>=20 valid to me.

> Exactly.=20 
*************************************************************************=
*************************
=20
 E-mail Confidentiality Notice and Disclaimer.
=20
  This email and any files transmitted with it are confidential and are i=
ntended solely for=20
the use of the individual or entity to which they are addressed. Access t=
o this e-mail by=20
anyone else is unauthorised. If you are not the intended recipient, any d=
isclosure,=20
copying, distribution or any action taken or omitted to be taken in relia=
nce on it, is=20
prohibited.=20
  E-mail messages are not necessarily secure.  Hitachi does not accept re=
sponsibility=20
for any changes made to this message after it was sent.=20
  Please note that Hitachi checks outgoing e-mail messages for the presen=
ce of=20
computer viruses.

*************************************************************************=
*************************
------_=_NextPart_001_01C71965.D35053BD-- --===============0026840619== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============0026840619==-- From ipfix-bounces@ietf.org Wed Dec 06 13:40:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs1fu-0000D1-Bu; Wed, 06 Dec 2006 13:39:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs1ft-0000Cw-1f for ipfix@ietf.org; Wed, 06 Dec 2006 13:39:21 -0500 Received: from gatekeeper.hitachi-eu.com ([194.36.128.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs1fn-0003tL-Ds for ipfix@ietf.org; Wed, 06 Dec 2006 13:39:21 -0500 X-ASG-Debug-ID: 1165430354-386f00040000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: primary.hitachi-eu.net[193.39.225.234] X-Barracuda-Start-Time: 1165430354 X-ASG-Whitelist: Client Received: from mhd-esafe-int.hitachi-eu.com (primary.hitachi-eu.net [193.39.225.234]) by gatekeeper.hitachi-eu.com (Spam Firewall) with SMTP id 2B5D92A919 for ; Wed, 6 Dec 2006 18:39:14 +0000 (GMT) Received: from MHDEXC99.adhel.hitachi-eu.com ([IP=193.39.227.52]) by eSafe SMTP Relay 1165411933; Wed Dec 6 18:39:14 2006 Received: from mhdexc02.adhel.hitachi-eu.com ([193.39.227.51]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 18:39:13 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [IPFIX] An advanced for Reducing Redundancy Subject: Re: [IPFIX] An advanced for Reducing Redundancy Date: Wed, 6 Dec 2006 18:37:11 -0000 Message-ID: <3167F18F59B81B4888A4D4C0A1717DD6670F99@mhdexc02.adhel.hitachi-eu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] An advanced for Reducing Redundancy Thread-Index: AccZZYrwKQWhAVPITiG6c782aiWpDg== X-Priority: 5 Priority: Non-Urgent Importance: low From: "Boschi, Elisa" To: X-OriginalArrivalTime: 06 Dec 2006 18:39:13.0656 (UTC) FILETIME=[D3A53780:01C71965] X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com X-Spam-Score: 0.1 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0026840619==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0026840619== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71965.D35053BD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71965.D35053BD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul, >> One more that might be a bit obtuse. The technique for=20 >> defining separate cpIds for source and destination Common=20 >> Properties is mentioned in the draft. For common combinations=20 >> a third category of cpId could be used which maps to two other=20 >> cpIds.=20 >>=20 >> i.e.:=20 >> cpID C -> cpID A + cpID B=20 >> cpID A -> source address A, source port A=20 >> cpID B -> destination address B, source port B=20 >=20 >=20 > Which raises the question of what duplicate cpID means, eg:=20 >=20 > cpID D -> cpID C + cpID A=20 >=20 >=20 > Also, we need to be careful to avoid circular definitions, eg:=20 >=20 > cpID E -> cpID F [ + cpID ... ]=20 > cpID F -> cpID E [ + cpID ... ]=20 >=20 >=20 > Probably an exporter SHOULD NOT send these, and a collector MUST=20 > detect and discard them, and log.=20 =09 >>> Agree, but I propose a SHOULD instead of a MUST:=20 =09 >>> "An Exporter SHOULD NOT send Common Properties defined in >>> term= s of other Common Properties (i.e. when one of the properties >>> is a Co= mmonPropertiesID), and a Collector SHOULD detect and >>> discard them and= log."=20 =09 =09 > Awww man, nooooo!=20 =09 > I want to be able to build CP ID trees without having to create Common= CommonProperties or CommonCommonPropertiesProperties!=20 =09 so to avoid that you propose to define CommonProperties in terms of other= Common Properties which in turn are defined in terms of CommonProperties= which... Is it really better? If we allow trees, there are a few things more to worry about that should= be addressed in the draft. For example:=20 duplication (as also written by Andrew) cpID A --> src addr A, src port A cpID B --> src addr A, cpID A collision cpID A --> src addr A, src port A cpID A --> src addr B, cpID A withdrawal what happens to a node in the tree if one of its children (or a node in i= ts subtree) is a cpID and is withdrawn? Does the collecting process need = to search for all the CP that are defined in terms of it and invalidate t= hem too? >> I think you misunderstand Paul's position. I believe Paul thinks th= at=20 >> the collector should catch circular definitions. The idea of defini= ng=20 >> common Properties in terms of other common properties seems complete= ly=20 >> valid to me.=20 =09 > Exactly.=20 =09 *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* ------_=_NextPart_001_01C71965.D35053BD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Paul,

 >> One more that might be a= bit=20 obtuse.  The technique for
 >> defining separat= e cpIds=20 for source and destination Common
 >> Properties is=20 mentioned in the draft.  For common combinations
 >= ;> a=20 third category of cpId could be used which maps to two other=20
 >> cpIds.
 >>
 >> i.e= =2E:=20
 >>  cpID C -> cpID A + cpID B=20
 >>  cpID A -> source address A, source port= A=20
 >>  cpID B -> destination address B, source= port B=20
 >
 >
 > Which raises the quest= ion of=20 what duplicate cpID means, eg:
 >
 > &= nbsp;=20 cpID D -> cpID C + cpID A
 >
 >
&nbs= p;>=20 Also, we need to be careful to avoid circular definitions, eg:=20
 >
 >   cpID E -> cpID F [ + c= pID ...=20 ]
 >   cpID F -> cpID E [ + cpID ... ]=20
 >
 >
 > Probably an exporter S= HOULD=20 NOT send these, and a collector MUST
 > detect and disc= ard=20 them, and log.

>>> Agree, but I propose a SHOULD i= nstead=20 of a MUST:

>>> "An Exporter SHOULD NOT send Common= =20 Properties defined in >>> terms of other Common Properties= (i.e.=20 when one of the properties >>> is a CommonPropertiesID), a= nd a=20 Collector SHOULD detect and >>> discard them and log."=20


> Awww man, nooooo!

> I want to be able to build C= P ID=20 trees without having to create CommonCommonProperties or=20 CommonCommonPropertiesProperties!

so to avoid that you propose to define CommonProperties in terms of = other=20 Common Properties which in turn are defined in terms of CommonProperties=20 which...
Is it really better?

If we allow trees, there are a fe= w=20 things more to worry about that should be addressed in the draft.

= For=20 example:

duplication (as also written by Andrew)

cpID A --= >=20 src addr A, src port A
cpID B --> src addr A, cpID=20 A

collision

cpID A --> src addr A, src port A
cpID A = -->=20 src addr B, cpID A

withdrawal

what happens to a node in the= tree=20 if one of its children (or a node in its subtree) is a cpID and is withdr= awn?=20 Does the collecting process need to search for all the CP that are define= d in=20 terms of it and invalidate them too?


>> I think you misunderstand Paul's=20 position.  I believe Paul thinks that
>> the collector= should=20 catch circular definitions.  The idea of defining
>> c= ommon=20 Properties in terms of other common properties seems completely
&= gt;>=20 valid to me.

> Exactly.=20 
*************************************************************************=
*************************
=20
 E-mail Confidentiality Notice and Disclaimer.
=20
  This email and any files transmitted with it are confidential and are i=
ntended solely for=20
the use of the individual or entity to which they are addressed. Access t=
o this e-mail by=20
anyone else is unauthorised. If you are not the intended recipient, any d=
isclosure,=20
copying, distribution or any action taken or omitted to be taken in relia=
nce on it, is=20
prohibited.=20
  E-mail messages are not necessarily secure.  Hitachi does not accept re=
sponsibility=20
for any changes made to this message after it was sent.=20
  Please note that Hitachi checks outgoing e-mail messages for the presen=
ce of=20
computer viruses.

*************************************************************************=
*************************
------_=_NextPart_001_01C71965.D35053BD-- --===============0026840619== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============0026840619==-- From ipfix-bounces@ietf.org Wed Dec 06 19:06:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs6lB-0000G2-1w; Wed, 06 Dec 2006 19:05:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs6lA-0000Fp-97 for ipfix@ietf.org; Wed, 06 Dec 2006 19:05:08 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gs6ks-0005wb-QT for ipfix@ietf.org; Wed, 06 Dec 2006 19:05:08 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 Dec 2006 01:04:48 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB704lN7020711; Thu, 7 Dec 2006 01:04:47 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB704lAJ024387; Thu, 7 Dec 2006 01:04:47 +0100 (MET) Received: from [10.61.81.32] (ams3-vpn-dhcp4385.cisco.com [10.61.81.32]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id AAA04719; Thu, 7 Dec 2006 00:04:44 GMT Message-ID: <45775A7D.5030601@cisco.com> Date: Thu, 07 Dec 2006 00:04:13 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Boschi, Elisa" Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <3167F18F59B81B4888A4D4C0A1717DD6670F97@mhdexc02.adhel.hitachi-eu.com> In-Reply-To: <3167F18F59B81B4888A4D4C0A1717DD6670F97@mhdexc02.adhel.hitachi-eu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12475; t=1165449887; x=1166313887; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20WG=20last=20call=20on=20draft-ietf-ipfix-re ducing-redundancy-01.txt=0A=20until=20December=201st |Sender:=20; bh=i7pblwSlFRG7kFCjjsjiIaphsq6dWydR4+1q66Cv4bM=; b=eEoN4eo9fws7spPp3cF1P1srnmnihtVhxFqB0T2mh2F6NTV2HulBiuxF5emXQaKAJcuNsX2M /+m8ybJUQDYeUGkYrQ1eQRI1uFCthu0/Wqi9AeNSxehgBD3mBViy7Ejj; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Boschi, Elisa wrote: > Andrew, Benoit, all, > > Comments, as usual, inline... Ditto... > Andrew Johnson wrote: > > >>> Since a flow is defined as a group of packets that share > >>> a set of common properties, i.e. key fields, is there > >>> any danger that the commonPropertiesID will be wrongly > >>> assumed to refer to only the complete set of key fields? > >> > >> > >> By definition, I think this is impossible. The flow key > >> definition says "Each of the fields which are used to define > >> a Flow are termed Flow Keys.". So there is nothing in common > >> between flows. However, I understand your concern for novice readers. [SNIP] > > My concern wasn't really directed at the draft itself, but just the > > name "common properties". > > From IPFIX-PROTO: > > "A Flow is defined as a set of IP packets passing an Observation > > Point in the network during a certain time interval. All packets > > belonging to a particular Flow have a set of common properties." > > > > And then from IPFIX-INFO: > > Description of commonPropertiesId: > > An identifier of a set of common properties that is unique per > > Observation Domain. Typically, this Information Element is used > > to link to information reported in separate records. > > > > The terminology is almost identical. The commonPropertiesId refers > > to "a set of common properties" that is quite different from ones > > that determine a Flow. > > so maybe the text proposed by Benoit helps clarifying things. I agree > with adding it How does that help? As I just said, "my concern wasn't really directed at the draft itself..." The only change to help clarify this would be in IPFIX-INFO in the description of the commonPropertiesId. Perhaps to (I changed the unique within to what it should be too): An identifier of a set of properties that is common across more that one Flow. Typically, this Information Element is used to link to information reported in separate records. The identifier is unique per Transport Session and Observation Domain. > >>> Is there any need to define a new term for "Specific > >>> Properties"? These are just part of a normal Data Record. > >>> For example: > >>> "... The rows are then referenced by the Specific Properties > >>> by using the appropriate value for the Common Properties > >>> identifier." > >>> > >>> could simply be: > >>> "... The rows are then referenced by Data Records by > >>> using the appropriate value for the Common Properties > >>> identifier." > >> > >> > >> In your example, the "Data Records" doesn't mean the full data > >> records before applying the redundancy reduction mechanism but only > >> a part of it. > >> So it might be confusing... That's the trick we found. > > > > The Specific Properties are "what is left" of the Data Record when the > Common Properties have been defined. In your example above using Data > Records is wrong... Wrong? It wouldn't be the first time, but perhaps you would like to explain your reasoning for saying so. A Flow is handed from the Metering Process to the Exporting Process. The Exporting Process performs some magic, possibly including some reducing redundancy type stuff and produces and IPFIX export stream. >From IPFIX-PROTO: Data Record A Data Record is a record that contains values of the parameters corresponding to a Template Record... The Data Records are something that the Exporting Process produces, it is not right to talk about Data Records before something is exported. > Using the term Specific Properties seems clearer... > (and it seemed intuitive after the term Common Properties had been used) By all means say that the Data Record that is sent contains properties specific to the Flow. I'm not complaining about calling them specific properties, but I don't think there is any need to have a new definition of "Specific Properties". > >>> How do you propose to withdraw common properties when they are > >>> associated with a template rather than the Common Properties index? > >> > >> > >> I don't ;) This is the reason why the use the Common Properties > >> index is a cleaner design. > > > > > > I think withdrawal messages should work in general for options > > data, so why not send an empty record with the template as scope? > > > yes we should add a sentence on that. Maybe in 8.3 (CommonProertiesID > vs. TemplatedID scope). Something like: > > Note that, if templateIDs are used, and similarly to commonPropertiesID > management, templateIDs that are not used anymore SHOULD be withdrawn. Erm, careful. Properties associated with a template need to withdrawn, not necessarily the templateID / template itself which is done with a template withdrawal message. > >>> General Comments > >>> ================ > >>> I think, sections 3.1.2, 8.2 and 8.3 would be better grouped > >>> into a 3.2 Advanced Techniques section. > > > > > I am not sure I would call 8.2 and 8.3 advanced techniques... they > really seem more an evaluation thing... Like recommending using reduced > size encoding for commonPropertiesId whenever possible for increased > data reduction(in 8.2) The idea is that you want one section that simply explains the system. Once the reader understands the basics you can then add things like using RLE for the IDs. It's "advanced" because it's not essential, it's not needed in the most basic of systems. > >>> I think 3.2 Per Packet Data Reduction, should be removed and > >>> any information that is not in section 3.1 should be added to > >>> to the PSAMP example. > >>> I think the the per-packet example is a good example of > >>> per flow reducing redundancy and section 11.1.1 can be removed. > >> > >> See one of my previous remark about: > >> > >> 3.1 Per Flow Data Reduction...............................11 > >> 3.1.1 Unique Data Reduction..................................11 > >> 3.1.2 Multiple Data Reduction................................12 > >> 3.2 Per Packet Data Reduction.............................13 > >> > >> Again, it's because you know the boundary between IPFIX and PSAMP > > > > > > I just don't think the repetition is necessary. Per-packet is > > just a good example of the technique, the Per Packet section > > doesn't seem to add any new information. > > > see my proposal below > > > > >>> 3.1.2 Multiple Data Reduction > >>> > >>> I don't think this section is explained very well. From my original > >>> email to Elisa and Lutz (18th Nov 2005): > >>> Andrew Johnson wrote: > >>> > >>>> Flows > >>>> ===== > >>>> Flow A: flowId 1, flowId 11, 30 packets, 6000 bytes > >>>> Flow B: flowID 1, flowId 12, 50 packets, 9500 bytes > >>>> Flow C: flowId 2, flowId 11, 60 packets, 8000 bytes > >>>> Flow D: flowID 2, flowId 12, 10 packets, 1500 bytes > >>>> > >>>> Options > >>>> ======= > >>>> flowId 1 - destinationIpv4address 10.0.0.1, destinationTcpPort 80 > >>>> flowId 1 - destinationIpv4address 10.0.0.5, destinationTcpPort 80 > >>>> > >>>> flowId 11 - sourceIpv4address 10.0.1.10, sourceTcpPort 1932 > >>>> flowId 12 - sourceIpv4address 10.0.1.15, sourceTcpPort 1842 > >>> > >>> > >>> This shows how 4 (2+2) options can be expanded to 4 combinations of > >>> Data Record to reduce redundancy without the need to define 4 complete > >>> sets of Common Properties and therefore not save any bandwidth. The > >>> more options you have the better this works. 20 options (10+10) would > >>> give you up to 100 possible pairs common properties. > >>> > >>> This isn't really made clear in the draft text, with only "flow1" > >>> having two indices. > >> > >> I agree the examples in figure 4/5 don't show this. > >> Maybe a new section in section 8 "Export and Evaluation Considerations"? > > > Agreed. But I think it should be addressed in section 3 I think section 3 should concentrate on explaining the most basic system from start to end. Once the user is clear about that then you can add complications, such as this. > >>> The example in 11.1.2 doesn't even have any! > >> > >> Agreed. This should be corrected. > >> > >>> > >>> While I agree that using a template that doesn't include the cpID > >>> is a good idea to efficiently communicate flows with not so common > >>> properties, however I would call this an "Advanced Technique" to be > >>> listed in the section I proposed earlier. > > do you mean using the templateID instead of the CommonPopertiesID? No. I'm talking about sending Data Records that contain all the properties from the original Flow when none of its properties are shared between Flows. Since none of this particular Flows properties are common, then sending it in full is more efficient that sending it with a cpID. > >>> > >>> > >>> 3.2 Per Packet Data Reduction > >>> > >>> The text reads: > >>> If filtering is applied to select a series of packets, using the > >>> PSAMP specifications to export per-packet information might be > >>> relatively inefficient if the filtered fields (the common attributes) > >>> are exported in every single record. > >>> > >>> However in section 6.5.2.5 (Property Match Filtering) of PSAMP-PROTO > >>> it is explained how the filter information MUST be sent. This is > >>> designed so that the selector ID will match the one from the Data > >>> Record (via the selectionSequenceId) and perform exactly the function > >>> that is being proposed here for the commonPropertiesId. > >> > >> Good point. I would remove this paragraph and move to this place the > >> one starting with: > >> > >> An example of the per packet data reduction is the measurement of > >> One-Way Delay (OWD), where the exact same specific packet must be > >> observed at the source and destination of the path to be measured. > >> By subtracting ... > > > Remember that section 3 explains the general solution...It doesn't seem > to be a good idea to have in the general specification just the > description of one example application, such as OWD. > See my proposal below > > >>> > >>> 4. Specifications for bandwidth saving information export > >>> > >>> What is being specified here that isn't true for ALL options as > >>> described in IPFIX-PROTO? > >> > >> > >> What do you suggest? Also, I'd like to reduce repetition from the protocol draft. You shouldn't explain how options work here, just reference the relevant section of [IPFIX-PROTO]. > > Well it seems that section three really explains almost the same > > thing 3 times. The section 4 explains most of it again (with a > > bit more info) another 3 times. > > I would prefer section 3 to simply explain the technique. Walk > > through how the information from a Flow is split into two parts, > > and then add the bit from section 4 how these two parts are > > exported. > > > > Using more than one CPid in a record should be part of the > > advanced techniques once the basics are made clear. Per packet > > should just be a detailed example at the end. > > > > I propose the following change: > > section three is split in just two sections: uique data reduction and > multiple data reduction. In the introductory part of section three we > write something like: You don't need to repeat how this works for "multiple data reduction". It works in the same way, but you have 2 cpIDs. Get the basics clear first and then expand on it later. > The PSAMP specifications are used for the export of per-packet > information, exporting the specific observed packet in an IPFIX Flow > Record. This can be considered as a special Flow Record case, composed > of a single packet. Therefore, the method described in this document is > applicable to per packet data reduction, e.g. for export of One Way > Delay (OWD) measurements (see Appendix), trajectory sampling, etc. > > The text on OWD can be moved to the Appendix, where we describe in > detail the OWD example. Moving the per-packet stuff to a detailed example in the Appendix sounds like a good idea to me. Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Dec 06 19:06:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs6lB-0000G2-1w; Wed, 06 Dec 2006 19:05:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs6lA-0000Fp-97 for ipfix@ietf.org; Wed, 06 Dec 2006 19:05:08 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gs6ks-0005wb-QT for ipfix@ietf.org; Wed, 06 Dec 2006 19:05:08 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 Dec 2006 01:04:48 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB704lN7020711; Thu, 7 Dec 2006 01:04:47 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB704lAJ024387; Thu, 7 Dec 2006 01:04:47 +0100 (MET) Received: from [10.61.81.32] (ams3-vpn-dhcp4385.cisco.com [10.61.81.32]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id AAA04719; Thu, 7 Dec 2006 00:04:44 GMT Message-ID: <45775A7D.5030601@cisco.com> Date: Thu, 07 Dec 2006 00:04:13 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Boschi, Elisa" Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <3167F18F59B81B4888A4D4C0A1717DD6670F97@mhdexc02.adhel.hitachi-eu.com> In-Reply-To: <3167F18F59B81B4888A4D4C0A1717DD6670F97@mhdexc02.adhel.hitachi-eu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12475; t=1165449887; x=1166313887; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20WG=20last=20call=20on=20draft-ietf-ipfix-re ducing-redundancy-01.txt=0A=20until=20December=201st |Sender:=20; bh=i7pblwSlFRG7kFCjjsjiIaphsq6dWydR4+1q66Cv4bM=; b=eEoN4eo9fws7spPp3cF1P1srnmnihtVhxFqB0T2mh2F6NTV2HulBiuxF5emXQaKAJcuNsX2M /+m8ybJUQDYeUGkYrQ1eQRI1uFCthu0/Wqi9AeNSxehgBD3mBViy7Ejj; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Boschi, Elisa wrote: > Andrew, Benoit, all, > > Comments, as usual, inline... Ditto... > Andrew Johnson wrote: > > >>> Since a flow is defined as a group of packets that share > >>> a set of common properties, i.e. key fields, is there > >>> any danger that the commonPropertiesID will be wrongly > >>> assumed to refer to only the complete set of key fields? > >> > >> > >> By definition, I think this is impossible. The flow key > >> definition says "Each of the fields which are used to define > >> a Flow are termed Flow Keys.". So there is nothing in common > >> between flows. However, I understand your concern for novice readers. [SNIP] > > My concern wasn't really directed at the draft itself, but just the > > name "common properties". > > From IPFIX-PROTO: > > "A Flow is defined as a set of IP packets passing an Observation > > Point in the network during a certain time interval. All packets > > belonging to a particular Flow have a set of common properties." > > > > And then from IPFIX-INFO: > > Description of commonPropertiesId: > > An identifier of a set of common properties that is unique per > > Observation Domain. Typically, this Information Element is used > > to link to information reported in separate records. > > > > The terminology is almost identical. The commonPropertiesId refers > > to "a set of common properties" that is quite different from ones > > that determine a Flow. > > so maybe the text proposed by Benoit helps clarifying things. I agree > with adding it How does that help? As I just said, "my concern wasn't really directed at the draft itself..." The only change to help clarify this would be in IPFIX-INFO in the description of the commonPropertiesId. Perhaps to (I changed the unique within to what it should be too): An identifier of a set of properties that is common across more that one Flow. Typically, this Information Element is used to link to information reported in separate records. The identifier is unique per Transport Session and Observation Domain. > >>> Is there any need to define a new term for "Specific > >>> Properties"? These are just part of a normal Data Record. > >>> For example: > >>> "... The rows are then referenced by the Specific Properties > >>> by using the appropriate value for the Common Properties > >>> identifier." > >>> > >>> could simply be: > >>> "... The rows are then referenced by Data Records by > >>> using the appropriate value for the Common Properties > >>> identifier." > >> > >> > >> In your example, the "Data Records" doesn't mean the full data > >> records before applying the redundancy reduction mechanism but only > >> a part of it. > >> So it might be confusing... That's the trick we found. > > > > The Specific Properties are "what is left" of the Data Record when the > Common Properties have been defined. In your example above using Data > Records is wrong... Wrong? It wouldn't be the first time, but perhaps you would like to explain your reasoning for saying so. A Flow is handed from the Metering Process to the Exporting Process. The Exporting Process performs some magic, possibly including some reducing redundancy type stuff and produces and IPFIX export stream. >From IPFIX-PROTO: Data Record A Data Record is a record that contains values of the parameters corresponding to a Template Record... The Data Records are something that the Exporting Process produces, it is not right to talk about Data Records before something is exported. > Using the term Specific Properties seems clearer... > (and it seemed intuitive after the term Common Properties had been used) By all means say that the Data Record that is sent contains properties specific to the Flow. I'm not complaining about calling them specific properties, but I don't think there is any need to have a new definition of "Specific Properties". > >>> How do you propose to withdraw common properties when they are > >>> associated with a template rather than the Common Properties index? > >> > >> > >> I don't ;) This is the reason why the use the Common Properties > >> index is a cleaner design. > > > > > > I think withdrawal messages should work in general for options > > data, so why not send an empty record with the template as scope? > > > yes we should add a sentence on that. Maybe in 8.3 (CommonProertiesID > vs. TemplatedID scope). Something like: > > Note that, if templateIDs are used, and similarly to commonPropertiesID > management, templateIDs that are not used anymore SHOULD be withdrawn. Erm, careful. Properties associated with a template need to withdrawn, not necessarily the templateID / template itself which is done with a template withdrawal message. > >>> General Comments > >>> ================ > >>> I think, sections 3.1.2, 8.2 and 8.3 would be better grouped > >>> into a 3.2 Advanced Techniques section. > > > > > I am not sure I would call 8.2 and 8.3 advanced techniques... they > really seem more an evaluation thing... Like recommending using reduced > size encoding for commonPropertiesId whenever possible for increased > data reduction(in 8.2) The idea is that you want one section that simply explains the system. Once the reader understands the basics you can then add things like using RLE for the IDs. It's "advanced" because it's not essential, it's not needed in the most basic of systems. > >>> I think 3.2 Per Packet Data Reduction, should be removed and > >>> any information that is not in section 3.1 should be added to > >>> to the PSAMP example. > >>> I think the the per-packet example is a good example of > >>> per flow reducing redundancy and section 11.1.1 can be removed. > >> > >> See one of my previous remark about: > >> > >> 3.1 Per Flow Data Reduction...............................11 > >> 3.1.1 Unique Data Reduction..................................11 > >> 3.1.2 Multiple Data Reduction................................12 > >> 3.2 Per Packet Data Reduction.............................13 > >> > >> Again, it's because you know the boundary between IPFIX and PSAMP > > > > > > I just don't think the repetition is necessary. Per-packet is > > just a good example of the technique, the Per Packet section > > doesn't seem to add any new information. > > > see my proposal below > > > > >>> 3.1.2 Multiple Data Reduction > >>> > >>> I don't think this section is explained very well. From my original > >>> email to Elisa and Lutz (18th Nov 2005): > >>> Andrew Johnson wrote: > >>> > >>>> Flows > >>>> ===== > >>>> Flow A: flowId 1, flowId 11, 30 packets, 6000 bytes > >>>> Flow B: flowID 1, flowId 12, 50 packets, 9500 bytes > >>>> Flow C: flowId 2, flowId 11, 60 packets, 8000 bytes > >>>> Flow D: flowID 2, flowId 12, 10 packets, 1500 bytes > >>>> > >>>> Options > >>>> ======= > >>>> flowId 1 - destinationIpv4address 10.0.0.1, destinationTcpPort 80 > >>>> flowId 1 - destinationIpv4address 10.0.0.5, destinationTcpPort 80 > >>>> > >>>> flowId 11 - sourceIpv4address 10.0.1.10, sourceTcpPort 1932 > >>>> flowId 12 - sourceIpv4address 10.0.1.15, sourceTcpPort 1842 > >>> > >>> > >>> This shows how 4 (2+2) options can be expanded to 4 combinations of > >>> Data Record to reduce redundancy without the need to define 4 complete > >>> sets of Common Properties and therefore not save any bandwidth. The > >>> more options you have the better this works. 20 options (10+10) would > >>> give you up to 100 possible pairs common properties. > >>> > >>> This isn't really made clear in the draft text, with only "flow1" > >>> having two indices. > >> > >> I agree the examples in figure 4/5 don't show this. > >> Maybe a new section in section 8 "Export and Evaluation Considerations"? > > > Agreed. But I think it should be addressed in section 3 I think section 3 should concentrate on explaining the most basic system from start to end. Once the user is clear about that then you can add complications, such as this. > >>> The example in 11.1.2 doesn't even have any! > >> > >> Agreed. This should be corrected. > >> > >>> > >>> While I agree that using a template that doesn't include the cpID > >>> is a good idea to efficiently communicate flows with not so common > >>> properties, however I would call this an "Advanced Technique" to be > >>> listed in the section I proposed earlier. > > do you mean using the templateID instead of the CommonPopertiesID? No. I'm talking about sending Data Records that contain all the properties from the original Flow when none of its properties are shared between Flows. Since none of this particular Flows properties are common, then sending it in full is more efficient that sending it with a cpID. > >>> > >>> > >>> 3.2 Per Packet Data Reduction > >>> > >>> The text reads: > >>> If filtering is applied to select a series of packets, using the > >>> PSAMP specifications to export per-packet information might be > >>> relatively inefficient if the filtered fields (the common attributes) > >>> are exported in every single record. > >>> > >>> However in section 6.5.2.5 (Property Match Filtering) of PSAMP-PROTO > >>> it is explained how the filter information MUST be sent. This is > >>> designed so that the selector ID will match the one from the Data > >>> Record (via the selectionSequenceId) and perform exactly the function > >>> that is being proposed here for the commonPropertiesId. > >> > >> Good point. I would remove this paragraph and move to this place the > >> one starting with: > >> > >> An example of the per packet data reduction is the measurement of > >> One-Way Delay (OWD), where the exact same specific packet must be > >> observed at the source and destination of the path to be measured. > >> By subtracting ... > > > Remember that section 3 explains the general solution...It doesn't seem > to be a good idea to have in the general specification just the > description of one example application, such as OWD. > See my proposal below > > >>> > >>> 4. Specifications for bandwidth saving information export > >>> > >>> What is being specified here that isn't true for ALL options as > >>> described in IPFIX-PROTO? > >> > >> > >> What do you suggest? Also, I'd like to reduce repetition from the protocol draft. You shouldn't explain how options work here, just reference the relevant section of [IPFIX-PROTO]. > > Well it seems that section three really explains almost the same > > thing 3 times. The section 4 explains most of it again (with a > > bit more info) another 3 times. > > I would prefer section 3 to simply explain the technique. Walk > > through how the information from a Flow is split into two parts, > > and then add the bit from section 4 how these two parts are > > exported. > > > > Using more than one CPid in a record should be part of the > > advanced techniques once the basics are made clear. Per packet > > should just be a detailed example at the end. > > > > I propose the following change: > > section three is split in just two sections: uique data reduction and > multiple data reduction. In the introductory part of section three we > write something like: You don't need to repeat how this works for "multiple data reduction". It works in the same way, but you have 2 cpIDs. Get the basics clear first and then expand on it later. > The PSAMP specifications are used for the export of per-packet > information, exporting the specific observed packet in an IPFIX Flow > Record. This can be considered as a special Flow Record case, composed > of a single packet. Therefore, the method described in this document is > applicable to per packet data reduction, e.g. for export of One Way > Delay (OWD) measurements (see Appendix), trajectory sampling, etc. > > The text on OWD can be moved to the Appendix, where we describe in > detail the OWD example. Moving the per-packet stuff to a detailed example in the Appendix sounds like a good idea to me. Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 04:09:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsFEY-0007my-3T; Thu, 07 Dec 2006 04:08:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsFEX-0007mm-1y for ipfix@ietf.org; Thu, 07 Dec 2006 04:08:01 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsFE3-0005et-IE for ipfix@ietf.org; Thu, 07 Dec 2006 04:08:01 -0500 Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A2FE913CF82 for ; Thu, 7 Dec 2006 10:11:55 +0100 (CET) Date: Thu, 07 Dec 2006 10:07:29 +0100 From: Juergen Quittek To: ipfix@ietf.org Message-ID: <9E6E4DC086F2E592C536245C@n-quittek2.office> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [IPFIX] draft minutes of the IPFIX session in San Diego X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear all, Please find draft minutes of our session in San Diego at Many thanks to Ralf Wolter for taking minutes! Please check them and send your comments or requests for changes. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 4342-115 NEC Europe Ltd., Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 04:09:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsFEY-0007my-3T; Thu, 07 Dec 2006 04:08:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsFEX-0007mm-1y for ipfix@ietf.org; Thu, 07 Dec 2006 04:08:01 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsFE3-0005et-IE for ipfix@ietf.org; Thu, 07 Dec 2006 04:08:01 -0500 Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A2FE913CF82 for ; Thu, 7 Dec 2006 10:11:55 +0100 (CET) Date: Thu, 07 Dec 2006 10:07:29 +0100 From: Juergen Quittek To: ipfix@ietf.org Message-ID: <9E6E4DC086F2E592C536245C@n-quittek2.office> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [IPFIX] draft minutes of the IPFIX session in San Diego X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear all, Please find draft minutes of our session in San Diego at Many thanks to Ralf Wolter for taking minutes! Please check them and send your comments or requests for changes. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 4342-115 NEC Europe Ltd., Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 07:39:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsIW7-0006OW-BN; Thu, 07 Dec 2006 07:38:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsIW5-0006Kr-1e for ipfix@ietf.org; Thu, 07 Dec 2006 07:38:21 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsIRw-0001YA-CB for ipfix@ietf.org; Thu, 07 Dec 2006 07:34:06 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB7CY3J16092; Thu, 7 Dec 2006 13:34:03 +0100 (CET) Received: from [10.61.82.49] (ams3-vpn-dhcp4658.cisco.com [10.61.82.49]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB7CY0W05982; Thu, 7 Dec 2006 13:34:00 +0100 (CET) Message-ID: <45780A37.8010905@cisco.com> Date: Thu, 07 Dec 2006 13:33:59 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> In-Reply-To: <457620B4.3080800@cisco.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 22dac05068499bb8ac058f0e1f7e0b17 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0021560747==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0021560747== Content-Type: multipart/alternative; boundary="------------050900090903090402000006" This is a multi-part message in MIME format. --------------050900090903090402000006 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-bru.cisco.com id kB7CY3J16092 Andrew, > >>> Do we have to mention PSAMP so much anyway, >>> as it's just a specialised use case of IPFIX? >> >> Right, I think that the previous version was somehow lacking some=20 >> information. >> Yes we can use this mechanism for all sort of flows, even for: >> "So the PSAMP export can be seen as special IPFIX Flow Record=20 >> containing information about a single packet." dixit PSAMP-PROTO >> However, by having the clear distinctions... >> >> 3.1 Per Flow Data Reduction...............................11 >> 3.1.1 Unique Data Reduction..................................11 >> 3.1.2 Multiple Data Reduction................................12 >> 3.2 Per Packet Data Reduction.............................13 >> ... I believe that we gained in clarity... Maybe not for you, as you=20 >> know enough about IPFIX and PSAMP to understand how to apply this=20 >> techniques, but for the rest of the community. > > It seems that 3.2 doesn't add anything to 3.1.1 other than providing > another example. Perhaps remove the per-packet stuff from the main > part of the draft but keep it as a detailed example at the end. > > >>> Since a flow is defined as a group of packets that share >>> a set of common properties, i.e. key fields, is there >>> any danger that the commonPropertiesID will be wrongly >>> assumed to refer to only the complete set of key fields? >> >> By definition, I think this is impossible. The flow key definition=20 >> says "Each of the fields which are used to define a Flow are termed=20 >> Flow Keys.". So there is nothing in common between flows. However, I=20 >> understand your concern for novice readers. >> >> OLD section 1 "Introduction" >> >> Regardless of the fields content, flow records with common =20 >> properties export the same fields in every single flow record. =20 >> These common properties may represent values common to a=20 >> collection of flows or packets, or values that are invariant=20 >> over time. The reduction of redundant data from the export=20 >> stream can result in a significant reduction of the transferred=20 >> data. >> >> NEW section 1 "Introduction" >> >> Regardless of the fields content, flow records with common =20 >> properties export the same fields in every single flow record. =20 >> These common properties may represent values common to a collection =20 >> of flows or packets, or values that are invariant over time. Note =20 >> that the common properties don't represent the list of flow keys,=20 >> which are used to define a flow definition: however, the common=20 >> properties may contain some of the flow keys. The reduction of=20 >> redundant data from the export stream can result in a significant=20 >> reduction of the transferred data. > > My concern wasn't really directed at the draft itself, but just the > name "common properties". From IPFIX-PROTO: > "A Flow is defined as a set of IP packets passing an Observation =20 > Point in the network during a certain time interval. All packets =20 > belonging to a particular Flow have a set of common properties." > > And then from IPFIX-INFO: > Description of commonPropertiesId: > An identifier of a set of common properties that is unique per > Observation Domain. Typically, this Information Element is used > to link to information reported in separate records. > > The terminology is almost identical. The commonPropertiesId refers > to "a set of common properties" that is quite different from ones > that determine a Flow. What about something such as? Description of commonPropertiesId: An identifier of a set of common properties between different Flows. The that is unique per Observation Domain.=20 Typically, this Information Element is used to link to information reported in separate records. > > >>> Is there any need to define a new term for "Specific >>> Properties"? These are just part of a normal Data Record. >>> For example: >>> "... The rows are then referenced by the Specific Properties >>> by using the appropriate value for the Common Properties >>> identifier." >>> >>> could simply be: >>> "... The rows are then referenced by Data Records by >>> using the appropriate value for the Common Properties >>> identifier." >> >> In your example, the "Data Records" doesn't mean the full data=20 >> records before applying the redundancy reduction mechanism but only a=20 >> part of it. >> So it might be confusing... That's the trick we found. >> >> However, I could agree that the draft would work without a formal=20 >> (upper case) definition.... So do you have the same idea for the=20 >> Common Properties? > > Considering there is a commonPropertiesID, I am quite happy with you > referring to Common Properties. Ok. So let's see how the draft looks like if we remove the "Specific=20 Properties" formal definition but if we keep the "Common Properties" one. > > There seems to be a bit of a conceptual difference here though. You > seem to imagine that an Exporting Process has a set of IPFIX Data > Records which it then applies some processing to to get some new > special IPFIX Data Records and some Common Property options. The > original set of Data Records may never actually exist, depending on > how the scheme is implemented. =20 Sure, this is an implementation detail, but conceptually, we want to=20 reduce "something". How do you call this "something"? This document describes a bandwidth saving method for exporting flow=20 or packet information using the IP Flow Information Export (IPFIX)=20 protocol. Anyway, I think that we're diverging from your initial issue which was ab= out "Specific Properties"... > For me, the only set of IPFIX Data > Records to consider are the ones which are actually sent. > > >>> Are option withdrawal messages part of IPFIX? >> Yes. IPFIX says: "The Set ID field MUST contain the value 2 for=20 >> Template Set withdrawal and the value 3 for Options Template Set=20 >> withdrawal." >> Unless you want to say an option data record withdrawal message? > > There is a distinct difference between withdrawing the template and > withdrawing the data record associated with an option template. I > think that the concept works though, although perhaps not by design. Agreed. > > >> Note: I discovered that the draft still contains: "Option Data Record" >> This term has been removed from IPFIX-PROTO. So it should be removed=20 >> in this draft. >> >>> Are they meaningful in IPFIX? i.e. per the PROTO will an option >>> with scope but no data be deemed invalidated by the Collector. >>> Scope without data is the same as never having recieved the >>> mapping in the first place. I think that it would be up to the >>> implementation but it seems like a good idea so if we can't add >>> it to the PROTO can we put it in the implementation guidelines? >>> >>> How do you propose to withdraw common properties when they are >>> associated with a template rather than the Common Properties index? >> >> I don't ;) This is the reason why the use the Common Properties index=20 >> is a cleaner design. > > I think withdrawal messages should work in general for options > data, so why not send an empty record with the template as scope? I guess that you wanted to say: I think withdrawal messages should work in general for options data, so why not send an empty record with the _common property_ as=20 scope? Well, I prefer to have a clear design so that this draft is really=20 independent, with its withdrawal mechanism. Otherwise, you're telling in this I-RFC the standard track IPFIX=20 protocol should consider an empty record as a withdrawal. This could be=20 true a true assumption, but this is not clearly explained/specified! > > >>> General Comments >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> I think, sections 3.1.2, 8.2 and 8.3 would be better grouped >>> into a 3.2 Advanced Techniques section. >>> >>> I think 3.2 Per Packet Data Reduction, should be removed and >>> any information that is not in section 3.1 should be added to >>> to the PSAMP example. >>> I think the the per-packet example is a good example of >>> per flow reducing redundancy and section 11.1.1 can be removed. >> See one of my previous remark about: >> >> 3.1 Per Flow Data Reduction...............................11 >> 3.1.1 Unique Data Reduction..................................11 >> 3.1.2 Multiple Data Reduction................................12 >> 3.2 Per Packet Data Reduction.............................13 >> >> Again, it's because you know the boundary between IPFIX and PSAMP > > I just don't think the repetition is necessary. Per-packet is > just a good example of the technique, the Per Packet section > doesn't seem to add any new information. > > >>> Labels for the figures would be better if they were centred. >> Agreed. >>> >>> There is all sorts of extra spacing at the end of the lines. >>> >>> >>> >>> Specific Comments >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> 2. Terminology >>> Tabbing is inconsistent in definition of "Selector": >>> (i) the Packet Content; (ii) information derived from the packet's=20 >>> treatment at the Observation Point; (iii) any selection state that=20 >>> may be maintained by the Selection Process. >>> >>> 3.1.2 Multiple Data Reduction >>> >>> I don't think this section is explained very well. From my original >>> email to Elisa and Lutz (18th Nov 2005): >>> Andrew Johnson wrote: >>>> Flows >>>> =3D=3D=3D=3D=3D >>>> Flow A: flowId 1, flowId 11, 30 packets, 6000 bytes >>>> Flow B: flowID 1, flowId 12, 50 packets, 9500 bytes >>>> Flow C: flowId 2, flowId 11, 60 packets, 8000 bytes >>>> Flow D: flowID 2, flowId 12, 10 packets, 1500 bytes >>>> >>>> Options >>>> =3D=3D=3D=3D=3D=3D=3D >>>> flowId 1 - destinationIpv4address 10.0.0.1, destinationTcpPort 80 >>>> flowId 1 - destinationIpv4address 10.0.0.5, destinationTcpPort 80 >>>> >>>> flowId 11 - sourceIpv4address 10.0.1.10, sourceTcpPort 1932 >>>> flowId 12 - sourceIpv4address 10.0.1.15, sourceTcpPort 1842 >>> >>> >>> This shows how 4 (2+2) options can be expanded to 4 combinations of >>> Data Record to reduce redundancy without the need to define 4 complet= e >>> sets of Common Properties and therefore not save any bandwidth. The >>> more options you have the better this works. 20 options (10+10) would >>> give you up to 100 possible pairs common properties. >>> >>> This isn't really made clear in the draft text, with only "flow1" >>> having two indices. >> I agree the examples in figure 4/5 don't show this. >> Maybe a new section in section 8 "Export and Evaluation Considerations= "? >>> The example in 11.1.2 doesn't even have any! >> Agreed. This should be corrected. >>> >>> While I agree that using a template that doesn't include the cpID >>> is a good idea to efficiently communicate flows with not so common >>> properties, however I would call this an "Advanced Technique" to be >>> listed in the section I proposed earlier. >>> >>> >>> 3.2 Per Packet Data Reduction >>> >>> The text reads: >>> If filtering is applied to select a series of packets, using the=20 >>> PSAMP specifications to export per-packet information might be=20 >>> relatively inefficient if the filtered fields (the common=20 >>> attributes) are exported in every single record. >>> >>> However in section 6.5.2.5 (Property Match Filtering) of PSAMP-PROTO >>> it is explained how the filter information MUST be sent. This is >>> designed so that the selector ID will match the one from the Data >>> Record (via the selectionSequenceId) and perform exactly the function >>> that is being proposed here for the commonPropertiesId. >> Good point. I would remove this paragraph and move to this place the=20 >> one starting with: >> >> An example of the per packet data reduction is the measurement of =20 >> One-Way Delay (OWD), where the exact same specific packet must be =20 >> observed at the source and destination of the path to be measured. =20 >> By subtracting ... >> >>> >>> >>> 4. Specifications for bandwidth saving information export >>> >>> What is being specified here that isn't true for ALL options as >>> described in IPFIX-PROTO? >> >> What do you suggest? > > Well it seems that section three really explains almost the same > thing 3 times. The section 4 explains most of it again (with a > bit more info) another 3 times. > > I would prefer section 3 to simply explain the technique. Walk > through how the information from a Flow is split into two parts, > and then add the bit from section 4 how these two parts are > exported. > > Using more than one CPid in a record should be part of the > advanced techniques once the basics are made clear. Per packet > should just be a detailed example at the end. > >>> I think section 3 does a better job of explaining how all this >>> works. I'm really not sure what section 4 adds. >> >> The idea was to put the specs in section 4 while the section 3 was=20 >> the high level solution. > > Rereading it, I see that now, but there seems to be a fair amount > of repetition. Let me ask the question differently. Do you see this repetition as proble= m? > >>> (Aside: figure 9 refers to Common Sroperties). >> Yep. thanks. >>> >>> >>> 6. commonPropertiesID Management >>> >>> The text reads: >>> The commonPropertiesID values MAY be assigned sequentially, but it=EF= =BF=BDs >>> It seems the "it's" is using an invalid character rather than an >>> apostrophe. >>> >>> >>> 7. The Collecting Process Side >>> >>> The text reads: >>> Like TemplateIDs the commonPropertiesIDs are generated dynamically=20 >>> by the Exporting Process. Hence a restart of the Exporting Process=20 >>> may imply a renumbering of commonProperiesIDs. >>> The collector can't know if the Exporter Process restarted, this is >>> why we rescoped the commonPropertiesID to the Transport Session, so >>> the above text is now redundant. >> >> I know it's redundant, but don't you think it helps. For example, we=20 >> don't explain anywhere (if I recall correctly) that "the=20 >> commonPropertiesIDs are generated dynamically by the Exporting Process= " > > The commonPropertiesIDs are unique within the transport session. If th= e > session is restarted then you've lost that scope and therefore can't > keep using the same commonPropertiesID mappings. > > I don't see why the commonPropertiesIDs have to be dynamically generate= d > by the Exporting Process. The could be shared between several EPs or > pre-calculated based in historical data from that Observation Domain. Fine. > > >>> The text reads: >>> Common Properties IDs are unique per SCTP association and per=20 >>> Observation Domain. If the Collecting Process receives a common=20 >>> Properties ID which has already been received but which has not=20 >>> previously been withdrawn (i.e. a commonPropertiesID from the same=20 >>> Exporter Observation Domain with the same Template ID received on=20 >>> the SCTP association), then the Collecting Process MUST shutdown the=20 >>> association. >> This is similar to [IPFIX-PROTO] >> >> Template IDs are unique per SCTP association and per Observation =20 >> Domain. If the Collecting Process receives a Template which has =20 >> already been received but which has not previously been withdrawn =20 >> (i.e. a Template Record from the same Exporter Observation Domain =20 >> with the same Template ID received on the SCTP association), then =20 >> the Collecting Process MUST shutdown the association. >> >>> >>> and: >>> If the Collecting Process receives a Common Properties Withdrawal=20 >>> message for a Common Properties that it has not received before on=20 >>> this SCTP assocation, it MUST reset the SCTP association, discard=20 >>> the IPFIX Message, and SHOULD log the error as it does for malformed=20 >>> IPFIX Messages. >>> I think this might go against IPFIX-PROTO. >> This is similar to [IPFIX-PROTO] > > These are similar to what IPFIX-PROTO says about templates, but that > doesn't mean the text can just be used to talk about Data Records sent > for Options Templates. > > Option data withdrawal messages are not mentioned in IPFIX-PROTO, > although I think they can work. However, in general options data with > the same scope as an earlier record will just overwrite the older > record. See my previous remark about an independent draft. > > >> If the Collecting Process receives a Template Withdraw message for=20 >> a Template Record it has not received before on this SCTP=20 >> assocation, it MUST reset the SCTP association, discard the IPFIX=20 >> Message, and SHOULD log the error as it does for malformed IPFIX=20 >> Messages. >>> >>> >>> The text reads: >>> If the Common Properties are not refreshed before that lifetime=20 >>> has expired, the Collecting Process MUST discard the corresponding=20 >>> definition of the commonPropertiesID and any current and future =20 >>> associated Data Records. In which case, an alarm MUST be logged. >>> What happened to storing it until the option turned up. Furthermore >>> you shouldn't dictate the the record is discarded, just because you >>> can't tell a piece of potentially trivial information about a flow >>> doesn't mean it's meaningless. The Common Properties in question >>> could be anything. >>> >> This is similar to [IPFIX-PROTO] >> >> If the Template (or other definition) is not refreshed before that=20 >> lifetime has expired, the Collecting Process MUST discard that=20 >> definition and any current and future associated Data Records. In=20 >> which case, an alarm MUST be logged. > > This "(or other definition)" stuff is only mentioned for the Collecting > Process and it really isn't clear if it should apply to Common > Properties. =20 In this draft, we require a mechanism such as the following: "If the Common Properties are not refreshed before that lifetime has =20 expired, the Collecting Process MUST discard the corresponding =20 definition of the commonPropertiesID and any current and future =20 associated Data Records. In which case, an alarm MUST be logged. " Because there is no withdraw message with UDP: " If UDP is selected as the transport protocol, the commonPropertiesID Template Withdraw Messages MUST not be used, as this method is inefficient due to the unreliable nature of UDP." So I'm wondering why we are discussing this? Let me come back to your questions: Q: What happened to storing it until the option turned up. A: If the Collecting Process has received the Specific Properties Data=20 Record before the associated Common Properties Data Record, the=20 Collecting Process MAY store the Specific Properties Data Record and=20 await the retransmission or out-of-order arrival of the Common=20 Properties Data Record. =20 Q: Furthermore you shouldn't dictate the the record is discarded, just=20 because you can't tell a piece of potentially trivial information about a flow doesn't mean it's meaningless. A: without the Common Properties, we can't decode the records. So we=20 must discard them Q: The Common Properties in question could be anything. A: I think we should limit this draft to Common Properties > However, storing the data records in a queue awaiting > the decode information is really only something that is expected to > be done at the start of the session. Is it mentioned in this draft? > > >>> Besides, we're not changing the protocol here, right? >> Right. So this is not an IPFIX redundancy reduction issue but an=20 >> IPFIX protocol issue... as we don't want to change the protocol with=20 >> this draft. > > What's a protocol issue? I think applying all the requirements of > templates to all options is changing the protocol. > > >>> 8.1 Transport Protocol Choice The text reads: >>> The proposed method is most effective using a reliable transport=20 >>> protocol for the transfer of the Common Properties. Therefore the=20 >>> use of SCTP or TCP is recommended. >>> >>> Note that SCTP isn't necessarily reliable. >> SCTP -> PR-SCTP with the reliable mode >>> >>> >>> 8.3 commonPropertiesID vs. TemplateID scope >>> Additional flow properties can be tied to almost any I.E. For example >>> a particular interface could be associated with the one IP address it >>> serves. >> That's true but I still think the design is cleaner with the Common=20 >> Properties Id. >> See the remark about the Common Properties ID withdrawal > > You can withdraw any option record, so I don't think it's a big deal. > > Regards, Benoit --------------050900090903090402000006 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-bru.cisco.com id kB7CY3J16092 Andrew,

Do we have to mention PSAMP so much anyway,
as it's just a specialised use case of IPFIX?

Right, I think that the previous version was somehow lacking some information.
Yes we can use this mechanism for all sort of flows, even for:
"So the PSAMP export can be seen as special IPFIX Flow Record containing information about a single packet." dixit PSAMP-PROTO
However, by having the clear distinctions...

=C2=A03.1=C2=A0=C2=A0=C2=A0=C2=A0 Per Flow Data Reduction................= ...............11
=C2=A03.1.1=C2=A0 Unique Data Reduction..................................= 11
=C2=A03.1.2=C2=A0 Multiple Data Reduction................................= 12
=C2=A03.2=C2=A0=C2=A0=C2=A0=C2=A0 Per Packet Data Reduction..............= ...............13
... I believe that we gained in clarity... Maybe not for you, as you know enough about IPFIX and PSAMP to understand how to apply this techniques, but for the rest of the community.

It seems that 3.2 doesn't add anything to 3.1.1 other than providing
another example.=C2=A0 Perhaps remove the per-packet stuff from the main
part of the draft but keep it as a detailed example at the end.


Since a flow is defined as a group of packets that share
a set of common properties, i.e. key fields, is there
any danger that the commonPropertiesID will be wrongly
assumed to refer to only the complete set of key fields?

By definition, I think this is impossible. The flow key definition says "Each of the fields which are used to define a Flow are termed Flow Keys.". So there is nothing in common between flows. However, I understand your concern for novice readers.

OLD section 1 "Introduction"

=C2=A0=C2=A0=C2=A0 Regardless of the fields content, flow records with co= mmon=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 properties export the same fields in every single flow record.=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 These common properties may represent values common to a collection=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of flows or packets, or values t= hat are invariant over time.=C2=A0 The=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reduction of redundant data= from the export stream can result in a=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 significant reduction of the tr= ansferred data.

NEW section 1 "Introduction"

=C2=A0Regardless of the fields content, flow records with common=C2=A0=C2= =A0 properties export the same fields in every single flow record.=C2=A0=C2=A0= =C2=A0 These common properties may represent values common to a collection=C2=A0=C2=A0= of flows or packets, or values that are invariant over time.=C2=A0 Note=C2=A0= =C2=A0 that the common properties don't represent the list of flow keys, which=C2=A0=C2= =A0 are used to define a flow definition: however, the common properties=C2=A0= =C2=A0 may contain some of the flow keys. The reduction of redundant data from=C2=A0=C2=A0 the export stream can result in a significant reduction = of the=C2=A0=C2=A0 transferred data.

My concern wasn't really directed at the draft itself, but just the
name "common properties".=C2=A0 From IPFIX-PROTO:
=C2=A0"A Flow is defined as a set of IP packets passing an Observation =C2= =A0 Point in the network during a certain time interval.=C2=A0 All packets =C2= =A0 belonging to a particular Flow have a set of common properties."

And then from IPFIX-INFO:
=C2=A0 Description of commonPropertiesId:
=C2=A0=C2=A0=C2=A0=C2=A0 An identifier of a set of common properties that= is unique per
=C2=A0=C2=A0=C2=A0=C2=A0 Observation Domain.=C2=A0 Typically, this Inform= ation Element is used
=C2=A0=C2=A0=C2=A0=C2=A0 to link to information reported in separate reco= rds.

The terminology is almost identical.=C2=A0 The commonPropertiesId refers
to "a set of common properties" that is quite different from ones
that determine a Flow.
What about something such as?
Description of commonPropertiesId:
=C2=A0=C2=A0=C2=A0=C2=A0 An identifier of a set of common properties betw= een different Flows.
=C2=A0=C2=A0=C2=A0=C2=A0 The that is unique per Observation Domain.=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 Typically, this Information Element is used
=C2=A0=C2=A0=C2=A0=C2=A0 to link to information reported in separate reco= rds.


Is there any need to define a new term for "Specific
Properties"? These are just part of a normal Data Record.
For example:
"... The rows are then referenced by the Specific Properties
by using the appropriate value for the Common Properties
identifier."

could simply be:
"... The rows are then referenced by Data Records by
using the appropriate value for the Common Properties
identifier."

In your example, the "Data Records" doesn't mean the full data records before applying the redundancy reduction mechanism but only a part of it.
So it might be confusing... That's the trick we found.

However, I could agree that the draft would work without a formal (upper case) definition.... So do you have the same idea for the Common Properties?

Considering there is a commonPropertiesID, I am quite happy with you
referring to Common Properties.
Ok. So let's see how the draft looks like if we remove the "Specific Properties" formal definition but if we keep the "Common Properties" one.

There seems to be a bit of a conceptual difference here though.=C2=A0 You
seem to imagine that an Exporting Process has a set of IPFIX Data
Records which it then applies some processing to to get some new
special IPFIX Data Records and some Common Property options.=C2=A0 The
original set of Data Records may never actually exist, depending on
how the scheme is implemented.=C2=A0
Sure, this is an implementation detail, but conceptually, we want to reduce "something". How do you call this "something"?
   This document describes a bandwidth saving method for exporting f=
low=20
   or packet information using the IP Flow Information Export (IPFIX)=20
   protocol.

Anyway, I think that we're diverging from your initial issue which was ab=
out "Specific
Properties"...

For me, the only set of IPFIX Data
Records to consider are the ones which are actually sent.



Are option withdrawal messages part of IPFIX?
Yes. IPFIX says: "The Set ID field MUST contain the value 2 for Template Set withdrawal and the value 3 for Options Template Set withdrawal."
Unless you want to say an option data record withdrawal message?

There is a distinct difference between withdrawing the template and
withdrawing the data record associated with an option template.=C2=A0 I
think that the concept works though, although perhaps not by design.
Agreed.


Note: I discovered that the draft still contains: "Option Data Record"
This term has been removed from IPFIX-PROTO. So it should be removed in this draft.

Are they meaningful in IPFIX? i.e. per the PROTO will an option
with scope but no data be deemed invalidated by the Collector.
Scope without data is the same as never having recieved the
mapping in the first place. I think that it would be up to the
implementation but it seems like a good idea so if we can't add
it to the PROTO can we put it in the implementation guidelines?

How do you propose to withdraw common properties when they are
associated with a template rather than the Common Properties index?

I don't ;) This is the reason why the use the Common Properties index is a cleaner design.

I think withdrawal messages should work in general for options
data, so why not send an empty record with the template as scope?
I guess that you wanted to say:
=C2=A0=C2=A0=C2=A0 I think withdrawal messages should work in general for= options
=C2=A0=C2=A0=C2=A0 data, so why not send an empty record with the comm= on property as scope?
Well, I prefer to have a clear design so that this draft is really independent, with its withdrawal mechanism.
Otherwise, you're telling in this I-RFC the standard track IPFIX protocol should consider an empty record as a withdrawal. This could be true a true assumption, but this is not clearly explained/specified!


General Comments
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I think, sections 3.1.2, 8.2 and 8.3 would be better grouped
into a 3.2 Advanced Techniques section.

I think 3.2 Per Packet Data Reduction, should be removed and
any information that is not in section 3.1 should be added to
to the PSAMP example.
I think the the per-packet example is a good example of
per flow reducing redundancy and section 11.1.1 can be removed.
See one of my previous remark about:

=C2=A03.1=C2=A0=C2=A0=C2=A0 Per Flow Data Reduction......................= .........11
=C2=A03.1.1 Unique Data Reduction..................................11
=C2=A03.1.2 Multiple Data Reduction................................12
=C2=A03.2=C2=A0=C2=A0=C2=A0 Per Packet Data Reduction....................= .........13

Again, it's because you know the boundary between IPFIX and PSAMP

I just don't think the repetition is necessary.=C2=A0 Per-packet is
just a good example of the technique, the Per Packet section
doesn't seem to add any new information.


Labels for the figures would be better if they were centred.
Agreed.

There is all sorts of extra spacing at the end of the lines.



Specific Comments
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
2. Terminology
Tabbing is inconsistent in definition of "Selector":
(i) the Packet Content; (ii) information derived from the packet's treatment at the Observation Point; (iii) any selection state that may be maintained by the Selection Process.

3.1.2 Multiple Data Reduction

I don't think this section is explained very well. From my original
email to Elisa and Lutz (18th Nov 2005):
Andrew Johnson wrote:
Flows
=3D=3D=3D=3D=3D
Flow A: flowId 1, flowId 11, 30 packets, 6000 bytes
Flow B: flowID 1, flowId 12, 50 packets, 9500 bytes
Flow C: flowId 2, flowId 11, 60 packets, 8000 bytes
Flow D: flowID 2, flowId 12, 10 packets, 1500 bytes

Options
=3D=3D=3D=3D=3D=3D=3D
flowId 1 - destinationIpv4address 10.0.0.1, destinationTcpPort 80
flowId 1 - destinationIpv4address 10.0.0.5, destinationTcpPort 80

flowId 11 - sourceIpv4address 10.0.1.10, sourceTcpPort 1932
flowId 12 - sourceIpv4address 10.0.1.15, sourceTcpPort 1842


This shows how 4 (2+2) options can be expanded to 4 combinations of
Data Record to reduce redundancy without the need to define 4 complete
sets of Common Properties and therefore not save any bandwidth. The
more options you have the better this works. 20 options (10+10) would
give you up to 100 possible pairs common properties.

This isn't really made clear in the draft text, with only "flow1"
having two indices.
I agree the examples in figure 4/5 don't show this.
Maybe a new section in section 8 "Export and Evaluation Considerations"?
The example in 11.1.2 doesn't even have any!
Agreed. This should be corrected.

While I agree that using a template that doesn't include the cpID
is a good idea to efficiently communicate flows with not so common
properties, however I would call this an "Advanced Technique" to be
listed in the section I proposed earlier.


3.2 Per Packet Data Reduction

The text reads:
If filtering is applied to select a series of packets, using the PSAMP specifications to export per-packet information might be relatively inefficient if the filtered fields (the common attributes) are exported in every single record.

However in section 6.5.2.5 (Property Match Filtering) of PSAMP-PROTO
it is explained how the filter information MUST be sent. This is
designed so that the selector ID will match the one from the Data
Record (via the selectionSequenceId) and perform exactly the function
that is being proposed here for the commonPropertiesId.
Good point. I would remove this paragraph and move to this place the one starting with:

=C2=A0An example of the per packet data reduction is the measurement of=C2= =A0 =C2=A0One-Way Delay (OWD), where the exact same specific packet must be=C2= =A0 =C2=A0observed at the source and destination of the path to be measured.=C2= =A0=C2=A0 By subtracting ...



4. Specifications for bandwidth saving information export

What is being specified here that isn't true for ALL options as
described in IPFIX-PROTO?

What do you suggest?

Well it seems that section three really explains almost the same
thing 3 times.=C2=A0 The section 4 explains most of it again (with a
bit more info) another 3 times.

I would prefer section 3 to simply explain the technique.=C2=A0 Walk
through how the information from a Flow is split into two parts,
and then add the bit from section 4 how these two parts are
exported.

Using more than one CPid in a record should be part of the
advanced techniques once the basics are made clear.=C2=A0 Per packet
should just be a detailed example at the end.

I think section 3 does a better job of explaining how all this
works. I'm really not sure what section 4 adds.

The idea was to put the specs in section 4 while the section 3 was the high level solution.

Rereading it, I see that now, but there seems to be a fair amount
of repetition.
Let me ask the question differently. Do you see this repetition as problem?

(Aside: figure 9 refers to Common Sroperties).
Yep. thanks.


6. commonPropertiesID Management

The text reads:
The commonPropertiesID values MAY be assigned sequentially, but it=EF=BF=BD= s
It seems the "it's" is using an invalid character rather than an
apostrophe.


7. The Collecting Process Side

The text reads:
Like TemplateIDs the commonPropertiesIDs are generated dynamically by the Exporting Process. Hence a restart of the Exporting Process may imply a renumbering of commonProperiesIDs.
The collector can't know if the Exporter Process restarted, this is
why we rescoped the commonPropertiesID to the Transport Session, so
the above text is now redundant.

I know it's redundant, but don't you think it helps. For example, we don't explain anywhere (if I recall correctly) that "the commonPropertiesIDs are generated dynamically by the Exporting Process"

The commonPropertiesIDs are unique within the transport session.=C2=A0 If the
session is restarted then you've lost that scope and therefore can't
keep using the same commonPropertiesID mappings.

I don't see why the commonPropertiesIDs have to be dynamically generated
by the Exporting Process.=C2=A0 The could be shared between several EPs o= r
pre-calculated based in historical data from that Observation Domain.
Fine.


The text reads:
Common Properties IDs are unique per SCTP association and per Observation Domain. If the Collecting Process receives a common Properties ID which has already been received but which has not previously been withdrawn (i.e. a commonPropertiesID from the same Exporter Observation Domain with the same Template ID received on the SCTP association), then the Collecting Process MUST shutdown the association.
This is similar to [IPFIX-PROTO]

=C2=A0Template IDs are unique per SCTP association and per Observation=C2= =A0 =C2=A0Domain.=C2=A0 If the Collecting Process receives a Template which h= as=C2=A0 =C2=A0already been received but which has not previously been withdrawn=C2= =A0=C2=A0=C2=A0 (i.e. a Template Record from the same Exporter Observation Domain=C2=A0=C2= =A0=C2=A0=C2=A0 with the same Template ID received on the SCTP association), then=C2=A0=C2= =A0=C2=A0 the Collecting Process MUST shutdown the association.


and:
If the Collecting Process receives a Common Properties Withdrawal message for a Common Properties that it has not received before on this SCTP assocation, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error as it does for malformed IPFIX Messages.
I think this might go against IPFIX-PROTO.
This is similar to [IPFIX-PROTO]

These are similar to what IPFIX-PROTO says about templates, but that
doesn't mean the text can just be used to talk about Data Records sent
for Options Templates.

Option data withdrawal messages are not mentioned in IPFIX-PROTO,
although I think they can work.=C2=A0 However, in general options data wi= th
the same scope as an earlier record will just overwrite the older
record.
See my previous remark about an independent draft.


=C2=A0If the Collecting Process receives a Template Withdraw message for a=C2=A0 =C2=A0Template Record it has not re= ceived before on this SCTP assocation,=C2=A0=C2=A0=C2=A0 it MUST reset the SCTP = association, discard the IPFIX Message, and=C2=A0=C2=A0=C2=A0 SHOULD log the error as = it does for malformed IPFIX Messages.


The text reads:
=C2=A0 If the Common Properties are not refreshed before that lifetime ha= s =C2=A0 expired, the Collecting Process MUST discard the corresponding =C2=A0 definition of the commonPropertiesID and any current and future =C2=A0 associated Data Records. In which case, an alarm MUST be logged.
What happened to storing it until the option turned up. Furthermore
you shouldn't dictate the the record is discarded, just because you
can't tell a piece of potentially trivial information about a flow
doesn't mean it's meaningless. The Common Properties in question
could be anything.

This is similar to [IPFIX-PROTO]

=C2=A0If the Template=C2=A0=C2=A0 (or other definition) is not refreshed = before that lifetime has=C2=A0=C2=A0 expired, the Collecting Process MUST discard tha= t definition and any=C2=A0=C2=A0 current and future associated Data Records= .=C2=A0 In which case, an alarm=C2=A0=C2=A0 MUST be logged.

This "(or other definition)" stuff is only mentioned for the Collecting
Process and it really isn't clear if it should apply to Common
Properties.=C2=A0
In this draft, we require a mechanism such as the following:
"If the Common Properties are not refreshed before that lifetime has =C2=A0 expired, the Collecting Process MUST discard the corresponding =C2=A0 definition of the commonPropertiesID and any current and future =C2=A0 associated Data Records. In which case, an alarm MUST be logged. "
Because there is no withdraw message with UDP:
" If UDP is selected as the transport protocol, the commonPropertiesID =C2=A0 Template Withdraw Messages MUST not be used, as this method is =C2=A0 inefficient due to the unreliable nature of UDP."
So I'm wondering why we are discussing this?

Let me come back to your questions:
Q: What happened to storing it until the option turned up.
A: 
   If the Collecting Process has received the Specific Properties Da=
ta=20
   Record before the associated Common Properties Data Record, the=20
   Collecting Process MAY store the Specific Properties Data Record and=20
   await the retransmission or out-of-order arrival of the Common=20
   Properties Data Record.

Q: Furthermore you shouldn't dictate the the record is discarded, just because you
can't tell a piece of potentially trivial information about a flow
doesn't mean it's meaningless.
A: without the Common Properties, we can't decode the records. So we must discard them

Q: The Common Properties in question could be anything.
A: I think we should limit this draft to Common Properties
However, storing the data records in a queue awaiting
the decode information is really only something that is expected to
be done at the start of the session.=C2=A0 Is it mentioned in this draft?


Besides, we're not changing the protocol here, right?
Right. So this is not an IPFIX redundancy reduction issue but an IPFIX protocol issue... as we don't want to change the protocol with this draft.

What's a protocol issue?=C2=A0 I think applying all the requirements of
templates to all options is changing the protocol.


8.1 Transport Protocol Choice The text reads:
The proposed method is most effective using a reliable transport protocol for the transfer of the Common Properties. Therefore the use of SCTP or TCP is recommended.

Note that SCTP isn't necessarily reliable.
SCTP -> PR-SCTP with the reliable mode


8.3 commonPropertiesID vs. TemplateID scope
Additional flow properties can be tied to almost any I.E. For example
a particular interface could be associated with the one IP address it
serves.
That's true but I still think the design is cleaner with the Common Properties Id.
See the remark about the Common Properties ID withdrawal

You can withdraw any option record, so I don't think it's a big deal.


Regards, Benoit
--------------050900090903090402000006-- --===============0021560747== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============0021560747==-- From ipfix-bounces@ietf.org Thu Dec 07 07:39:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsIW7-0006OW-BN; Thu, 07 Dec 2006 07:38:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsIW5-0006Kr-1e for ipfix@ietf.org; Thu, 07 Dec 2006 07:38:21 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsIRw-0001YA-CB for ipfix@ietf.org; Thu, 07 Dec 2006 07:34:06 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB7CY3J16092; Thu, 7 Dec 2006 13:34:03 +0100 (CET) Received: from [10.61.82.49] (ams3-vpn-dhcp4658.cisco.com [10.61.82.49]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB7CY0W05982; Thu, 7 Dec 2006 13:34:00 +0100 (CET) Message-ID: <45780A37.8010905@cisco.com> Date: Thu, 07 Dec 2006 13:33:59 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> In-Reply-To: <457620B4.3080800@cisco.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 22dac05068499bb8ac058f0e1f7e0b17 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0021560747==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0021560747== Content-Type: multipart/alternative; boundary="------------050900090903090402000006" This is a multi-part message in MIME format. --------------050900090903090402000006 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-bru.cisco.com id kB7CY3J16092 Andrew, > >>> Do we have to mention PSAMP so much anyway, >>> as it's just a specialised use case of IPFIX? >> >> Right, I think that the previous version was somehow lacking some=20 >> information. >> Yes we can use this mechanism for all sort of flows, even for: >> "So the PSAMP export can be seen as special IPFIX Flow Record=20 >> containing information about a single packet." dixit PSAMP-PROTO >> However, by having the clear distinctions... >> >> 3.1 Per Flow Data Reduction...............................11 >> 3.1.1 Unique Data Reduction..................................11 >> 3.1.2 Multiple Data Reduction................................12 >> 3.2 Per Packet Data Reduction.............................13 >> ... I believe that we gained in clarity... Maybe not for you, as you=20 >> know enough about IPFIX and PSAMP to understand how to apply this=20 >> techniques, but for the rest of the community. > > It seems that 3.2 doesn't add anything to 3.1.1 other than providing > another example. Perhaps remove the per-packet stuff from the main > part of the draft but keep it as a detailed example at the end. > > >>> Since a flow is defined as a group of packets that share >>> a set of common properties, i.e. key fields, is there >>> any danger that the commonPropertiesID will be wrongly >>> assumed to refer to only the complete set of key fields? >> >> By definition, I think this is impossible. The flow key definition=20 >> says "Each of the fields which are used to define a Flow are termed=20 >> Flow Keys.". So there is nothing in common between flows. However, I=20 >> understand your concern for novice readers. >> >> OLD section 1 "Introduction" >> >> Regardless of the fields content, flow records with common =20 >> properties export the same fields in every single flow record. =20 >> These common properties may represent values common to a=20 >> collection of flows or packets, or values that are invariant=20 >> over time. The reduction of redundant data from the export=20 >> stream can result in a significant reduction of the transferred=20 >> data. >> >> NEW section 1 "Introduction" >> >> Regardless of the fields content, flow records with common =20 >> properties export the same fields in every single flow record. =20 >> These common properties may represent values common to a collection =20 >> of flows or packets, or values that are invariant over time. Note =20 >> that the common properties don't represent the list of flow keys,=20 >> which are used to define a flow definition: however, the common=20 >> properties may contain some of the flow keys. The reduction of=20 >> redundant data from the export stream can result in a significant=20 >> reduction of the transferred data. > > My concern wasn't really directed at the draft itself, but just the > name "common properties". From IPFIX-PROTO: > "A Flow is defined as a set of IP packets passing an Observation =20 > Point in the network during a certain time interval. All packets =20 > belonging to a particular Flow have a set of common properties." > > And then from IPFIX-INFO: > Description of commonPropertiesId: > An identifier of a set of common properties that is unique per > Observation Domain. Typically, this Information Element is used > to link to information reported in separate records. > > The terminology is almost identical. The commonPropertiesId refers > to "a set of common properties" that is quite different from ones > that determine a Flow. What about something such as? Description of commonPropertiesId: An identifier of a set of common properties between different Flows. The that is unique per Observation Domain.=20 Typically, this Information Element is used to link to information reported in separate records. > > >>> Is there any need to define a new term for "Specific >>> Properties"? These are just part of a normal Data Record. >>> For example: >>> "... The rows are then referenced by the Specific Properties >>> by using the appropriate value for the Common Properties >>> identifier." >>> >>> could simply be: >>> "... The rows are then referenced by Data Records by >>> using the appropriate value for the Common Properties >>> identifier." >> >> In your example, the "Data Records" doesn't mean the full data=20 >> records before applying the redundancy reduction mechanism but only a=20 >> part of it. >> So it might be confusing... That's the trick we found. >> >> However, I could agree that the draft would work without a formal=20 >> (upper case) definition.... So do you have the same idea for the=20 >> Common Properties? > > Considering there is a commonPropertiesID, I am quite happy with you > referring to Common Properties. Ok. So let's see how the draft looks like if we remove the "Specific=20 Properties" formal definition but if we keep the "Common Properties" one. > > There seems to be a bit of a conceptual difference here though. You > seem to imagine that an Exporting Process has a set of IPFIX Data > Records which it then applies some processing to to get some new > special IPFIX Data Records and some Common Property options. The > original set of Data Records may never actually exist, depending on > how the scheme is implemented. =20 Sure, this is an implementation detail, but conceptually, we want to=20 reduce "something". How do you call this "something"? This document describes a bandwidth saving method for exporting flow=20 or packet information using the IP Flow Information Export (IPFIX)=20 protocol. Anyway, I think that we're diverging from your initial issue which was ab= out "Specific Properties"... > For me, the only set of IPFIX Data > Records to consider are the ones which are actually sent. > > >>> Are option withdrawal messages part of IPFIX? >> Yes. IPFIX says: "The Set ID field MUST contain the value 2 for=20 >> Template Set withdrawal and the value 3 for Options Template Set=20 >> withdrawal." >> Unless you want to say an option data record withdrawal message? > > There is a distinct difference between withdrawing the template and > withdrawing the data record associated with an option template. I > think that the concept works though, although perhaps not by design. Agreed. > > >> Note: I discovered that the draft still contains: "Option Data Record" >> This term has been removed from IPFIX-PROTO. So it should be removed=20 >> in this draft. >> >>> Are they meaningful in IPFIX? i.e. per the PROTO will an option >>> with scope but no data be deemed invalidated by the Collector. >>> Scope without data is the same as never having recieved the >>> mapping in the first place. I think that it would be up to the >>> implementation but it seems like a good idea so if we can't add >>> it to the PROTO can we put it in the implementation guidelines? >>> >>> How do you propose to withdraw common properties when they are >>> associated with a template rather than the Common Properties index? >> >> I don't ;) This is the reason why the use the Common Properties index=20 >> is a cleaner design. > > I think withdrawal messages should work in general for options > data, so why not send an empty record with the template as scope? I guess that you wanted to say: I think withdrawal messages should work in general for options data, so why not send an empty record with the _common property_ as=20 scope? Well, I prefer to have a clear design so that this draft is really=20 independent, with its withdrawal mechanism. Otherwise, you're telling in this I-RFC the standard track IPFIX=20 protocol should consider an empty record as a withdrawal. This could be=20 true a true assumption, but this is not clearly explained/specified! > > >>> General Comments >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> I think, sections 3.1.2, 8.2 and 8.3 would be better grouped >>> into a 3.2 Advanced Techniques section. >>> >>> I think 3.2 Per Packet Data Reduction, should be removed and >>> any information that is not in section 3.1 should be added to >>> to the PSAMP example. >>> I think the the per-packet example is a good example of >>> per flow reducing redundancy and section 11.1.1 can be removed. >> See one of my previous remark about: >> >> 3.1 Per Flow Data Reduction...............................11 >> 3.1.1 Unique Data Reduction..................................11 >> 3.1.2 Multiple Data Reduction................................12 >> 3.2 Per Packet Data Reduction.............................13 >> >> Again, it's because you know the boundary between IPFIX and PSAMP > > I just don't think the repetition is necessary. Per-packet is > just a good example of the technique, the Per Packet section > doesn't seem to add any new information. > > >>> Labels for the figures would be better if they were centred. >> Agreed. >>> >>> There is all sorts of extra spacing at the end of the lines. >>> >>> >>> >>> Specific Comments >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> 2. Terminology >>> Tabbing is inconsistent in definition of "Selector": >>> (i) the Packet Content; (ii) information derived from the packet's=20 >>> treatment at the Observation Point; (iii) any selection state that=20 >>> may be maintained by the Selection Process. >>> >>> 3.1.2 Multiple Data Reduction >>> >>> I don't think this section is explained very well. From my original >>> email to Elisa and Lutz (18th Nov 2005): >>> Andrew Johnson wrote: >>>> Flows >>>> =3D=3D=3D=3D=3D >>>> Flow A: flowId 1, flowId 11, 30 packets, 6000 bytes >>>> Flow B: flowID 1, flowId 12, 50 packets, 9500 bytes >>>> Flow C: flowId 2, flowId 11, 60 packets, 8000 bytes >>>> Flow D: flowID 2, flowId 12, 10 packets, 1500 bytes >>>> >>>> Options >>>> =3D=3D=3D=3D=3D=3D=3D >>>> flowId 1 - destinationIpv4address 10.0.0.1, destinationTcpPort 80 >>>> flowId 1 - destinationIpv4address 10.0.0.5, destinationTcpPort 80 >>>> >>>> flowId 11 - sourceIpv4address 10.0.1.10, sourceTcpPort 1932 >>>> flowId 12 - sourceIpv4address 10.0.1.15, sourceTcpPort 1842 >>> >>> >>> This shows how 4 (2+2) options can be expanded to 4 combinations of >>> Data Record to reduce redundancy without the need to define 4 complet= e >>> sets of Common Properties and therefore not save any bandwidth. The >>> more options you have the better this works. 20 options (10+10) would >>> give you up to 100 possible pairs common properties. >>> >>> This isn't really made clear in the draft text, with only "flow1" >>> having two indices. >> I agree the examples in figure 4/5 don't show this. >> Maybe a new section in section 8 "Export and Evaluation Considerations= "? >>> The example in 11.1.2 doesn't even have any! >> Agreed. This should be corrected. >>> >>> While I agree that using a template that doesn't include the cpID >>> is a good idea to efficiently communicate flows with not so common >>> properties, however I would call this an "Advanced Technique" to be >>> listed in the section I proposed earlier. >>> >>> >>> 3.2 Per Packet Data Reduction >>> >>> The text reads: >>> If filtering is applied to select a series of packets, using the=20 >>> PSAMP specifications to export per-packet information might be=20 >>> relatively inefficient if the filtered fields (the common=20 >>> attributes) are exported in every single record. >>> >>> However in section 6.5.2.5 (Property Match Filtering) of PSAMP-PROTO >>> it is explained how the filter information MUST be sent. This is >>> designed so that the selector ID will match the one from the Data >>> Record (via the selectionSequenceId) and perform exactly the function >>> that is being proposed here for the commonPropertiesId. >> Good point. I would remove this paragraph and move to this place the=20 >> one starting with: >> >> An example of the per packet data reduction is the measurement of =20 >> One-Way Delay (OWD), where the exact same specific packet must be =20 >> observed at the source and destination of the path to be measured. =20 >> By subtracting ... >> >>> >>> >>> 4. Specifications for bandwidth saving information export >>> >>> What is being specified here that isn't true for ALL options as >>> described in IPFIX-PROTO? >> >> What do you suggest? > > Well it seems that section three really explains almost the same > thing 3 times. The section 4 explains most of it again (with a > bit more info) another 3 times. > > I would prefer section 3 to simply explain the technique. Walk > through how the information from a Flow is split into two parts, > and then add the bit from section 4 how these two parts are > exported. > > Using more than one CPid in a record should be part of the > advanced techniques once the basics are made clear. Per packet > should just be a detailed example at the end. > >>> I think section 3 does a better job of explaining how all this >>> works. I'm really not sure what section 4 adds. >> >> The idea was to put the specs in section 4 while the section 3 was=20 >> the high level solution. > > Rereading it, I see that now, but there seems to be a fair amount > of repetition. Let me ask the question differently. Do you see this repetition as proble= m? > >>> (Aside: figure 9 refers to Common Sroperties). >> Yep. thanks. >>> >>> >>> 6. commonPropertiesID Management >>> >>> The text reads: >>> The commonPropertiesID values MAY be assigned sequentially, but it=EF= =BF=BDs >>> It seems the "it's" is using an invalid character rather than an >>> apostrophe. >>> >>> >>> 7. The Collecting Process Side >>> >>> The text reads: >>> Like TemplateIDs the commonPropertiesIDs are generated dynamically=20 >>> by the Exporting Process. Hence a restart of the Exporting Process=20 >>> may imply a renumbering of commonProperiesIDs. >>> The collector can't know if the Exporter Process restarted, this is >>> why we rescoped the commonPropertiesID to the Transport Session, so >>> the above text is now redundant. >> >> I know it's redundant, but don't you think it helps. For example, we=20 >> don't explain anywhere (if I recall correctly) that "the=20 >> commonPropertiesIDs are generated dynamically by the Exporting Process= " > > The commonPropertiesIDs are unique within the transport session. If th= e > session is restarted then you've lost that scope and therefore can't > keep using the same commonPropertiesID mappings. > > I don't see why the commonPropertiesIDs have to be dynamically generate= d > by the Exporting Process. The could be shared between several EPs or > pre-calculated based in historical data from that Observation Domain. Fine. > > >>> The text reads: >>> Common Properties IDs are unique per SCTP association and per=20 >>> Observation Domain. If the Collecting Process receives a common=20 >>> Properties ID which has already been received but which has not=20 >>> previously been withdrawn (i.e. a commonPropertiesID from the same=20 >>> Exporter Observation Domain with the same Template ID received on=20 >>> the SCTP association), then the Collecting Process MUST shutdown the=20 >>> association. >> This is similar to [IPFIX-PROTO] >> >> Template IDs are unique per SCTP association and per Observation =20 >> Domain. If the Collecting Process receives a Template which has =20 >> already been received but which has not previously been withdrawn =20 >> (i.e. a Template Record from the same Exporter Observation Domain =20 >> with the same Template ID received on the SCTP association), then =20 >> the Collecting Process MUST shutdown the association. >> >>> >>> and: >>> If the Collecting Process receives a Common Properties Withdrawal=20 >>> message for a Common Properties that it has not received before on=20 >>> this SCTP assocation, it MUST reset the SCTP association, discard=20 >>> the IPFIX Message, and SHOULD log the error as it does for malformed=20 >>> IPFIX Messages. >>> I think this might go against IPFIX-PROTO. >> This is similar to [IPFIX-PROTO] > > These are similar to what IPFIX-PROTO says about templates, but that > doesn't mean the text can just be used to talk about Data Records sent > for Options Templates. > > Option data withdrawal messages are not mentioned in IPFIX-PROTO, > although I think they can work. However, in general options data with > the same scope as an earlier record will just overwrite the older > record. See my previous remark about an independent draft. > > >> If the Collecting Process receives a Template Withdraw message for=20 >> a Template Record it has not received before on this SCTP=20 >> assocation, it MUST reset the SCTP association, discard the IPFIX=20 >> Message, and SHOULD log the error as it does for malformed IPFIX=20 >> Messages. >>> >>> >>> The text reads: >>> If the Common Properties are not refreshed before that lifetime=20 >>> has expired, the Collecting Process MUST discard the corresponding=20 >>> definition of the commonPropertiesID and any current and future =20 >>> associated Data Records. In which case, an alarm MUST be logged. >>> What happened to storing it until the option turned up. Furthermore >>> you shouldn't dictate the the record is discarded, just because you >>> can't tell a piece of potentially trivial information about a flow >>> doesn't mean it's meaningless. The Common Properties in question >>> could be anything. >>> >> This is similar to [IPFIX-PROTO] >> >> If the Template (or other definition) is not refreshed before that=20 >> lifetime has expired, the Collecting Process MUST discard that=20 >> definition and any current and future associated Data Records. In=20 >> which case, an alarm MUST be logged. > > This "(or other definition)" stuff is only mentioned for the Collecting > Process and it really isn't clear if it should apply to Common > Properties. =20 In this draft, we require a mechanism such as the following: "If the Common Properties are not refreshed before that lifetime has =20 expired, the Collecting Process MUST discard the corresponding =20 definition of the commonPropertiesID and any current and future =20 associated Data Records. In which case, an alarm MUST be logged. " Because there is no withdraw message with UDP: " If UDP is selected as the transport protocol, the commonPropertiesID Template Withdraw Messages MUST not be used, as this method is inefficient due to the unreliable nature of UDP." So I'm wondering why we are discussing this? Let me come back to your questions: Q: What happened to storing it until the option turned up. A: If the Collecting Process has received the Specific Properties Data=20 Record before the associated Common Properties Data Record, the=20 Collecting Process MAY store the Specific Properties Data Record and=20 await the retransmission or out-of-order arrival of the Common=20 Properties Data Record. =20 Q: Furthermore you shouldn't dictate the the record is discarded, just=20 because you can't tell a piece of potentially trivial information about a flow doesn't mean it's meaningless. A: without the Common Properties, we can't decode the records. So we=20 must discard them Q: The Common Properties in question could be anything. A: I think we should limit this draft to Common Properties > However, storing the data records in a queue awaiting > the decode information is really only something that is expected to > be done at the start of the session. Is it mentioned in this draft? > > >>> Besides, we're not changing the protocol here, right? >> Right. So this is not an IPFIX redundancy reduction issue but an=20 >> IPFIX protocol issue... as we don't want to change the protocol with=20 >> this draft. > > What's a protocol issue? I think applying all the requirements of > templates to all options is changing the protocol. > > >>> 8.1 Transport Protocol Choice The text reads: >>> The proposed method is most effective using a reliable transport=20 >>> protocol for the transfer of the Common Properties. Therefore the=20 >>> use of SCTP or TCP is recommended. >>> >>> Note that SCTP isn't necessarily reliable. >> SCTP -> PR-SCTP with the reliable mode >>> >>> >>> 8.3 commonPropertiesID vs. TemplateID scope >>> Additional flow properties can be tied to almost any I.E. For example >>> a particular interface could be associated with the one IP address it >>> serves. >> That's true but I still think the design is cleaner with the Common=20 >> Properties Id. >> See the remark about the Common Properties ID withdrawal > > You can withdraw any option record, so I don't think it's a big deal. > > Regards, Benoit --------------050900090903090402000006 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-bru.cisco.com id kB7CY3J16092 Andrew,

Do we have to mention PSAMP so much anyway,
as it's just a specialised use case of IPFIX?

Right, I think that the previous version was somehow lacking some information.
Yes we can use this mechanism for all sort of flows, even for:
"So the PSAMP export can be seen as special IPFIX Flow Record containing information about a single packet." dixit PSAMP-PROTO
However, by having the clear distinctions...

=C2=A03.1=C2=A0=C2=A0=C2=A0=C2=A0 Per Flow Data Reduction................= ...............11
=C2=A03.1.1=C2=A0 Unique Data Reduction..................................= 11
=C2=A03.1.2=C2=A0 Multiple Data Reduction................................= 12
=C2=A03.2=C2=A0=C2=A0=C2=A0=C2=A0 Per Packet Data Reduction..............= ...............13
... I believe that we gained in clarity... Maybe not for you, as you know enough about IPFIX and PSAMP to understand how to apply this techniques, but for the rest of the community.

It seems that 3.2 doesn't add anything to 3.1.1 other than providing
another example.=C2=A0 Perhaps remove the per-packet stuff from the main
part of the draft but keep it as a detailed example at the end.


Since a flow is defined as a group of packets that share
a set of common properties, i.e. key fields, is there
any danger that the commonPropertiesID will be wrongly
assumed to refer to only the complete set of key fields?

By definition, I think this is impossible. The flow key definition says "Each of the fields which are used to define a Flow are termed Flow Keys.". So there is nothing in common between flows. However, I understand your concern for novice readers.

OLD section 1 "Introduction"

=C2=A0=C2=A0=C2=A0 Regardless of the fields content, flow records with co= mmon=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 properties export the same fields in every single flow record.=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 These common properties may represent values common to a collection=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of flows or packets, or values t= hat are invariant over time.=C2=A0 The=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reduction of redundant data= from the export stream can result in a=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 significant reduction of the tr= ansferred data.

NEW section 1 "Introduction"

=C2=A0Regardless of the fields content, flow records with common=C2=A0=C2= =A0 properties export the same fields in every single flow record.=C2=A0=C2=A0= =C2=A0 These common properties may represent values common to a collection=C2=A0=C2=A0= of flows or packets, or values that are invariant over time.=C2=A0 Note=C2=A0= =C2=A0 that the common properties don't represent the list of flow keys, which=C2=A0=C2= =A0 are used to define a flow definition: however, the common properties=C2=A0= =C2=A0 may contain some of the flow keys. The reduction of redundant data from=C2=A0=C2=A0 the export stream can result in a significant reduction = of the=C2=A0=C2=A0 transferred data.

My concern wasn't really directed at the draft itself, but just the
name "common properties".=C2=A0 From IPFIX-PROTO:
=C2=A0"A Flow is defined as a set of IP packets passing an Observation =C2= =A0 Point in the network during a certain time interval.=C2=A0 All packets =C2= =A0 belonging to a particular Flow have a set of common properties."

And then from IPFIX-INFO:
=C2=A0 Description of commonPropertiesId:
=C2=A0=C2=A0=C2=A0=C2=A0 An identifier of a set of common properties that= is unique per
=C2=A0=C2=A0=C2=A0=C2=A0 Observation Domain.=C2=A0 Typically, this Inform= ation Element is used
=C2=A0=C2=A0=C2=A0=C2=A0 to link to information reported in separate reco= rds.

The terminology is almost identical.=C2=A0 The commonPropertiesId refers
to "a set of common properties" that is quite different from ones
that determine a Flow.
What about something such as?
Description of commonPropertiesId:
=C2=A0=C2=A0=C2=A0=C2=A0 An identifier of a set of common properties betw= een different Flows.
=C2=A0=C2=A0=C2=A0=C2=A0 The that is unique per Observation Domain.=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 Typically, this Information Element is used
=C2=A0=C2=A0=C2=A0=C2=A0 to link to information reported in separate reco= rds.


Is there any need to define a new term for "Specific
Properties"? These are just part of a normal Data Record.
For example:
"... The rows are then referenced by the Specific Properties
by using the appropriate value for the Common Properties
identifier."

could simply be:
"... The rows are then referenced by Data Records by
using the appropriate value for the Common Properties
identifier."

In your example, the "Data Records" doesn't mean the full data records before applying the redundancy reduction mechanism but only a part of it.
So it might be confusing... That's the trick we found.

However, I could agree that the draft would work without a formal (upper case) definition.... So do you have the same idea for the Common Properties?

Considering there is a commonPropertiesID, I am quite happy with you
referring to Common Properties.
Ok. So let's see how the draft looks like if we remove the "Specific Properties" formal definition but if we keep the "Common Properties" one.

There seems to be a bit of a conceptual difference here though.=C2=A0 You
seem to imagine that an Exporting Process has a set of IPFIX Data
Records which it then applies some processing to to get some new
special IPFIX Data Records and some Common Property options.=C2=A0 The
original set of Data Records may never actually exist, depending on
how the scheme is implemented.=C2=A0
Sure, this is an implementation detail, but conceptually, we want to reduce "something". How do you call this "something"?
   This document describes a bandwidth saving method for exporting f=
low=20
   or packet information using the IP Flow Information Export (IPFIX)=20
   protocol.

Anyway, I think that we're diverging from your initial issue which was ab=
out "Specific
Properties"...

For me, the only set of IPFIX Data
Records to consider are the ones which are actually sent.



Are option withdrawal messages part of IPFIX?
Yes. IPFIX says: "The Set ID field MUST contain the value 2 for Template Set withdrawal and the value 3 for Options Template Set withdrawal."
Unless you want to say an option data record withdrawal message?

There is a distinct difference between withdrawing the template and
withdrawing the data record associated with an option template.=C2=A0 I
think that the concept works though, although perhaps not by design.
Agreed.


Note: I discovered that the draft still contains: "Option Data Record"
This term has been removed from IPFIX-PROTO. So it should be removed in this draft.

Are they meaningful in IPFIX? i.e. per the PROTO will an option
with scope but no data be deemed invalidated by the Collector.
Scope without data is the same as never having recieved the
mapping in the first place. I think that it would be up to the
implementation but it seems like a good idea so if we can't add
it to the PROTO can we put it in the implementation guidelines?

How do you propose to withdraw common properties when they are
associated with a template rather than the Common Properties index?

I don't ;) This is the reason why the use the Common Properties index is a cleaner design.

I think withdrawal messages should work in general for options
data, so why not send an empty record with the template as scope?
I guess that you wanted to say:
=C2=A0=C2=A0=C2=A0 I think withdrawal messages should work in general for= options
=C2=A0=C2=A0=C2=A0 data, so why not send an empty record with the comm= on property as scope?
Well, I prefer to have a clear design so that this draft is really independent, with its withdrawal mechanism.
Otherwise, you're telling in this I-RFC the standard track IPFIX protocol should consider an empty record as a withdrawal. This could be true a true assumption, but this is not clearly explained/specified!


General Comments
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I think, sections 3.1.2, 8.2 and 8.3 would be better grouped
into a 3.2 Advanced Techniques section.

I think 3.2 Per Packet Data Reduction, should be removed and
any information that is not in section 3.1 should be added to
to the PSAMP example.
I think the the per-packet example is a good example of
per flow reducing redundancy and section 11.1.1 can be removed.
See one of my previous remark about:

=C2=A03.1=C2=A0=C2=A0=C2=A0 Per Flow Data Reduction......................= .........11
=C2=A03.1.1 Unique Data Reduction..................................11
=C2=A03.1.2 Multiple Data Reduction................................12
=C2=A03.2=C2=A0=C2=A0=C2=A0 Per Packet Data Reduction....................= .........13

Again, it's because you know the boundary between IPFIX and PSAMP

I just don't think the repetition is necessary.=C2=A0 Per-packet is
just a good example of the technique, the Per Packet section
doesn't seem to add any new information.


Labels for the figures would be better if they were centred.
Agreed.

There is all sorts of extra spacing at the end of the lines.



Specific Comments
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
2. Terminology
Tabbing is inconsistent in definition of "Selector":
(i) the Packet Content; (ii) information derived from the packet's treatment at the Observation Point; (iii) any selection state that may be maintained by the Selection Process.

3.1.2 Multiple Data Reduction

I don't think this section is explained very well. From my original
email to Elisa and Lutz (18th Nov 2005):
Andrew Johnson wrote:
Flows
=3D=3D=3D=3D=3D
Flow A: flowId 1, flowId 11, 30 packets, 6000 bytes
Flow B: flowID 1, flowId 12, 50 packets, 9500 bytes
Flow C: flowId 2, flowId 11, 60 packets, 8000 bytes
Flow D: flowID 2, flowId 12, 10 packets, 1500 bytes

Options
=3D=3D=3D=3D=3D=3D=3D
flowId 1 - destinationIpv4address 10.0.0.1, destinationTcpPort 80
flowId 1 - destinationIpv4address 10.0.0.5, destinationTcpPort 80

flowId 11 - sourceIpv4address 10.0.1.10, sourceTcpPort 1932
flowId 12 - sourceIpv4address 10.0.1.15, sourceTcpPort 1842


This shows how 4 (2+2) options can be expanded to 4 combinations of
Data Record to reduce redundancy without the need to define 4 complete
sets of Common Properties and therefore not save any bandwidth. The
more options you have the better this works. 20 options (10+10) would
give you up to 100 possible pairs common properties.

This isn't really made clear in the draft text, with only "flow1"
having two indices.
I agree the examples in figure 4/5 don't show this.
Maybe a new section in section 8 "Export and Evaluation Considerations"?
The example in 11.1.2 doesn't even have any!
Agreed. This should be corrected.

While I agree that using a template that doesn't include the cpID
is a good idea to efficiently communicate flows with not so common
properties, however I would call this an "Advanced Technique" to be
listed in the section I proposed earlier.


3.2 Per Packet Data Reduction

The text reads:
If filtering is applied to select a series of packets, using the PSAMP specifications to export per-packet information might be relatively inefficient if the filtered fields (the common attributes) are exported in every single record.

However in section 6.5.2.5 (Property Match Filtering) of PSAMP-PROTO
it is explained how the filter information MUST be sent. This is
designed so that the selector ID will match the one from the Data
Record (via the selectionSequenceId) and perform exactly the function
that is being proposed here for the commonPropertiesId.
Good point. I would remove this paragraph and move to this place the one starting with:

=C2=A0An example of the per packet data reduction is the measurement of=C2= =A0 =C2=A0One-Way Delay (OWD), where the exact same specific packet must be=C2= =A0 =C2=A0observed at the source and destination of the path to be measured.=C2= =A0=C2=A0 By subtracting ...



4. Specifications for bandwidth saving information export

What is being specified here that isn't true for ALL options as
described in IPFIX-PROTO?

What do you suggest?

Well it seems that section three really explains almost the same
thing 3 times.=C2=A0 The section 4 explains most of it again (with a
bit more info) another 3 times.

I would prefer section 3 to simply explain the technique.=C2=A0 Walk
through how the information from a Flow is split into two parts,
and then add the bit from section 4 how these two parts are
exported.

Using more than one CPid in a record should be part of the
advanced techniques once the basics are made clear.=C2=A0 Per packet
should just be a detailed example at the end.

I think section 3 does a better job of explaining how all this
works. I'm really not sure what section 4 adds.

The idea was to put the specs in section 4 while the section 3 was the high level solution.

Rereading it, I see that now, but there seems to be a fair amount
of repetition.
Let me ask the question differently. Do you see this repetition as problem?

(Aside: figure 9 refers to Common Sroperties).
Yep. thanks.


6. commonPropertiesID Management

The text reads:
The commonPropertiesID values MAY be assigned sequentially, but it=EF=BF=BD= s
It seems the "it's" is using an invalid character rather than an
apostrophe.


7. The Collecting Process Side

The text reads:
Like TemplateIDs the commonPropertiesIDs are generated dynamically by the Exporting Process. Hence a restart of the Exporting Process may imply a renumbering of commonProperiesIDs.
The collector can't know if the Exporter Process restarted, this is
why we rescoped the commonPropertiesID to the Transport Session, so
the above text is now redundant.

I know it's redundant, but don't you think it helps. For example, we don't explain anywhere (if I recall correctly) that "the commonPropertiesIDs are generated dynamically by the Exporting Process"

The commonPropertiesIDs are unique within the transport session.=C2=A0 If the
session is restarted then you've lost that scope and therefore can't
keep using the same commonPropertiesID mappings.

I don't see why the commonPropertiesIDs have to be dynamically generated
by the Exporting Process.=C2=A0 The could be shared between several EPs o= r
pre-calculated based in historical data from that Observation Domain.
Fine.


The text reads:
Common Properties IDs are unique per SCTP association and per Observation Domain. If the Collecting Process receives a common Properties ID which has already been received but which has not previously been withdrawn (i.e. a commonPropertiesID from the same Exporter Observation Domain with the same Template ID received on the SCTP association), then the Collecting Process MUST shutdown the association.
This is similar to [IPFIX-PROTO]

=C2=A0Template IDs are unique per SCTP association and per Observation=C2= =A0 =C2=A0Domain.=C2=A0 If the Collecting Process receives a Template which h= as=C2=A0 =C2=A0already been received but which has not previously been withdrawn=C2= =A0=C2=A0=C2=A0 (i.e. a Template Record from the same Exporter Observation Domain=C2=A0=C2= =A0=C2=A0=C2=A0 with the same Template ID received on the SCTP association), then=C2=A0=C2= =A0=C2=A0 the Collecting Process MUST shutdown the association.


and:
If the Collecting Process receives a Common Properties Withdrawal message for a Common Properties that it has not received before on this SCTP assocation, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error as it does for malformed IPFIX Messages.
I think this might go against IPFIX-PROTO.
This is similar to [IPFIX-PROTO]

These are similar to what IPFIX-PROTO says about templates, but that
doesn't mean the text can just be used to talk about Data Records sent
for Options Templates.

Option data withdrawal messages are not mentioned in IPFIX-PROTO,
although I think they can work.=C2=A0 However, in general options data wi= th
the same scope as an earlier record will just overwrite the older
record.
See my previous remark about an independent draft.


=C2=A0If the Collecting Process receives a Template Withdraw message for a=C2=A0 =C2=A0Template Record it has not re= ceived before on this SCTP assocation,=C2=A0=C2=A0=C2=A0 it MUST reset the SCTP = association, discard the IPFIX Message, and=C2=A0=C2=A0=C2=A0 SHOULD log the error as = it does for malformed IPFIX Messages.


The text reads:
=C2=A0 If the Common Properties are not refreshed before that lifetime ha= s =C2=A0 expired, the Collecting Process MUST discard the corresponding =C2=A0 definition of the commonPropertiesID and any current and future =C2=A0 associated Data Records. In which case, an alarm MUST be logged.
What happened to storing it until the option turned up. Furthermore
you shouldn't dictate the the record is discarded, just because you
can't tell a piece of potentially trivial information about a flow
doesn't mean it's meaningless. The Common Properties in question
could be anything.

This is similar to [IPFIX-PROTO]

=C2=A0If the Template=C2=A0=C2=A0 (or other definition) is not refreshed = before that lifetime has=C2=A0=C2=A0 expired, the Collecting Process MUST discard tha= t definition and any=C2=A0=C2=A0 current and future associated Data Records= .=C2=A0 In which case, an alarm=C2=A0=C2=A0 MUST be logged.

This "(or other definition)" stuff is only mentioned for the Collecting
Process and it really isn't clear if it should apply to Common
Properties.=C2=A0
In this draft, we require a mechanism such as the following:
"If the Common Properties are not refreshed before that lifetime has =C2=A0 expired, the Collecting Process MUST discard the corresponding =C2=A0 definition of the commonPropertiesID and any current and future =C2=A0 associated Data Records. In which case, an alarm MUST be logged. "
Because there is no withdraw message with UDP:
" If UDP is selected as the transport protocol, the commonPropertiesID =C2=A0 Template Withdraw Messages MUST not be used, as this method is =C2=A0 inefficient due to the unreliable nature of UDP."
So I'm wondering why we are discussing this?

Let me come back to your questions:
Q: What happened to storing it until the option turned up.
A: 
   If the Collecting Process has received the Specific Properties Da=
ta=20
   Record before the associated Common Properties Data Record, the=20
   Collecting Process MAY store the Specific Properties Data Record and=20
   await the retransmission or out-of-order arrival of the Common=20
   Properties Data Record.

Q: Furthermore you shouldn't dictate the the record is discarded, just because you
can't tell a piece of potentially trivial information about a flow
doesn't mean it's meaningless.
A: without the Common Properties, we can't decode the records. So we must discard them

Q: The Common Properties in question could be anything.
A: I think we should limit this draft to Common Properties
However, storing the data records in a queue awaiting
the decode information is really only something that is expected to
be done at the start of the session.=C2=A0 Is it mentioned in this draft?


Besides, we're not changing the protocol here, right?
Right. So this is not an IPFIX redundancy reduction issue but an IPFIX protocol issue... as we don't want to change the protocol with this draft.

What's a protocol issue?=C2=A0 I think applying all the requirements of
templates to all options is changing the protocol.


8.1 Transport Protocol Choice The text reads:
The proposed method is most effective using a reliable transport protocol for the transfer of the Common Properties. Therefore the use of SCTP or TCP is recommended.

Note that SCTP isn't necessarily reliable.
SCTP -> PR-SCTP with the reliable mode


8.3 commonPropertiesID vs. TemplateID scope
Additional flow properties can be tied to almost any I.E. For example
a particular interface could be associated with the one IP address it
serves.
That's true but I still think the design is cleaner with the Common Properties Id.
See the remark about the Common Properties ID withdrawal

You can withdraw any option record, so I don't think it's a big deal.


Regards, Benoit
--------------050900090903090402000006-- --===============0021560747== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============0021560747==-- From ipfix-bounces@ietf.org Thu Dec 07 07:52:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsIjZ-0005Jk-5C; Thu, 07 Dec 2006 07:52:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsIjX-0005J3-HH for ipfix@ietf.org; Thu, 07 Dec 2006 07:52:15 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsIjW-00045w-5w for ipfix@ietf.org; Thu, 07 Dec 2006 07:52: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.7p3+Sun/8.11.7) with ESMTP id kB7CpHX17110; Thu, 7 Dec 2006 13:51:17 +0100 (CET) Received: from [10.61.82.49] (ams3-vpn-dhcp4658.cisco.com [10.61.82.49]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB7CpGW17786; Thu, 7 Dec 2006 13:51:16 +0100 (CET) Message-ID: <45780E44.4090906@cisco.com> Date: Thu, 07 Dec 2006 13:51:16 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Paul Aitken Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <4561CC85.4030200@cisco.com> In-Reply-To: <4561CC85.4030200@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Paul, > Dear all, > >> As agreed at the IPFIX session in San Diego last week >> this is the WG last call on the Internet draft on >> Reducing redundancy in IPFIX and PSAMP reports, >> draft-ietf-ipfix-reducing-redundancy-01.txt. > > The draft should discuss whether it's possible to define common > property trees, where common properties are defined in terms of other > common properties. We could add a new section ( 8.5 Cascaded Common Properties.) with a few sentences. My personal view is: - There is nothing in the protocol that prevents this - So this should be allowed - However, I'm not sure it makes a lot of sense (expressed differently: I haven't found the perfect example yet ;) ) Regards, Benoit. > > If so, it should also discuss what to do when one or more necessary > common properties are missing, and how to avoid circular definitions. > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 07:52:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsIjZ-0005Jk-5C; Thu, 07 Dec 2006 07:52:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsIjX-0005J3-HH for ipfix@ietf.org; Thu, 07 Dec 2006 07:52:15 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsIjW-00045w-5w for ipfix@ietf.org; Thu, 07 Dec 2006 07:52: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.7p3+Sun/8.11.7) with ESMTP id kB7CpHX17110; Thu, 7 Dec 2006 13:51:17 +0100 (CET) Received: from [10.61.82.49] (ams3-vpn-dhcp4658.cisco.com [10.61.82.49]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB7CpGW17786; Thu, 7 Dec 2006 13:51:16 +0100 (CET) Message-ID: <45780E44.4090906@cisco.com> Date: Thu, 07 Dec 2006 13:51:16 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Paul Aitken Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <4561CC85.4030200@cisco.com> In-Reply-To: <4561CC85.4030200@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Paul, > Dear all, > >> As agreed at the IPFIX session in San Diego last week >> this is the WG last call on the Internet draft on >> Reducing redundancy in IPFIX and PSAMP reports, >> draft-ietf-ipfix-reducing-redundancy-01.txt. > > The draft should discuss whether it's possible to define common > property trees, where common properties are defined in terms of other > common properties. We could add a new section ( 8.5 Cascaded Common Properties.) with a few sentences. My personal view is: - There is nothing in the protocol that prevents this - So this should be allowed - However, I'm not sure it makes a lot of sense (expressed differently: I haven't found the perfect example yet ;) ) Regards, Benoit. > > If so, it should also discuss what to do when one or more necessary > common properties are missing, and how to avoid circular definitions. > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 08:02:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsIto-00034q-3i; Thu, 07 Dec 2006 08:02:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsItm-00034N-B6 for ipfix@ietf.org; Thu, 07 Dec 2006 08:02:50 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsItk-0006B1-Sr for ipfix@ietf.org; Thu, 07 Dec 2006 08:02:50 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB7D2mS17816; Thu, 7 Dec 2006 14:02:48 +0100 (CET) Received: from [10.61.82.49] (ams3-vpn-dhcp4658.cisco.com [10.61.82.49]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB7D2lW27263; Thu, 7 Dec 2006 14:02:47 +0100 (CET) Message-ID: <457810F7.2010606@cisco.com> Date: Thu, 07 Dec 2006 14:02:47 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <45756B12.8020109@cisco.com> <5A5FB8CC-317C-40A9-A0B3-5E6E97BE370D@cert.org> In-Reply-To: <5A5FB8CC-317C-40A9-A0B3-5E6E97BE370D@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: ipfix@ietf.org, Elisa Boschi X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian, > Benoit and all, > > See inline, as always... > > On Dec 5, 2006, at 7:50 AM, Benoit Claise wrote: > >>> 7 para 7 OLD: >>> >>> If a Collecting Process receives a Common Properties Withdrawal >>> message, the Collecting Process MUST delete the corresponding Common >>> Properties associated with the specific SCTP association and >>> specific Observation Domain, and stop decoding IPFIX Messages that >>> use the withdrawn Templates. >>> >>> 7 para 7 NEW: >>> >>> If a Collecting Process receives a Common Properties Withdrawal >>> message, the Collecting Process MUST delete the corresponding Common >>> Properties associated with the specific SCTP association and >>> specific Observation Domain. >> I would like to add, "and stop decoding IPFIX Messages that use the >> withdrawn Common Properties" >> This would be in line with [IPFIX-PROTO] "The Collecting Process's >> Side" section: >> >> If a Collecting Process receives a Template Withdraw Message, the >> Collecting Process MUST delete the corresponding Template Records >> associated with the specific SCTP association and specific >> Observation Domain, and stop decoding IPFIX Messages that use the >> withdrawn Templates. > > Hmmm.... I agree with the point, but I'm not sure this is the right > language here. A CP would stop decoding Messages (actually, Sets) > described by withdrawn Templates because Templates are necessary for > decode. Common Properties are a bit higher in the stack - the Sets can > be decoded, but some data would be missing for each record. How about > something like: > > "and stop interpreting Data Records referring to those Common > Properties. The receipt of Data Records referring to Common Properties > that have been withdrawn MUST be ignored and SHOULD be logged by the > Collecting Process." Yes, this is more accurate. Thanks. > >>> >>> 7.1 para 3 OLD: >>> >>> The Collecting Process MUST NOT decode any further Data Records >>> which >>> are associated with the expired Common Properties. If a Common >>> Property is refreshed with a Template Record that differs from the >>> previous received Template Record, the Collecting Process SHOULD log >>> a warning and replace the previous received Common Property with the >>> new one. The Template lifetime at the Collecting Process MUST be at >>> least 3 times higher than the Template refresh timeout configured on >>> the Exporting Process. >>> >>> 7.1 para 3 NEW: >>> >>> The Collecting Process MUST NOT decode any further Data Records >>> which >>> are associated with the expired Common Properties. If a Common >>> Property is refreshed with a definition that differs from the >>> previous definition, the Collecting Process SHOULD log >>> a warning and replace the previous received Common Property with the >>> new one. The Common Property lifetime at the Collecting Process >>> MUST be at >>> least 3 times higher than the Common Property timeout configured on >>> the Exporting Process. >> In this case, you insert a new term "Common Property timeout". I >> propose: >> The Collecting Process MUST NOT decode any further Data Records which >> are associated with the expired Common Properties. If a Common >> Property is refreshed with a definition that differs from the >> previous definition, the Collecting Process SHOULD log >> a warning and replace the previous received Common Property with the >> new one. The Common Property lifetime at the Collecting Process >> MUST be at >> least 3 times higher than the refresh timeout of the Template used >> to export the >> Common Property definition, configured on the Exporting Process. > > (see previous message where this was clarified to "Common Property > refresh timeout") > > An alternative would be to define the Common Property refresh timeout > elsewhere in the document, and refer to it here, as we do with > Template refresh in the protocol. Since the Common Property lifetime > and the Template lifetime are both scoped to the Transport Session > lifetime for connection-oriented transports, there may be no reason to > presume that the Template refresh and Common Property refresh timeout > should ever be different (indeed, things may break if they are; I've > not thought it all the way through); however, I do think it is clearer > if the Common Property refresh mechanism has its own terminology > rather than tying it directly to the template timeout. > > Thoughts? Fine with me if this makes the draft clearer. I would also add a note somewhere in the draft (not sure where) a guideline to express your concern. "there may be no reason to presume that the Template refresh and Common Property refresh timeout should ever be different" Regards, Benoit. > > Regards, > > Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 08:02:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsIto-00034q-3i; Thu, 07 Dec 2006 08:02:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsItm-00034N-B6 for ipfix@ietf.org; Thu, 07 Dec 2006 08:02:50 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsItk-0006B1-Sr for ipfix@ietf.org; Thu, 07 Dec 2006 08:02:50 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB7D2mS17816; Thu, 7 Dec 2006 14:02:48 +0100 (CET) Received: from [10.61.82.49] (ams3-vpn-dhcp4658.cisco.com [10.61.82.49]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB7D2lW27263; Thu, 7 Dec 2006 14:02:47 +0100 (CET) Message-ID: <457810F7.2010606@cisco.com> Date: Thu, 07 Dec 2006 14:02:47 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <45756B12.8020109@cisco.com> <5A5FB8CC-317C-40A9-A0B3-5E6E97BE370D@cert.org> In-Reply-To: <5A5FB8CC-317C-40A9-A0B3-5E6E97BE370D@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: ipfix@ietf.org, Elisa Boschi X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian, > Benoit and all, > > See inline, as always... > > On Dec 5, 2006, at 7:50 AM, Benoit Claise wrote: > >>> 7 para 7 OLD: >>> >>> If a Collecting Process receives a Common Properties Withdrawal >>> message, the Collecting Process MUST delete the corresponding Common >>> Properties associated with the specific SCTP association and >>> specific Observation Domain, and stop decoding IPFIX Messages that >>> use the withdrawn Templates. >>> >>> 7 para 7 NEW: >>> >>> If a Collecting Process receives a Common Properties Withdrawal >>> message, the Collecting Process MUST delete the corresponding Common >>> Properties associated with the specific SCTP association and >>> specific Observation Domain. >> I would like to add, "and stop decoding IPFIX Messages that use the >> withdrawn Common Properties" >> This would be in line with [IPFIX-PROTO] "The Collecting Process's >> Side" section: >> >> If a Collecting Process receives a Template Withdraw Message, the >> Collecting Process MUST delete the corresponding Template Records >> associated with the specific SCTP association and specific >> Observation Domain, and stop decoding IPFIX Messages that use the >> withdrawn Templates. > > Hmmm.... I agree with the point, but I'm not sure this is the right > language here. A CP would stop decoding Messages (actually, Sets) > described by withdrawn Templates because Templates are necessary for > decode. Common Properties are a bit higher in the stack - the Sets can > be decoded, but some data would be missing for each record. How about > something like: > > "and stop interpreting Data Records referring to those Common > Properties. The receipt of Data Records referring to Common Properties > that have been withdrawn MUST be ignored and SHOULD be logged by the > Collecting Process." Yes, this is more accurate. Thanks. > >>> >>> 7.1 para 3 OLD: >>> >>> The Collecting Process MUST NOT decode any further Data Records >>> which >>> are associated with the expired Common Properties. If a Common >>> Property is refreshed with a Template Record that differs from the >>> previous received Template Record, the Collecting Process SHOULD log >>> a warning and replace the previous received Common Property with the >>> new one. The Template lifetime at the Collecting Process MUST be at >>> least 3 times higher than the Template refresh timeout configured on >>> the Exporting Process. >>> >>> 7.1 para 3 NEW: >>> >>> The Collecting Process MUST NOT decode any further Data Records >>> which >>> are associated with the expired Common Properties. If a Common >>> Property is refreshed with a definition that differs from the >>> previous definition, the Collecting Process SHOULD log >>> a warning and replace the previous received Common Property with the >>> new one. The Common Property lifetime at the Collecting Process >>> MUST be at >>> least 3 times higher than the Common Property timeout configured on >>> the Exporting Process. >> In this case, you insert a new term "Common Property timeout". I >> propose: >> The Collecting Process MUST NOT decode any further Data Records which >> are associated with the expired Common Properties. If a Common >> Property is refreshed with a definition that differs from the >> previous definition, the Collecting Process SHOULD log >> a warning and replace the previous received Common Property with the >> new one. The Common Property lifetime at the Collecting Process >> MUST be at >> least 3 times higher than the refresh timeout of the Template used >> to export the >> Common Property definition, configured on the Exporting Process. > > (see previous message where this was clarified to "Common Property > refresh timeout") > > An alternative would be to define the Common Property refresh timeout > elsewhere in the document, and refer to it here, as we do with > Template refresh in the protocol. Since the Common Property lifetime > and the Template lifetime are both scoped to the Transport Session > lifetime for connection-oriented transports, there may be no reason to > presume that the Template refresh and Common Property refresh timeout > should ever be different (indeed, things may break if they are; I've > not thought it all the way through); however, I do think it is clearer > if the Common Property refresh mechanism has its own terminology > rather than tying it directly to the template timeout. > > Thoughts? Fine with me if this makes the draft clearer. I would also add a note somewhere in the draft (not sure where) a guideline to express your concern. "there may be no reason to presume that the Template refresh and Common Property refresh timeout should ever be different" Regards, Benoit. > > Regards, > > Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 09:13:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsJzC-00085E-LL; Thu, 07 Dec 2006 09:12:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsJzB-000857-Gc for ipfix@ietf.org; Thu, 07 Dec 2006 09:12:29 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsJz8-0000ur-Pb for ipfix@ietf.org; Thu, 07 Dec 2006 09:12:29 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB7ECMc22128; Thu, 7 Dec 2006 15:12:25 +0100 (CET) Received: from [10.61.82.49] (ams3-vpn-dhcp4658.cisco.com [10.61.82.49]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB7ECLW06027; Thu, 7 Dec 2006 15:12:22 +0100 (CET) Message-ID: <45782145.6000302@cisco.com> Date: Thu, 07 Dec 2006 15:12:21 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Gerhard Muenz Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455D917A.7020003@informatik.uni-tuebingen.de> In-Reply-To: <455D917A.7020003@informatik.uni-tuebingen.de> X-Spam-Score: 0.5 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1543867150==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1543867150== Content-Type: multipart/alternative; boundary="------------020501040504030605050604" This is a multi-part message in MIME format. --------------020501040504030605050604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard, > Dear all, > > Some meccorrections for draft-ietf-ipfix-reducing-redundancy-01: > > fig. 7: > Shouldn't "index of properties A" be in front of "scrAddrA"? > Well spot. This would be inline with figure 5 > p. 18: > it's => it is > etc... => etc. > > p. 21: > "In that case, for a flow of 1000 packets the amount of data can be > decreased _by_ more than 33 percent" > can't => cannot > This comes from section 11.2 "For a flow of 1000 packets this sums up to 20018 bytes. This is a decrease of more than 33 percent." Maybe the proposal is to: 1. Change section 11.2 to "For a flow of 1000 packets this sums up to 20018 bytes. This is a decrease of 33 percents". 2. Modify the first paragraph in section 8.4: The passive One-Way Delay measurement example in section 11.2, which is a very special application where the proposed method is very beneficial, uses IPFIX to export measurement data for each received packet. In that case, for a flow of 1000 packets the amount of data can be decreased by 33 percents" 3. Add an extra paragraph in section 8.4 to address "under conditions" (i.e. your last remark) See below. > p. 22: > Somehow mark the notion of time in the table, e.g. with horizontal lines > between distinct export instances? Or add timestamp fields. > > p. 23: > Field Count = 3 ? > Good catch. Figure 14 should be corrected. > > Some comments on Section 8: > > The main advantage of the method specified in this document is the > reduction in the amount of measurement data that has to be > transferred from the Exporter to the Collector. > > I would like to add here "under some conditions" (or something similar) > since the proposed method does not necessarily lead to a reduction of > the amount of data. > > The transfer of the commonPropertiesIDs originates some overhead. > Note that IPFIX allows reduced-size encoding of Information > Elements. In cases where the range of the commonPropertiesID can be > restricted, reduced-size encoding can be applied also to the > commonPropertiesID, and would result in a further bandwidth > efficiency gain. > > I would say: the overhead of the commonPropertiesID IE is very > significant if 64 bit are used. The length of the commonPropertiesID > field also gives you a necessary condition if you ever want to reach a > reduced amount of data: The length must be shorter than the length of > the replaced IEs, otherwise you even increase the amount monitoring data! > As a consequence, reduced-size encoding should be used whenever possible. > Agreed. > The example in section 11.2 below uses IPFIX to export measurement > data for each received packet. In that case, for a flow of 1000 > packets the amount of data can be decreased more than 33 percent. > > The example in 11.2 refers to OWD measurements, which is a very special > application where the proposed method is very beneficial. Maybe you > should mention "OWD measurements" here, since 33 percent may not be the > general case. > > While the goal of this specification is to reduce the bandwidth, the > efficiency might be limited. > > As I said before, you can even increase the amount of data with the > proposed method. So I suggest to explain under which conditions the > approach achieves its goal. > How many times do I need to refer to the common properties until the > amount of data is reduced for the first time? > This should be a simple calculation. Even if this number cannot be > predicted in advance in pratice, it might be useful to estimate when I > should use the approach. > Proposal: add the following two paragraphs at the end of the section 8.4 Efficiency Gain While the goal of this specification is to reduce the bandwidth, this technique might even lead to an increase in bandwidth usage under certain conditions. Taking into account the overhead of exporting the commonPropertiesID values, if the commonPropertiesID values are not used in future Data Records, this technique would actually increase the export bandwidth. A typical case would be the assignments of Common Properties based on past observed traffic, hoping that future flows would contain the same characteristics. Note that the efficiency gain would be directly proportional the re-use of the defined commonPropertiesID values (In other words, the more we re-use a commonPropertiesID value, the better the efficiency gain), with a theoretical limit where all the Data Records would use a single commonPropertiesID. Feel free to modify the proposal as you wish. > Regards, > Gerhard > > Juergen Quittek wrote: > >> Dear all, >> >> As agreed at the IPFIX session in San Diego last week >> this is the WG last call on the Internet draft on >> Reducing redundancy in IPFIX and PSAMP reports, >> draft-ietf-ipfix-reducing-redundancy-01.txt. >> >> The WG last call starts today and will be closed on >> December 1st. >> >> Please review the draft and send your comments! Please also >> send a message to the mailing list if you reviewed it and >> have no comment to make! >> >> Thanks, >> >> Juergen >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipfix >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix > --------------020501040504030605050604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard, 
Dear all,

Some meccorrections for draft-ietf-ipfix-reducing-redundancy-01:

fig. 7:
Shouldn't "index of properties A" be in front of "scrAddrA"?
Well spot. This would be inline with figure 5
p. 18:
it's => it is
etc... => etc.

p. 21:
"In that case, for a flow of 1000 packets the amount of data can be
decreased _by_ more than 33 percent"
can't => cannot
This comes from section 11.2 "For a flow of 1000 packets this sums up to 20018 bytes. This is a decrease of more than 33 percent."
Maybe the proposal is to:
1. Change section 11.2 to "For a flow of 1000 packets this sums up to 20018 bytes. This is a decrease of 33 percents".
2. Modify the first paragraph in section 8.4:
The passive One-Way Delay measurement example in section 11.2,  which is a very special application where the proposed method is very beneficial,  uses IPFIX to export measurement data for each received packet. In that case, for a flow of 1000 packets the amount of data can be decreased by 33 percents"
3. Add an extra paragraph in section 8.4 to address "under conditions" (i.e. your last remark)
    See below.

p. 22:
Somehow mark the notion of time in the table, e.g. with horizontal lines
between distinct export instances? Or add timestamp fields.

p. 23:
Field Count = 3 ?
Good catch.
Figure 14 should be corrected.

Some comments on Section 8:

   The main advantage of the method specified in this document is the
   reduction in the amount of measurement data that has to be
   transferred from the Exporter to the Collector.

I would like to add here "under some conditions" (or something similar)
since the proposed method does not necessarily lead to a reduction of
the amount of data.

   The transfer of the commonPropertiesIDs originates some overhead.
   Note that IPFIX allows reduced-size encoding of Information
   Elements.  In cases where the range of the commonPropertiesID can be
   restricted, reduced-size encoding can be applied also to the
   commonPropertiesID, and would result in a further bandwidth
   efficiency gain.

I would say: the overhead of the commonPropertiesID IE is very
significant if 64 bit are used. The length of the commonPropertiesID
field also gives you a necessary condition if you ever want to reach a
reduced amount of data: The length must be shorter than the length of
the replaced IEs, otherwise you even increase the amount monitoring data!
As a consequence, reduced-size encoding should be used whenever possible.
Agreed.
   The example in section 11.2 below uses IPFIX to export measurement
   data for each received packet.  In that case, for a flow of 1000
   packets the amount of data can be decreased more than 33 percent.

The example in 11.2 refers to OWD measurements, which is a very special
application where the proposed method is very beneficial. Maybe you
should mention "OWD measurements" here, since 33 percent may not be the
general case.

   While the goal of this specification is to reduce the bandwidth, the
   efficiency might be limited.

As I said before, you can even increase the amount of data with the
proposed method. So I suggest to explain under which conditions the
approach achieves its goal.
How many times do I need to refer to the common properties until the
amount of data is reduced for the first time?
This should be a simple calculation. Even if this number cannot be
predicted in advance in pratice, it might be useful to estimate when I
should use the approach.
Proposal: add the following two paragraphs at the end of the section 8.4 Efficiency Gain

While the goal of this specification is to reduce the bandwidth, this technique might even lead to an increase in bandwidth usage under certain conditions.
Taking into account the overhead of exporting the commonPropertiesID values, if the commonPropertiesID values are not used in future Data Records, this technique would actually increase the export bandwidth. A typical case would be the assignments of Common Properties based on past observed traffic, hoping that future flows would contain the same characteristics.

Note that the efficiency gain would be directly proportional the re-use of the defined commonPropertiesID values (In other words, the more we re-use a commonPropertiesID value, the better the efficiency gain), with a theoretical limit where all the Data Records would use a single commonPropertiesID.
Feel free to modify the proposal as you wish.

Regards,
Gerhard

Juergen Quittek wrote:
  
Dear all,

As agreed at the IPFIX session in San Diego last week
this is the WG last call on the Internet draft on
Reducing redundancy in IPFIX and PSAMP reports,
draft-ietf-ipfix-reducing-redundancy-01.txt.

The WG last call starts today and will be closed on
December 1st.

Please review the draft and send your comments!  Please also
send a message to the mailing list if you reviewed it and
have no comment to make!

Thanks,

   Juergen


_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.org/mailman/listinfo/ipfix
    

  

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.org/mailman/listinfo/ipfix

--------------020501040504030605050604-- --===============1543867150== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1543867150==-- From ipfix-bounces@ietf.org Thu Dec 07 09:13:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsJzC-00085E-LL; Thu, 07 Dec 2006 09:12:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsJzB-000857-Gc for ipfix@ietf.org; Thu, 07 Dec 2006 09:12:29 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsJz8-0000ur-Pb for ipfix@ietf.org; Thu, 07 Dec 2006 09:12:29 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB7ECMc22128; Thu, 7 Dec 2006 15:12:25 +0100 (CET) Received: from [10.61.82.49] (ams3-vpn-dhcp4658.cisco.com [10.61.82.49]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB7ECLW06027; Thu, 7 Dec 2006 15:12:22 +0100 (CET) Message-ID: <45782145.6000302@cisco.com> Date: Thu, 07 Dec 2006 15:12:21 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Gerhard Muenz Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455D917A.7020003@informatik.uni-tuebingen.de> In-Reply-To: <455D917A.7020003@informatik.uni-tuebingen.de> X-Spam-Score: 0.5 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1543867150==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1543867150== Content-Type: multipart/alternative; boundary="------------020501040504030605050604" This is a multi-part message in MIME format. --------------020501040504030605050604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard, > Dear all, > > Some meccorrections for draft-ietf-ipfix-reducing-redundancy-01: > > fig. 7: > Shouldn't "index of properties A" be in front of "scrAddrA"? > Well spot. This would be inline with figure 5 > p. 18: > it's => it is > etc... => etc. > > p. 21: > "In that case, for a flow of 1000 packets the amount of data can be > decreased _by_ more than 33 percent" > can't => cannot > This comes from section 11.2 "For a flow of 1000 packets this sums up to 20018 bytes. This is a decrease of more than 33 percent." Maybe the proposal is to: 1. Change section 11.2 to "For a flow of 1000 packets this sums up to 20018 bytes. This is a decrease of 33 percents". 2. Modify the first paragraph in section 8.4: The passive One-Way Delay measurement example in section 11.2, which is a very special application where the proposed method is very beneficial, uses IPFIX to export measurement data for each received packet. In that case, for a flow of 1000 packets the amount of data can be decreased by 33 percents" 3. Add an extra paragraph in section 8.4 to address "under conditions" (i.e. your last remark) See below. > p. 22: > Somehow mark the notion of time in the table, e.g. with horizontal lines > between distinct export instances? Or add timestamp fields. > > p. 23: > Field Count = 3 ? > Good catch. Figure 14 should be corrected. > > Some comments on Section 8: > > The main advantage of the method specified in this document is the > reduction in the amount of measurement data that has to be > transferred from the Exporter to the Collector. > > I would like to add here "under some conditions" (or something similar) > since the proposed method does not necessarily lead to a reduction of > the amount of data. > > The transfer of the commonPropertiesIDs originates some overhead. > Note that IPFIX allows reduced-size encoding of Information > Elements. In cases where the range of the commonPropertiesID can be > restricted, reduced-size encoding can be applied also to the > commonPropertiesID, and would result in a further bandwidth > efficiency gain. > > I would say: the overhead of the commonPropertiesID IE is very > significant if 64 bit are used. The length of the commonPropertiesID > field also gives you a necessary condition if you ever want to reach a > reduced amount of data: The length must be shorter than the length of > the replaced IEs, otherwise you even increase the amount monitoring data! > As a consequence, reduced-size encoding should be used whenever possible. > Agreed. > The example in section 11.2 below uses IPFIX to export measurement > data for each received packet. In that case, for a flow of 1000 > packets the amount of data can be decreased more than 33 percent. > > The example in 11.2 refers to OWD measurements, which is a very special > application where the proposed method is very beneficial. Maybe you > should mention "OWD measurements" here, since 33 percent may not be the > general case. > > While the goal of this specification is to reduce the bandwidth, the > efficiency might be limited. > > As I said before, you can even increase the amount of data with the > proposed method. So I suggest to explain under which conditions the > approach achieves its goal. > How many times do I need to refer to the common properties until the > amount of data is reduced for the first time? > This should be a simple calculation. Even if this number cannot be > predicted in advance in pratice, it might be useful to estimate when I > should use the approach. > Proposal: add the following two paragraphs at the end of the section 8.4 Efficiency Gain While the goal of this specification is to reduce the bandwidth, this technique might even lead to an increase in bandwidth usage under certain conditions. Taking into account the overhead of exporting the commonPropertiesID values, if the commonPropertiesID values are not used in future Data Records, this technique would actually increase the export bandwidth. A typical case would be the assignments of Common Properties based on past observed traffic, hoping that future flows would contain the same characteristics. Note that the efficiency gain would be directly proportional the re-use of the defined commonPropertiesID values (In other words, the more we re-use a commonPropertiesID value, the better the efficiency gain), with a theoretical limit where all the Data Records would use a single commonPropertiesID. Feel free to modify the proposal as you wish. > Regards, > Gerhard > > Juergen Quittek wrote: > >> Dear all, >> >> As agreed at the IPFIX session in San Diego last week >> this is the WG last call on the Internet draft on >> Reducing redundancy in IPFIX and PSAMP reports, >> draft-ietf-ipfix-reducing-redundancy-01.txt. >> >> The WG last call starts today and will be closed on >> December 1st. >> >> Please review the draft and send your comments! Please also >> send a message to the mailing list if you reviewed it and >> have no comment to make! >> >> Thanks, >> >> Juergen >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipfix >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix > --------------020501040504030605050604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard, 
Dear all,

Some meccorrections for draft-ietf-ipfix-reducing-redundancy-01:

fig. 7:
Shouldn't "index of properties A" be in front of "scrAddrA"?
Well spot. This would be inline with figure 5
p. 18:
it's => it is
etc... => etc.

p. 21:
"In that case, for a flow of 1000 packets the amount of data can be
decreased _by_ more than 33 percent"
can't => cannot
This comes from section 11.2 "For a flow of 1000 packets this sums up to 20018 bytes. This is a decrease of more than 33 percent."
Maybe the proposal is to:
1. Change section 11.2 to "For a flow of 1000 packets this sums up to 20018 bytes. This is a decrease of 33 percents".
2. Modify the first paragraph in section 8.4:
The passive One-Way Delay measurement example in section 11.2,  which is a very special application where the proposed method is very beneficial,  uses IPFIX to export measurement data for each received packet. In that case, for a flow of 1000 packets the amount of data can be decreased by 33 percents"
3. Add an extra paragraph in section 8.4 to address "under conditions" (i.e. your last remark)
    See below.

p. 22:
Somehow mark the notion of time in the table, e.g. with horizontal lines
between distinct export instances? Or add timestamp fields.

p. 23:
Field Count = 3 ?
Good catch.
Figure 14 should be corrected.

Some comments on Section 8:

   The main advantage of the method specified in this document is the
   reduction in the amount of measurement data that has to be
   transferred from the Exporter to the Collector.

I would like to add here "under some conditions" (or something similar)
since the proposed method does not necessarily lead to a reduction of
the amount of data.

   The transfer of the commonPropertiesIDs originates some overhead.
   Note that IPFIX allows reduced-size encoding of Information
   Elements.  In cases where the range of the commonPropertiesID can be
   restricted, reduced-size encoding can be applied also to the
   commonPropertiesID, and would result in a further bandwidth
   efficiency gain.

I would say: the overhead of the commonPropertiesID IE is very
significant if 64 bit are used. The length of the commonPropertiesID
field also gives you a necessary condition if you ever want to reach a
reduced amount of data: The length must be shorter than the length of
the replaced IEs, otherwise you even increase the amount monitoring data!
As a consequence, reduced-size encoding should be used whenever possible.
Agreed.
   The example in section 11.2 below uses IPFIX to export measurement
   data for each received packet.  In that case, for a flow of 1000
   packets the amount of data can be decreased more than 33 percent.

The example in 11.2 refers to OWD measurements, which is a very special
application where the proposed method is very beneficial. Maybe you
should mention "OWD measurements" here, since 33 percent may not be the
general case.

   While the goal of this specification is to reduce the bandwidth, the
   efficiency might be limited.

As I said before, you can even increase the amount of data with the
proposed method. So I suggest to explain under which conditions the
approach achieves its goal.
How many times do I need to refer to the common properties until the
amount of data is reduced for the first time?
This should be a simple calculation. Even if this number cannot be
predicted in advance in pratice, it might be useful to estimate when I
should use the approach.
Proposal: add the following two paragraphs at the end of the section 8.4 Efficiency Gain

While the goal of this specification is to reduce the bandwidth, this technique might even lead to an increase in bandwidth usage under certain conditions.
Taking into account the overhead of exporting the commonPropertiesID values, if the commonPropertiesID values are not used in future Data Records, this technique would actually increase the export bandwidth. A typical case would be the assignments of Common Properties based on past observed traffic, hoping that future flows would contain the same characteristics.

Note that the efficiency gain would be directly proportional the re-use of the defined commonPropertiesID values (In other words, the more we re-use a commonPropertiesID value, the better the efficiency gain), with a theoretical limit where all the Data Records would use a single commonPropertiesID.
Feel free to modify the proposal as you wish.

Regards,
Gerhard

Juergen Quittek wrote:
  
Dear all,

As agreed at the IPFIX session in San Diego last week
this is the WG last call on the Internet draft on
Reducing redundancy in IPFIX and PSAMP reports,
draft-ietf-ipfix-reducing-redundancy-01.txt.

The WG last call starts today and will be closed on
December 1st.

Please review the draft and send your comments!  Please also
send a message to the mailing list if you reviewed it and
have no comment to make!

Thanks,

   Juergen


_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.org/mailman/listinfo/ipfix
    

  

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.org/mailman/listinfo/ipfix

--------------020501040504030605050604-- --===============1543867150== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1543867150==-- From ipfix-bounces@ietf.org Thu Dec 07 09:33:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKJQ-0001mN-1a; Thu, 07 Dec 2006 09:33:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKJN-0001mD-VD for ipfix@ietf.org; Thu, 07 Dec 2006 09:33:21 -0500 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsKJI-0005oh-VM for ipfix@ietf.org; Thu, 07 Dec 2006 09:33:21 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id BD0C8125; Thu, 7 Dec 2006 15:33:15 +0100 (MET) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44558-02; Thu, 7 Dec 2006 15:33:13 +0100 (MET) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 31CA7122; Thu, 7 Dec 2006 15:33:13 +0100 (MET) Message-ID: <45782657.9030100@informatik.uni-tuebingen.de> Date: Thu, 07 Dec 2006 15:33:59 +0100 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Benoit Claise Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455D917A.7020003@informatik.uni-tuebingen.de> <45782145.6000302@cisco.com> In-Reply-To: <45782145.6000302@cisco.com> X-Enigmail-Version: 0.94.0.0 X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1644004233==" Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1644004233== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000803050508060005090509" This is a cryptographically signed message in MIME format. --------------ms000803050508060005090509 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Benoit, Elisa, Benoit Claise wrote: >> p. 21: >> "In that case, for a flow of 1000 packets the amount of data can be >> decreased _by_ more than 33 percent" Actually, I thought I found a typo, thinking that "_by_" should be added ("decreased by"), but maybe I'm wrong and it's good English without. Sorry if my comment was not clear. > This comes from section 11.2 "For a flow of 1000 packets this sums up t= o > 20018 bytes. This is a decrease of more than 33 percent." > Maybe the proposal is to: > 1. Change section 11.2 to "For a flow of 1000 packets this sums up to > 20018 bytes. This is a decrease of 33 percents". > 2. Modify the first paragraph in section 8.4: >=20 > The passive One-Way Delay measurement example in section 11.2,=20 > which is a very special application where the proposed method is > very beneficial, uses IPFIX to export measurement data for each > received packet. In that case, for a flow of 1000 packets the amoun= t > of data can be decreased by 33 percents" >=20 > 3. Add an extra paragraph in section 8.4 to address "under conditions" > (i.e. your last remark) > See below. As you like. I'm also fine this the original phrase. >> Some comments on Section 8: >> >> The main advantage of the method specified in this document is the >> reduction in the amount of measurement data that has to be >> transferred from the Exporter to the Collector. >> >> I would like to add here "under some conditions" (or something similar= ) >> since the proposed method does not necessarily lead to a reduction of >> the amount of data. >> >> The transfer of the commonPropertiesIDs originates some overhead. >> Note that IPFIX allows reduced-size encoding of Information >> Elements. In cases where the range of the commonPropertiesID can b= e >> restricted, reduced-size encoding can be applied also to the >> commonPropertiesID, and would result in a further bandwidth >> efficiency gain. >> >> I would say: the overhead of the commonPropertiesID IE is very >> significant if 64 bit are used. The length of the commonPropertiesID >> field also gives you a necessary condition if you ever want to reach a >> reduced amount of data: The length must be shorter than the length of >> the replaced IEs, otherwise you even increase the amount monitoring da= ta! >> As a consequence, reduced-size encoding should be used whenever possib= le. >> =20 > Agreed. Elisa proposed a "RECOMMENDED" here, but see my answer: http://www1.ietf.org/mail-archive/web/ipfix/current/msg03774.html "You should add that the length of the commonPropertiesID field has to be shorter than the length of the replaced fields, otherwise the amount of data is increased. You could note that a big difference between the length of the replaced fields and the length of the commonPropertiesID field increases the efficiency gain." >> The example in section 11.2 below uses IPFIX to export measurement >> data for each received packet. In that case, for a flow of 1000 >> packets the amount of data can be decreased more than 33 percent. >> >> The example in 11.2 refers to OWD measurements, which is a very specia= l >> application where the proposed method is very beneficial. Maybe you >> should mention "OWD measurements" here, since 33 percent may not be th= e >> general case. >> >> While the goal of this specification is to reduce the bandwidth, th= e >> efficiency might be limited. >> >> As I said before, you can even increase the amount of data with the >> proposed method. So I suggest to explain under which conditions the >> approach achieves its goal. >> How many times do I need to refer to the common properties until the >> amount of data is reduced for the first time? >> This should be a simple calculation. Even if this number cannot be >> predicted in advance in pratice, it might be useful to estimate when I >> should use the approach. >> =20 > Proposal: add the following two paragraphs at the end of the section 8.= 4 > Efficiency Gain >=20 > While the goal of this specification is to reduce the bandwidth, > this technique might even lead to an increase in bandwidth usage > under certain conditions. > Taking into account the overhead of exporting the commonPropertiesI= D > values, if the commonPropertiesID values are not used in future Dat= a > Records, this technique would actually increase the export > bandwidth. A typical case would be the assignments of Common > Properties based on past observed traffic, hoping that future flows > would contain the same characteristics. >=20 > Note that the efficiency gain would be directly proportional the > re-use of the defined commonPropertiesID values (In other words, th= e > more we re-use a commonPropertiesID value, the better the efficienc= y > gain), with a theoretical limit where all the Data Records would us= e > a single commonPropertiesID. >=20 > Feel free to modify the proposal as you wish. Looks good to me. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms000803050508060005090509 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICEFnnd0ztch8/FKZyDU4aYM8wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDIxMDE3MjI0OVoX DTA3MDIxMDE3MjI0OVowbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOJTlGpd UzaDtPwN+ScPJAXpfQletJ+7B/Zr5MDTyHrAGyXcwsWZB6y7PEO+blM2X66y7+e0kRZVUJYo ycFQZ2dOFS+L2cwNeiea0fEi4wGZ507kYPsFWlYFmB0dRTTTrz6zQaxpsBllvJsTHeYKJ5hc gXyP4la+7ArnYidjqcEpwJqiIO5BNIiX/6WR70tDb7cgJgA2VTgLgWWUbD3cPc9lP0wgEjVB 1/KBZ7F1gVKWCatZSsjBUnf9OO9/DexMdeKCtho06/56ddljFbwwLO4kzy06yzdFlruUWtHZ /hE+IwN/twj+Iv9B6Q2buWICUZi8GHzUKK4CoKsYW93ah5sCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEArrY1DQ7N6RiHFbjBcsmGfm0IqlCOH+X1c77jMwjR2TFYlsb9urRP ZaFFhVo6lKmZSw2+0QPXhtG6hkFCruSzqRA2Xc+ePpm/nftGLrE4kXsnza35lqfCYfKBVk/i 5ugddlcc3FzyCcBnCOOy+XCt5JfweGCkbsMyuVL1oTRHv88wggMVMIICfqADAgECAhBZ53dM 7XIfPxSmcg1OGmDPMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjAyMTAxNzIyNDlaFw0wNzAyMTAxNzIyNDlaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDiU5RqXVM2g7T8DfknDyQF6X0JXrSf uwf2a+TA08h6wBsl3MLFmQesuzxDvm5TNl+usu/ntJEWVVCWKMnBUGdnThUvi9nMDXonmtHx IuMBmedO5GD7BVpWBZgdHUU0068+s0GsabAZZbybEx3mCieYXIF8j+JWvuwK52InY6nBKcCa oiDuQTSIl/+lke9LQ2+3ICYANlU4C4FllGw93D3PZT9MIBI1QdfygWexdYFSlgmrWUrIwVJ3 /Tjvfw3sTHXigrYaNOv+enXZYxW8MCzuJM8tOss3RZa7lFrR2f4RPiMDf7cI/iL/QekNm7li AlGYvBh81CiuAqCrGFvd2oebAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAK62 NQ0OzekYhxW4wXLJhn5tCKpQjh/l9XO+4zMI0dkxWJbG/bq0T2WhRYVaOpSpmUsNvtED14bR uoZBQq7ks6kQNl3Pnj6Zv537Ri6xOJF7J82t+ZanwmHygVZP4uboHXZXHNxc8gnAZwjjsvlw reSX8HhgpG7DMrlS9aE0R7/PMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBZ53dM 7XIfPxSmcg1OGmDPMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA2MTIwNzE0MzM1OVowIwYJKoZIhvcNAQkEMRYEFAWB7HOn6682 kaTftTLt/R5E79t7MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ Wed3TO1yHz8UpnINThpgzzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQWed3TO1yHz8UpnINThpgzzANBgkqhkiG 9w0BAQEFAASCAQCjOx85zh2OXn7EP9UTJfIkwAyvwAeFKgwRxCy1C5RAiS5DlptgM9rP0dTM QI7rmntNCSJeUAYbLeV/AfdTNocZw0UFFeUUk2i47Gk82GIeugV5zMUKYB3kEkYHd1WChkvc Dp8ovtgwYK7hpIHX3/bMarTbtLDDStyRsbBU0gwhg2Y4ktte1ayuHzXA1QjKJmzUV3BHgxGS t8/L6ddZ3Cw0ALiH6JXHmIh0fzJijYPCxA0IMFo83SRrENEr6uQWaOEN52f9WnUaBzAkCZHq WhEXwzlTK4Ambx8KLAwXYNktkKJzariguC6HovAnMhjekkI9yfz23h/DE816JJaINK7FAAAA AAAA --------------ms000803050508060005090509-- --===============1644004233== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1644004233==-- From ipfix-bounces@ietf.org Thu Dec 07 09:33:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKJQ-0001mN-1a; Thu, 07 Dec 2006 09:33:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKJN-0001mD-VD for ipfix@ietf.org; Thu, 07 Dec 2006 09:33:21 -0500 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsKJI-0005oh-VM for ipfix@ietf.org; Thu, 07 Dec 2006 09:33:21 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id BD0C8125; Thu, 7 Dec 2006 15:33:15 +0100 (MET) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44558-02; Thu, 7 Dec 2006 15:33:13 +0100 (MET) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 31CA7122; Thu, 7 Dec 2006 15:33:13 +0100 (MET) Message-ID: <45782657.9030100@informatik.uni-tuebingen.de> Date: Thu, 07 Dec 2006 15:33:59 +0100 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Benoit Claise Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455D917A.7020003@informatik.uni-tuebingen.de> <45782145.6000302@cisco.com> In-Reply-To: <45782145.6000302@cisco.com> X-Enigmail-Version: 0.94.0.0 X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1644004233==" Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1644004233== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000803050508060005090509" This is a cryptographically signed message in MIME format. --------------ms000803050508060005090509 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Benoit, Elisa, Benoit Claise wrote: >> p. 21: >> "In that case, for a flow of 1000 packets the amount of data can be >> decreased _by_ more than 33 percent" Actually, I thought I found a typo, thinking that "_by_" should be added ("decreased by"), but maybe I'm wrong and it's good English without. Sorry if my comment was not clear. > This comes from section 11.2 "For a flow of 1000 packets this sums up t= o > 20018 bytes. This is a decrease of more than 33 percent." > Maybe the proposal is to: > 1. Change section 11.2 to "For a flow of 1000 packets this sums up to > 20018 bytes. This is a decrease of 33 percents". > 2. Modify the first paragraph in section 8.4: >=20 > The passive One-Way Delay measurement example in section 11.2,=20 > which is a very special application where the proposed method is > very beneficial, uses IPFIX to export measurement data for each > received packet. In that case, for a flow of 1000 packets the amoun= t > of data can be decreased by 33 percents" >=20 > 3. Add an extra paragraph in section 8.4 to address "under conditions" > (i.e. your last remark) > See below. As you like. I'm also fine this the original phrase. >> Some comments on Section 8: >> >> The main advantage of the method specified in this document is the >> reduction in the amount of measurement data that has to be >> transferred from the Exporter to the Collector. >> >> I would like to add here "under some conditions" (or something similar= ) >> since the proposed method does not necessarily lead to a reduction of >> the amount of data. >> >> The transfer of the commonPropertiesIDs originates some overhead. >> Note that IPFIX allows reduced-size encoding of Information >> Elements. In cases where the range of the commonPropertiesID can b= e >> restricted, reduced-size encoding can be applied also to the >> commonPropertiesID, and would result in a further bandwidth >> efficiency gain. >> >> I would say: the overhead of the commonPropertiesID IE is very >> significant if 64 bit are used. The length of the commonPropertiesID >> field also gives you a necessary condition if you ever want to reach a >> reduced amount of data: The length must be shorter than the length of >> the replaced IEs, otherwise you even increase the amount monitoring da= ta! >> As a consequence, reduced-size encoding should be used whenever possib= le. >> =20 > Agreed. Elisa proposed a "RECOMMENDED" here, but see my answer: http://www1.ietf.org/mail-archive/web/ipfix/current/msg03774.html "You should add that the length of the commonPropertiesID field has to be shorter than the length of the replaced fields, otherwise the amount of data is increased. You could note that a big difference between the length of the replaced fields and the length of the commonPropertiesID field increases the efficiency gain." >> The example in section 11.2 below uses IPFIX to export measurement >> data for each received packet. In that case, for a flow of 1000 >> packets the amount of data can be decreased more than 33 percent. >> >> The example in 11.2 refers to OWD measurements, which is a very specia= l >> application where the proposed method is very beneficial. Maybe you >> should mention "OWD measurements" here, since 33 percent may not be th= e >> general case. >> >> While the goal of this specification is to reduce the bandwidth, th= e >> efficiency might be limited. >> >> As I said before, you can even increase the amount of data with the >> proposed method. So I suggest to explain under which conditions the >> approach achieves its goal. >> How many times do I need to refer to the common properties until the >> amount of data is reduced for the first time? >> This should be a simple calculation. Even if this number cannot be >> predicted in advance in pratice, it might be useful to estimate when I >> should use the approach. >> =20 > Proposal: add the following two paragraphs at the end of the section 8.= 4 > Efficiency Gain >=20 > While the goal of this specification is to reduce the bandwidth, > this technique might even lead to an increase in bandwidth usage > under certain conditions. > Taking into account the overhead of exporting the commonPropertiesI= D > values, if the commonPropertiesID values are not used in future Dat= a > Records, this technique would actually increase the export > bandwidth. A typical case would be the assignments of Common > Properties based on past observed traffic, hoping that future flows > would contain the same characteristics. >=20 > Note that the efficiency gain would be directly proportional the > re-use of the defined commonPropertiesID values (In other words, th= e > more we re-use a commonPropertiesID value, the better the efficienc= y > gain), with a theoretical limit where all the Data Records would us= e > a single commonPropertiesID. >=20 > Feel free to modify the proposal as you wish. Looks good to me. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms000803050508060005090509 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICEFnnd0ztch8/FKZyDU4aYM8wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDIxMDE3MjI0OVoX DTA3MDIxMDE3MjI0OVowbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOJTlGpd UzaDtPwN+ScPJAXpfQletJ+7B/Zr5MDTyHrAGyXcwsWZB6y7PEO+blM2X66y7+e0kRZVUJYo ycFQZ2dOFS+L2cwNeiea0fEi4wGZ507kYPsFWlYFmB0dRTTTrz6zQaxpsBllvJsTHeYKJ5hc gXyP4la+7ArnYidjqcEpwJqiIO5BNIiX/6WR70tDb7cgJgA2VTgLgWWUbD3cPc9lP0wgEjVB 1/KBZ7F1gVKWCatZSsjBUnf9OO9/DexMdeKCtho06/56ddljFbwwLO4kzy06yzdFlruUWtHZ /hE+IwN/twj+Iv9B6Q2buWICUZi8GHzUKK4CoKsYW93ah5sCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEArrY1DQ7N6RiHFbjBcsmGfm0IqlCOH+X1c77jMwjR2TFYlsb9urRP ZaFFhVo6lKmZSw2+0QPXhtG6hkFCruSzqRA2Xc+ePpm/nftGLrE4kXsnza35lqfCYfKBVk/i 5ugddlcc3FzyCcBnCOOy+XCt5JfweGCkbsMyuVL1oTRHv88wggMVMIICfqADAgECAhBZ53dM 7XIfPxSmcg1OGmDPMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjAyMTAxNzIyNDlaFw0wNzAyMTAxNzIyNDlaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDiU5RqXVM2g7T8DfknDyQF6X0JXrSf uwf2a+TA08h6wBsl3MLFmQesuzxDvm5TNl+usu/ntJEWVVCWKMnBUGdnThUvi9nMDXonmtHx IuMBmedO5GD7BVpWBZgdHUU0068+s0GsabAZZbybEx3mCieYXIF8j+JWvuwK52InY6nBKcCa oiDuQTSIl/+lke9LQ2+3ICYANlU4C4FllGw93D3PZT9MIBI1QdfygWexdYFSlgmrWUrIwVJ3 /Tjvfw3sTHXigrYaNOv+enXZYxW8MCzuJM8tOss3RZa7lFrR2f4RPiMDf7cI/iL/QekNm7li AlGYvBh81CiuAqCrGFvd2oebAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAK62 NQ0OzekYhxW4wXLJhn5tCKpQjh/l9XO+4zMI0dkxWJbG/bq0T2WhRYVaOpSpmUsNvtED14bR uoZBQq7ks6kQNl3Pnj6Zv537Ri6xOJF7J82t+ZanwmHygVZP4uboHXZXHNxc8gnAZwjjsvlw reSX8HhgpG7DMrlS9aE0R7/PMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBZ53dM 7XIfPxSmcg1OGmDPMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA2MTIwNzE0MzM1OVowIwYJKoZIhvcNAQkEMRYEFAWB7HOn6682 kaTftTLt/R5E79t7MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ Wed3TO1yHz8UpnINThpgzzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQWed3TO1yHz8UpnINThpgzzANBgkqhkiG 9w0BAQEFAASCAQCjOx85zh2OXn7EP9UTJfIkwAyvwAeFKgwRxCy1C5RAiS5DlptgM9rP0dTM QI7rmntNCSJeUAYbLeV/AfdTNocZw0UFFeUUk2i47Gk82GIeugV5zMUKYB3kEkYHd1WChkvc Dp8ovtgwYK7hpIHX3/bMarTbtLDDStyRsbBU0gwhg2Y4ktte1ayuHzXA1QjKJmzUV3BHgxGS t8/L6ddZ3Cw0ALiH6JXHmIh0fzJijYPCxA0IMFo83SRrENEr6uQWaOEN52f9WnUaBzAkCZHq WhEXwzlTK4Ambx8KLAwXYNktkKJzariguC6HovAnMhjekkI9yfz23h/DE816JJaINK7FAAAA AAAA --------------ms000803050508060005090509-- --===============1644004233== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1644004233==-- From ipfix-bounces@ietf.org Thu Dec 07 10:04:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKmi-0006t2-Vu; Thu, 07 Dec 2006 10:03:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKmh-0006sw-Uf for ipfix@ietf.org; Thu, 07 Dec 2006 10:03:39 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsKmd-0001wR-GL for ipfix@ietf.org; Thu, 07 Dec 2006 10:03:39 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Dec 2006 16:03:31 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB7F3U6e014103; Thu, 7 Dec 2006 16:03:30 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB7F3TAJ015590; Thu, 7 Dec 2006 16:03:30 +0100 (MET) Received: from [144.254.153.27] (dhcp-144-254-153-27.cisco.com [144.254.153.27]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA07926; Thu, 7 Dec 2006 15:03:29 GMT Message-ID: <45782D40.20002@cisco.com> Date: Thu, 07 Dec 2006 15:03:28 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Benoit Claise Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> <45780A37.8010905@cisco.com> In-Reply-To: <45780A37.8010905@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12807; t=1165503810; x=1166367810; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20WG=20last=20call=20on=20draft-ietf-ipfix-re ducing-redundancy-01.txt=0A=20until=20December=201st |Sender:=20; bh=zBY1KT2QTHyRmYpKz95BVvHekGdLZmEpALZuukiXRX0=; b=aFenyW1JEj0vCiprm6dCOeEc6HlE4+Vs1sWTJqwuwYFCJO0INIwbTYYbBvaK5svwBjZrdQmf 9ZaRXIx5uyeZAOtI1kni9du63obQVv1XlcBmBtXTGNETZ7BYid0qINx/; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Benoit Claise wrote: > Andrew, [SNIP] >> My concern wasn't really directed at the draft itself, but just the >> name "common properties". From IPFIX-PROTO: >> "A Flow is defined as a set of IP packets passing an Observation >> Point in the network during a certain time interval. All packets >> belonging to a particular Flow have a set of common properties." >> >> And then from IPFIX-INFO: >> Description of commonPropertiesId: >> An identifier of a set of common properties that is unique per >> Observation Domain. Typically, this Information Element is used >> to link to information reported in separate records. >> >> The terminology is almost identical. The commonPropertiesId refers >> to "a set of common properties" that is quite different from ones >> that determine a Flow. > > What about something such as? > Description of commonPropertiesId: > An identifier of a set of common properties between different Flows. > The that is unique per Observation Domain. > Typically, this Information Element is used > to link to information reported in separate records. I suggested something quite similar to Elisa: An identifier of a set of properties that is common across more that one Flow. Typically, this Information Element is used to link to information reported in separate records. The identifier is unique per Transport Session and Observation Domain. Note: the uniqueness of the cpID needs redefined to include the Transport Session. >>>> Is there any need to define a new term for "Specific >>>> Properties"? These are just part of a normal Data Record. >>>> For example: >>>> "... The rows are then referenced by the Specific Properties >>>> by using the appropriate value for the Common Properties >>>> identifier." >>>> >>>> could simply be: >>>> "... The rows are then referenced by Data Records by >>>> using the appropriate value for the Common Properties >>>> identifier." >>> >>> In your example, the "Data Records" doesn't mean the full data >>> records before applying the redundancy reduction mechanism but only a >>> part of it. >>> So it might be confusing... That's the trick we found. >>> >>> However, I could agree that the draft would work without a formal >>> (upper case) definition.... So do you have the same idea for the >>> Common Properties? >> >> Considering there is a commonPropertiesID, I am quite happy with you >> referring to Common Properties. > > Ok. So let's see how the draft looks like if we remove the "Specific > Properties" formal definition but if we keep the "Common Properties" one. Sounds good. >> There seems to be a bit of a conceptual difference here though. You >> seem to imagine that an Exporting Process has a set of IPFIX Data >> Records which it then applies some processing to to get some new >> special IPFIX Data Records and some Common Property options. The >> original set of Data Records may never actually exist, depending on >> how the scheme is implemented. > > Sure, this is an implementation detail, but conceptually, we want to > reduce "something". How do you call this "something"? There are already several names for the something. Most common is Flows or data. Sometimes even "Flow Record" but I think that term is too easily confused with "Data Record". Data Record has a very specific meaning and is not what is meant here. A Data Record is defined by an IPFIX Template. The Flows that are sent from the Metering Process to the Exporting Process have no set format. > This document describes a bandwidth saving method for exporting flow > or packet information using the IP Flow Information Export (IPFIX) > protocol. > > Anyway, I think that we're diverging from your initial issue which was about "Specific > Properties"... > > >> For me, the only set of IPFIX Data >> Records to consider are the ones which are actually sent. [SNIP] >>>> Are they meaningful in IPFIX? i.e. per the PROTO will an option >>>> with scope but no data be deemed invalidated by the Collector. >>>> Scope without data is the same as never having recieved the >>>> mapping in the first place. I think that it would be up to the >>>> implementation but it seems like a good idea so if we can't add >>>> it to the PROTO can we put it in the implementation guidelines? >>>> >>>> How do you propose to withdraw common properties when they are >>>> associated with a template rather than the Common Properties index? >>> >>> I don't ;) This is the reason why the use the Common Properties index >>> is a cleaner design. >> >> I think withdrawal messages should work in general for options >> data, so why not send an empty record with the template as scope? > I guess that you wanted to say: > I think withdrawal messages should work in general for options > data, so why not send an empty record with the _common property_ as > scope? > Well, I prefer to have a clear design so that this draft is really > independent, with its withdrawal mechanism. Then using the template ID to identify Common Properties can be mentioned in passing, which I guess it is, in 8.3, however it is also discussed in a little detail in section 4.1.1 (and figure 9), and section 7. It seems that these details should be removed. > Otherwise, you're telling in this I-RFC the standard track IPFIX > protocol should consider an empty record as a withdrawal. This could be > true a true assumption, but this is not clearly explained/specified! Not at all. Either withdrawing options in this way is valid in IPFIX, in which case Reducing Redundancy can use it, or it a valid technique for anybody. Now I'm not declaring that this is a technique for all is within the scope of the draft. If red-red is going to use this technique though we should decide in the WG that it is valid and say so in the implementation guidelines or the "Managing Scope" draft. >>>> 4. Specifications for bandwidth saving information export >>>> >>>> What is being specified here that isn't true for ALL options as >>>> described in IPFIX-PROTO? >>> >>> What do you suggest? >> >> Well it seems that section three really explains almost the same >> thing 3 times. The section 4 explains most of it again (with a >> bit more info) another 3 times. >> >> I would prefer section 3 to simply explain the technique. Walk >> through how the information from a Flow is split into two parts, >> and then add the bit from section 4 how these two parts are >> exported. >> >> Using more than one CPid in a record should be part of the >> advanced techniques once the basics are made clear. Per packet >> should just be a detailed example at the end. >> >>>> I think section 3 does a better job of explaining how all this >>>> works. I'm really not sure what section 4 adds. >>> >>> The idea was to put the specs in section 4 while the section 3 was >>> the high level solution. >> >> Rereading it, I see that now, but there seems to be a fair amount >> of repetition. > > Let me ask the question differently. Do you see this repetition as problem? Yes. I think the draft would be cleared if how options work was left to IPFIX-PROTO. red-red should reference that, then build describe exactly how the basic Common Properties work for the simple case, from concept to execution. The other variations on this can then build upon the proper foundation of the simple case. This way the reader can understand how the system works before you introduce the concept of including more than one commonPropertiesId in a Template/Data Record. [SNIP] >>>> The text reads: >>>> Common Properties IDs are unique per SCTP association and per >>>> Observation Domain. If the Collecting Process receives a common >>>> Properties ID which has already been received but which has not >>>> previously been withdrawn (i.e. a commonPropertiesID from the same >>>> Exporter Observation Domain with the same Template ID received on >>>> the SCTP association), then the Collecting Process MUST shutdown the >>>> association. >>> This is similar to [IPFIX-PROTO] >>> >>> Template IDs are unique per SCTP association and per Observation >>> Domain. If the Collecting Process receives a Template which has >>> already been received but which has not previously been withdrawn >>> (i.e. a Template Record from the same Exporter Observation Domain >>> with the same Template ID received on the SCTP association), then >>> the Collecting Process MUST shutdown the association. >>> >>>> >>>> and: >>>> If the Collecting Process receives a Common Properties Withdrawal >>>> message for a Common Properties that it has not received before on >>>> this SCTP assocation, it MUST reset the SCTP association, discard >>>> the IPFIX Message, and SHOULD log the error as it does for malformed >>>> IPFIX Messages. >>>> I think this might go against IPFIX-PROTO. >>> This is similar to [IPFIX-PROTO] >> >> These are similar to what IPFIX-PROTO says about templates, but that >> doesn't mean the text can just be used to talk about Data Records sent >> for Options Templates. >> >> Option data withdrawal messages are not mentioned in IPFIX-PROTO, >> although I think they can work. However, in general options data with >> the same scope as an earlier record will just overwrite the older >> record. > > See my previous remark about an independent draft. What? AFAIK red-red is an information draft aimed at explaining how a technique you can use with an IPFIX compliant Exporter/Collector. IPFIX-PROTO says nothing about withdrawing options data and if this draft says: If the Collecting Process receives a common Properties ID which has already been received but which has not previously been withdrawn ... then the Collecting Process MUST shutdown the association. Then it is expanding on what IPFIX-PROTO says and is no longer just a way of using IPFIX but an extension to it. If we accept that withdrawing options is part of IPFIX today then this is about the only extension being asked for. I can see why you want it, but the problem you are trying to solve here is the same for ALL options, not just Common Property definitions. [SNIP] > In this draft, we require a mechanism such as the following: > "If the Common Properties are not refreshed before that lifetime has > expired, the Collecting Process MUST discard the corresponding > definition of the commonPropertiesID and any current and future > associated Data Records. In which case, an alarm MUST be logged. " Why is it required for common properties and not other options? Why is it ok to use a mechanism that is not part of the protocol? > Because there is no withdraw message with UDP: > " If UDP is selected as the transport protocol, the commonPropertiesID > Template Withdraw Messages MUST not be used, as this method is > inefficient due to the unreliable nature of UDP." > So I'm wondering why we are discussing this? Because you're trying to extend the protocol because you don't think it's good enough. While I agree that the protocol could do a better job of handling options, I think this extension is out of scope of the draft. > Let me come back to your questions: > Q: What happened to storing it until the option turned up. > A: > > If the Collecting Process has received the Specific Properties Data > Record before the associated Common Properties Data Record, the > Collecting Process MAY store the Specific Properties Data Record and > await the retransmission or out-of-order arrival of the Common > Properties Data Record. Fine. > Q: Furthermore you shouldn't dictate the the record is discarded, just > because you > can't tell a piece of potentially trivial information about a flow > doesn't mean it's meaningless. > A: without the Common Properties, we can't decode the records. So we > must discard them Surely that depends on what the Common Properties show. Perhaps the particular properties that are common aren't important. Similarly, if a normal full Data Record was received without something the exporter thought was necessary, it could be discarded. > Q: The Common Properties in question could be anything. > A: I think we should limit this draft to Common Properties It wasn't a question and your answer makes no sense. I'm saying that the properties defined by a particular cpID could be something that is not important to the Collector. Perhaps it's the classOfService field and the collector doesn't use it. Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 10:04:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKmi-0006t2-Vu; Thu, 07 Dec 2006 10:03:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKmh-0006sw-Uf for ipfix@ietf.org; Thu, 07 Dec 2006 10:03:39 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsKmd-0001wR-GL for ipfix@ietf.org; Thu, 07 Dec 2006 10:03:39 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Dec 2006 16:03:31 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB7F3U6e014103; Thu, 7 Dec 2006 16:03:30 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB7F3TAJ015590; Thu, 7 Dec 2006 16:03:30 +0100 (MET) Received: from [144.254.153.27] (dhcp-144-254-153-27.cisco.com [144.254.153.27]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA07926; Thu, 7 Dec 2006 15:03:29 GMT Message-ID: <45782D40.20002@cisco.com> Date: Thu, 07 Dec 2006 15:03:28 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Benoit Claise Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> <45780A37.8010905@cisco.com> In-Reply-To: <45780A37.8010905@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12807; t=1165503810; x=1166367810; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20WG=20last=20call=20on=20draft-ietf-ipfix-re ducing-redundancy-01.txt=0A=20until=20December=201st |Sender:=20; bh=zBY1KT2QTHyRmYpKz95BVvHekGdLZmEpALZuukiXRX0=; b=aFenyW1JEj0vCiprm6dCOeEc6HlE4+Vs1sWTJqwuwYFCJO0INIwbTYYbBvaK5svwBjZrdQmf 9ZaRXIx5uyeZAOtI1kni9du63obQVv1XlcBmBtXTGNETZ7BYid0qINx/; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Benoit Claise wrote: > Andrew, [SNIP] >> My concern wasn't really directed at the draft itself, but just the >> name "common properties". From IPFIX-PROTO: >> "A Flow is defined as a set of IP packets passing an Observation >> Point in the network during a certain time interval. All packets >> belonging to a particular Flow have a set of common properties." >> >> And then from IPFIX-INFO: >> Description of commonPropertiesId: >> An identifier of a set of common properties that is unique per >> Observation Domain. Typically, this Information Element is used >> to link to information reported in separate records. >> >> The terminology is almost identical. The commonPropertiesId refers >> to "a set of common properties" that is quite different from ones >> that determine a Flow. > > What about something such as? > Description of commonPropertiesId: > An identifier of a set of common properties between different Flows. > The that is unique per Observation Domain. > Typically, this Information Element is used > to link to information reported in separate records. I suggested something quite similar to Elisa: An identifier of a set of properties that is common across more that one Flow. Typically, this Information Element is used to link to information reported in separate records. The identifier is unique per Transport Session and Observation Domain. Note: the uniqueness of the cpID needs redefined to include the Transport Session. >>>> Is there any need to define a new term for "Specific >>>> Properties"? These are just part of a normal Data Record. >>>> For example: >>>> "... The rows are then referenced by the Specific Properties >>>> by using the appropriate value for the Common Properties >>>> identifier." >>>> >>>> could simply be: >>>> "... The rows are then referenced by Data Records by >>>> using the appropriate value for the Common Properties >>>> identifier." >>> >>> In your example, the "Data Records" doesn't mean the full data >>> records before applying the redundancy reduction mechanism but only a >>> part of it. >>> So it might be confusing... That's the trick we found. >>> >>> However, I could agree that the draft would work without a formal >>> (upper case) definition.... So do you have the same idea for the >>> Common Properties? >> >> Considering there is a commonPropertiesID, I am quite happy with you >> referring to Common Properties. > > Ok. So let's see how the draft looks like if we remove the "Specific > Properties" formal definition but if we keep the "Common Properties" one. Sounds good. >> There seems to be a bit of a conceptual difference here though. You >> seem to imagine that an Exporting Process has a set of IPFIX Data >> Records which it then applies some processing to to get some new >> special IPFIX Data Records and some Common Property options. The >> original set of Data Records may never actually exist, depending on >> how the scheme is implemented. > > Sure, this is an implementation detail, but conceptually, we want to > reduce "something". How do you call this "something"? There are already several names for the something. Most common is Flows or data. Sometimes even "Flow Record" but I think that term is too easily confused with "Data Record". Data Record has a very specific meaning and is not what is meant here. A Data Record is defined by an IPFIX Template. The Flows that are sent from the Metering Process to the Exporting Process have no set format. > This document describes a bandwidth saving method for exporting flow > or packet information using the IP Flow Information Export (IPFIX) > protocol. > > Anyway, I think that we're diverging from your initial issue which was about "Specific > Properties"... > > >> For me, the only set of IPFIX Data >> Records to consider are the ones which are actually sent. [SNIP] >>>> Are they meaningful in IPFIX? i.e. per the PROTO will an option >>>> with scope but no data be deemed invalidated by the Collector. >>>> Scope without data is the same as never having recieved the >>>> mapping in the first place. I think that it would be up to the >>>> implementation but it seems like a good idea so if we can't add >>>> it to the PROTO can we put it in the implementation guidelines? >>>> >>>> How do you propose to withdraw common properties when they are >>>> associated with a template rather than the Common Properties index? >>> >>> I don't ;) This is the reason why the use the Common Properties index >>> is a cleaner design. >> >> I think withdrawal messages should work in general for options >> data, so why not send an empty record with the template as scope? > I guess that you wanted to say: > I think withdrawal messages should work in general for options > data, so why not send an empty record with the _common property_ as > scope? > Well, I prefer to have a clear design so that this draft is really > independent, with its withdrawal mechanism. Then using the template ID to identify Common Properties can be mentioned in passing, which I guess it is, in 8.3, however it is also discussed in a little detail in section 4.1.1 (and figure 9), and section 7. It seems that these details should be removed. > Otherwise, you're telling in this I-RFC the standard track IPFIX > protocol should consider an empty record as a withdrawal. This could be > true a true assumption, but this is not clearly explained/specified! Not at all. Either withdrawing options in this way is valid in IPFIX, in which case Reducing Redundancy can use it, or it a valid technique for anybody. Now I'm not declaring that this is a technique for all is within the scope of the draft. If red-red is going to use this technique though we should decide in the WG that it is valid and say so in the implementation guidelines or the "Managing Scope" draft. >>>> 4. Specifications for bandwidth saving information export >>>> >>>> What is being specified here that isn't true for ALL options as >>>> described in IPFIX-PROTO? >>> >>> What do you suggest? >> >> Well it seems that section three really explains almost the same >> thing 3 times. The section 4 explains most of it again (with a >> bit more info) another 3 times. >> >> I would prefer section 3 to simply explain the technique. Walk >> through how the information from a Flow is split into two parts, >> and then add the bit from section 4 how these two parts are >> exported. >> >> Using more than one CPid in a record should be part of the >> advanced techniques once the basics are made clear. Per packet >> should just be a detailed example at the end. >> >>>> I think section 3 does a better job of explaining how all this >>>> works. I'm really not sure what section 4 adds. >>> >>> The idea was to put the specs in section 4 while the section 3 was >>> the high level solution. >> >> Rereading it, I see that now, but there seems to be a fair amount >> of repetition. > > Let me ask the question differently. Do you see this repetition as problem? Yes. I think the draft would be cleared if how options work was left to IPFIX-PROTO. red-red should reference that, then build describe exactly how the basic Common Properties work for the simple case, from concept to execution. The other variations on this can then build upon the proper foundation of the simple case. This way the reader can understand how the system works before you introduce the concept of including more than one commonPropertiesId in a Template/Data Record. [SNIP] >>>> The text reads: >>>> Common Properties IDs are unique per SCTP association and per >>>> Observation Domain. If the Collecting Process receives a common >>>> Properties ID which has already been received but which has not >>>> previously been withdrawn (i.e. a commonPropertiesID from the same >>>> Exporter Observation Domain with the same Template ID received on >>>> the SCTP association), then the Collecting Process MUST shutdown the >>>> association. >>> This is similar to [IPFIX-PROTO] >>> >>> Template IDs are unique per SCTP association and per Observation >>> Domain. If the Collecting Process receives a Template which has >>> already been received but which has not previously been withdrawn >>> (i.e. a Template Record from the same Exporter Observation Domain >>> with the same Template ID received on the SCTP association), then >>> the Collecting Process MUST shutdown the association. >>> >>>> >>>> and: >>>> If the Collecting Process receives a Common Properties Withdrawal >>>> message for a Common Properties that it has not received before on >>>> this SCTP assocation, it MUST reset the SCTP association, discard >>>> the IPFIX Message, and SHOULD log the error as it does for malformed >>>> IPFIX Messages. >>>> I think this might go against IPFIX-PROTO. >>> This is similar to [IPFIX-PROTO] >> >> These are similar to what IPFIX-PROTO says about templates, but that >> doesn't mean the text can just be used to talk about Data Records sent >> for Options Templates. >> >> Option data withdrawal messages are not mentioned in IPFIX-PROTO, >> although I think they can work. However, in general options data with >> the same scope as an earlier record will just overwrite the older >> record. > > See my previous remark about an independent draft. What? AFAIK red-red is an information draft aimed at explaining how a technique you can use with an IPFIX compliant Exporter/Collector. IPFIX-PROTO says nothing about withdrawing options data and if this draft says: If the Collecting Process receives a common Properties ID which has already been received but which has not previously been withdrawn ... then the Collecting Process MUST shutdown the association. Then it is expanding on what IPFIX-PROTO says and is no longer just a way of using IPFIX but an extension to it. If we accept that withdrawing options is part of IPFIX today then this is about the only extension being asked for. I can see why you want it, but the problem you are trying to solve here is the same for ALL options, not just Common Property definitions. [SNIP] > In this draft, we require a mechanism such as the following: > "If the Common Properties are not refreshed before that lifetime has > expired, the Collecting Process MUST discard the corresponding > definition of the commonPropertiesID and any current and future > associated Data Records. In which case, an alarm MUST be logged. " Why is it required for common properties and not other options? Why is it ok to use a mechanism that is not part of the protocol? > Because there is no withdraw message with UDP: > " If UDP is selected as the transport protocol, the commonPropertiesID > Template Withdraw Messages MUST not be used, as this method is > inefficient due to the unreliable nature of UDP." > So I'm wondering why we are discussing this? Because you're trying to extend the protocol because you don't think it's good enough. While I agree that the protocol could do a better job of handling options, I think this extension is out of scope of the draft. > Let me come back to your questions: > Q: What happened to storing it until the option turned up. > A: > > If the Collecting Process has received the Specific Properties Data > Record before the associated Common Properties Data Record, the > Collecting Process MAY store the Specific Properties Data Record and > await the retransmission or out-of-order arrival of the Common > Properties Data Record. Fine. > Q: Furthermore you shouldn't dictate the the record is discarded, just > because you > can't tell a piece of potentially trivial information about a flow > doesn't mean it's meaningless. > A: without the Common Properties, we can't decode the records. So we > must discard them Surely that depends on what the Common Properties show. Perhaps the particular properties that are common aren't important. Similarly, if a normal full Data Record was received without something the exporter thought was necessary, it could be discarded. > Q: The Common Properties in question could be anything. > A: I think we should limit this draft to Common Properties It wasn't a question and your answer makes no sense. I'm saying that the properties defined by a particular cpID could be something that is not important to the Collector. Perhaps it's the classOfService field and the collector doesn't use it. Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 10:10:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKtb-0005nB-NW; Thu, 07 Dec 2006 10:10:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKta-0005mL-5R for ipfix@ietf.org; Thu, 07 Dec 2006 10:10:46 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsKtV-0003BQ-V7 for ipfix@ietf.org; Thu, 07 Dec 2006 10:10:46 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB7FAfT25772; Thu, 7 Dec 2006 16:10:41 +0100 (CET) Received: from [10.61.66.18] (ams3-vpn-dhcp530.cisco.com [10.61.66.18]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB7FAeW02016; Thu, 7 Dec 2006 16:10:40 +0100 (CET) Message-ID: <45782EF1.7090809@cisco.com> Date: Thu, 07 Dec 2006 16:10:41 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Boschi, Elisa" Subject: Re: [IPFIX] An advanced for Reducing Redundancy References: <3167F18F59B81B4888A4D4C0A1717DD6670F99@mhdexc02.adhel.hitachi-eu.com> In-Reply-To: <3167F18F59B81B4888A4D4C0A1717DD6670F99@mhdexc02.adhel.hitachi-eu.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0762771073==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0762771073== Content-Type: multipart/alternative; boundary="------------000707030800090506020008" This is a multi-part message in MIME format. --------------000707030800090506020008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Elisa, Paul, > Paul, > >>>> >>>> >> One more that might be a bit obtuse. The technique for >>>> >> defining separate cpIds for source and destination Common >>>> >> Properties is mentioned in the draft. For common combinations >>>> >> a third category of cpId could be used which maps to two other >>>> >> cpIds. >>>> >> >>>> >> i.e.: >>>> >> cpID C -> cpID A + cpID B >>>> >> cpID A -> source address A, source port A >>>> >> cpID B -> destination address B, source port B >>>> > >>>> > >>>> > Which raises the question of what duplicate cpID means, eg: >>>> > >>>> > cpID D -> cpID C + cpID A >>>> > >>>> > >>>> > Also, we need to be careful to avoid circular definitions, eg: >>>> > >>>> > cpID E -> cpID F [ + cpID ... ] >>>> > cpID F -> cpID E [ + cpID ... ] >>>> > >>>> > >>>> > Probably an exporter SHOULD NOT send these, and a collector MUST >>>> > detect and discard them, and log. >>>> >>>> >>> Agree, but I propose a SHOULD instead of a MUST: >>>> >>>> >>> "An Exporter SHOULD NOT send Common Properties defined in >>> >>>> terms of other Common Properties (i.e. when one of the properties >>>> >>> is a CommonPropertiesID), and a Collector SHOULD detect and >>> >>>> discard them and log." >> >> >> > Awww man, nooooo! >> >> > I want to be able to build CP ID trees without having to create >> CommonCommonProperties or CommonCommonPropertiesProperties! >> > so to avoid that you propose to define CommonProperties in terms of > other Common Properties which in turn are defined in terms of > CommonProperties which... > Is it really better? > > If we allow trees, there are a few things more to worry about that > should be addressed in the draft. Hence the new section I proposed earlier: Section 8.5 "Cascaded Common Properties" Regards, Benoit. > > For example: > > duplication (as also written by Andrew) > > cpID A --> src addr A, src port A > cpID B --> src addr A, cpID A > > collision > > cpID A --> src addr A, src port A > cpID A --> src addr B, cpID A > > withdrawal > > what happens to a node in the tree if one of its children (or a node > in its subtree) is a cpID and is withdrawn? Does the collecting > process need to search for all the CP that are defined in terms of it > and invalidate them too? > > >>> >> I think you misunderstand Paul's position. I believe Paul thinks >>> that >>> >> the collector should catch circular definitions. The idea of >>> defining >>> >> common Properties in terms of other common properties seems >>> completely >>> >> valid to me. >> >> > Exactly. > ************************************************************************************************** > > 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 e-mail 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. > E-mail messages are not necessarily secure. Hitachi does not accept responsibility > for any changes made to this message after it was sent. > Please note that Hitachi checks outgoing e-mail messages for the presence of > computer viruses. > > ************************************************************************************************** > > > ------------------------------------------------------------------------ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix > --------------000707030800090506020008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Elisa, Paul,
Paul,


 >> One more that might be a bit obtuse.  The technique for
 >> defining separate cpIds for source and destination Common
 >> Properties is mentioned in the draft.  For common combinations
 >> a third category of cpId could be used which maps to two other
 >> cpIds.
 >>
 >> i.e.:
 >>  cpID C -> cpID A + cpID B
 >>  cpID A -> source address A, source port A
 >>  cpID B -> destination address B, source port B
 >
 >
 > Which raises the question of what duplicate cpID means, eg:
 >
 >   cpID D -> cpID C + cpID A
 >
 >
 > Also, we need to be careful to avoid circular definitions, eg:
 >
 >   cpID E -> cpID F [ + cpID ... ]
 >   cpID F -> cpID E [ + cpID ... ]
 >
 >
 > Probably an exporter SHOULD NOT send these, and a collector MUST
 > detect and discard them, and log.

>>> Agree, but I propose a SHOULD instead of a MUST:

>>> "An Exporter SHOULD NOT send Common Properties defined in >>> terms of other Common Properties (i.e. when one of the properties >>> is a CommonPropertiesID), and a Collector SHOULD detect and >>> discard them and log."


> Awww man, nooooo!

> I want to be able to build CP ID trees without having to create CommonCommonProperties or CommonCommonPropertiesProperties!

so to avoid that you propose to define CommonProperties in terms of other Common Properties which in turn are defined in terms of CommonProperties which...
Is it really better?

If we allow trees, there are a few things more to worry about that should be addressed in the draft.
Hence the new section I proposed earlier: Section 8.5 "Cascaded Common Properties"

Regards, Benoit.

For example:

duplication (as also written by Andrew)

cpID A --> src addr A, src port A
cpID B --> src addr A, cpID A

collision

cpID A --> src addr A, src port A
cpID A --> src addr B, cpID A

withdrawal

what happens to a node in the tree if one of its children (or a node in its subtree) is a cpID and is withdrawn? Does the collecting process need to search for all the CP that are defined in terms of it and invalidate them too?


>> I think you misunderstand Paul's position.  I believe Paul thinks that
>> the collector should catch circular definitions.  The idea of defining
>> common Properties in terms of other common properties seems completely
>> valid to me.

> Exactly. 
**************************************************************************************************
 
 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 e-mail 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. 
  E-mail messages are not necessarily secure.  Hitachi does not accept responsibility 
for any changes made to this message after it was sent. 
  Please note that Hitachi checks outgoing e-mail messages for the presence of 
computer viruses.

**************************************************************************************************

  

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.org/mailman/listinfo/ipfix

--------------000707030800090506020008-- --===============0762771073== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============0762771073==-- From ipfix-bounces@ietf.org Thu Dec 07 10:10:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKtb-0005nB-NW; Thu, 07 Dec 2006 10:10:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKta-0005mL-5R for ipfix@ietf.org; Thu, 07 Dec 2006 10:10:46 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsKtV-0003BQ-V7 for ipfix@ietf.org; Thu, 07 Dec 2006 10:10:46 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB7FAfT25772; Thu, 7 Dec 2006 16:10:41 +0100 (CET) Received: from [10.61.66.18] (ams3-vpn-dhcp530.cisco.com [10.61.66.18]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB7FAeW02016; Thu, 7 Dec 2006 16:10:40 +0100 (CET) Message-ID: <45782EF1.7090809@cisco.com> Date: Thu, 07 Dec 2006 16:10:41 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Boschi, Elisa" Subject: Re: [IPFIX] An advanced for Reducing Redundancy References: <3167F18F59B81B4888A4D4C0A1717DD6670F99@mhdexc02.adhel.hitachi-eu.com> In-Reply-To: <3167F18F59B81B4888A4D4C0A1717DD6670F99@mhdexc02.adhel.hitachi-eu.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0762771073==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0762771073== Content-Type: multipart/alternative; boundary="------------000707030800090506020008" This is a multi-part message in MIME format. --------------000707030800090506020008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Elisa, Paul, > Paul, > >>>> >>>> >> One more that might be a bit obtuse. The technique for >>>> >> defining separate cpIds for source and destination Common >>>> >> Properties is mentioned in the draft. For common combinations >>>> >> a third category of cpId could be used which maps to two other >>>> >> cpIds. >>>> >> >>>> >> i.e.: >>>> >> cpID C -> cpID A + cpID B >>>> >> cpID A -> source address A, source port A >>>> >> cpID B -> destination address B, source port B >>>> > >>>> > >>>> > Which raises the question of what duplicate cpID means, eg: >>>> > >>>> > cpID D -> cpID C + cpID A >>>> > >>>> > >>>> > Also, we need to be careful to avoid circular definitions, eg: >>>> > >>>> > cpID E -> cpID F [ + cpID ... ] >>>> > cpID F -> cpID E [ + cpID ... ] >>>> > >>>> > >>>> > Probably an exporter SHOULD NOT send these, and a collector MUST >>>> > detect and discard them, and log. >>>> >>>> >>> Agree, but I propose a SHOULD instead of a MUST: >>>> >>>> >>> "An Exporter SHOULD NOT send Common Properties defined in >>> >>>> terms of other Common Properties (i.e. when one of the properties >>>> >>> is a CommonPropertiesID), and a Collector SHOULD detect and >>> >>>> discard them and log." >> >> >> > Awww man, nooooo! >> >> > I want to be able to build CP ID trees without having to create >> CommonCommonProperties or CommonCommonPropertiesProperties! >> > so to avoid that you propose to define CommonProperties in terms of > other Common Properties which in turn are defined in terms of > CommonProperties which... > Is it really better? > > If we allow trees, there are a few things more to worry about that > should be addressed in the draft. Hence the new section I proposed earlier: Section 8.5 "Cascaded Common Properties" Regards, Benoit. > > For example: > > duplication (as also written by Andrew) > > cpID A --> src addr A, src port A > cpID B --> src addr A, cpID A > > collision > > cpID A --> src addr A, src port A > cpID A --> src addr B, cpID A > > withdrawal > > what happens to a node in the tree if one of its children (or a node > in its subtree) is a cpID and is withdrawn? Does the collecting > process need to search for all the CP that are defined in terms of it > and invalidate them too? > > >>> >> I think you misunderstand Paul's position. I believe Paul thinks >>> that >>> >> the collector should catch circular definitions. The idea of >>> defining >>> >> common Properties in terms of other common properties seems >>> completely >>> >> valid to me. >> >> > Exactly. > ************************************************************************************************** > > 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 e-mail 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. > E-mail messages are not necessarily secure. Hitachi does not accept responsibility > for any changes made to this message after it was sent. > Please note that Hitachi checks outgoing e-mail messages for the presence of > computer viruses. > > ************************************************************************************************** > > > ------------------------------------------------------------------------ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix > --------------000707030800090506020008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Elisa, Paul,
Paul,


 >> One more that might be a bit obtuse.  The technique for
 >> defining separate cpIds for source and destination Common
 >> Properties is mentioned in the draft.  For common combinations
 >> a third category of cpId could be used which maps to two other
 >> cpIds.
 >>
 >> i.e.:
 >>  cpID C -> cpID A + cpID B
 >>  cpID A -> source address A, source port A
 >>  cpID B -> destination address B, source port B
 >
 >
 > Which raises the question of what duplicate cpID means, eg:
 >
 >   cpID D -> cpID C + cpID A
 >
 >
 > Also, we need to be careful to avoid circular definitions, eg:
 >
 >   cpID E -> cpID F [ + cpID ... ]
 >   cpID F -> cpID E [ + cpID ... ]
 >
 >
 > Probably an exporter SHOULD NOT send these, and a collector MUST
 > detect and discard them, and log.

>>> Agree, but I propose a SHOULD instead of a MUST:

>>> "An Exporter SHOULD NOT send Common Properties defined in >>> terms of other Common Properties (i.e. when one of the properties >>> is a CommonPropertiesID), and a Collector SHOULD detect and >>> discard them and log."


> Awww man, nooooo!

> I want to be able to build CP ID trees without having to create CommonCommonProperties or CommonCommonPropertiesProperties!

so to avoid that you propose to define CommonProperties in terms of other Common Properties which in turn are defined in terms of CommonProperties which...
Is it really better?

If we allow trees, there are a few things more to worry about that should be addressed in the draft.
Hence the new section I proposed earlier: Section 8.5 "Cascaded Common Properties"

Regards, Benoit.

For example:

duplication (as also written by Andrew)

cpID A --> src addr A, src port A
cpID B --> src addr A, cpID A

collision

cpID A --> src addr A, src port A
cpID A --> src addr B, cpID A

withdrawal

what happens to a node in the tree if one of its children (or a node in its subtree) is a cpID and is withdrawn? Does the collecting process need to search for all the CP that are defined in terms of it and invalidate them too?


>> I think you misunderstand Paul's position.  I believe Paul thinks that
>> the collector should catch circular definitions.  The idea of defining
>> common Properties in terms of other common properties seems completely
>> valid to me.

> Exactly. 
**************************************************************************************************
 
 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 e-mail 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. 
  E-mail messages are not necessarily secure.  Hitachi does not accept responsibility 
for any changes made to this message after it was sent. 
  Please note that Hitachi checks outgoing e-mail messages for the presence of 
computer viruses.

**************************************************************************************************

  

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.org/mailman/listinfo/ipfix

--------------000707030800090506020008-- --===============0762771073== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============0762771073==-- From ipfix-bounces@ietf.org Thu Dec 07 10:19:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsL1P-0001C9-Cv; Thu, 07 Dec 2006 10:18:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsL1O-0001C1-CV for ipfix@ietf.org; Thu, 07 Dec 2006 10:18:50 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GsL14-0007Ur-Kp for ipfix@ietf.org; Thu, 07 Dec 2006 10:18:50 -0500 Received: from [10.147.65.153] (luz@kaitos [10.147.65.153]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id kB7FII424991; Thu, 7 Dec 2006 16:18:18 +0100 (MET) Message-ID: <457830BA.1030209@fokus.fraunhofer.de> Date: Thu, 07 Dec 2006 16:18:18 +0100 From: Lutz Mark User-Agent: Icedove 1.5.0.8 (X11/20061116) MIME-Version: 1.0 To: Benoit Claise , "Boschi, Elisa" , paitken@cisco.com Subject: Re: [IPFIX] An advanced for Reducing Redundancy References: <3167F18F59B81B4888A4D4C0A1717DD6670F99@mhdexc02.adhel.hitachi-eu.com> <45782EF1.7090809@cisco.com> In-Reply-To: <45782EF1.7090809@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Benoit, Elisa, Paul, >> If we allow trees, there are a few things more to worry about that >> should be addressed in the draft. > Hence the new section I proposed earlier: Section 8.5 "Cascaded Common > Properties" If we discuss and find a solution for the mentioned and probably some more special cases in the draft, I wonder if this will take more space than the description of the methods of redundancy reduction. Although I would prefer to allow the use of Common Property IDs within the Common Properties Records, I guess that dealing with all the special cases will blow up the implementation disproportionately. If we just say "the Exporter SHOULD NOT send trees of Common Properties" and "the Collector SHOULD discard them", then we can leave out the discussion from the draft and ease the implementation of the protocol. (However everybody may use CommonPropertiesIDs as Common Properties, if there are special demands.) Thoughts? Regards, Lutz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 10:19:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsL1P-0001C9-Cv; Thu, 07 Dec 2006 10:18:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsL1O-0001C1-CV for ipfix@ietf.org; Thu, 07 Dec 2006 10:18:50 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GsL14-0007Ur-Kp for ipfix@ietf.org; Thu, 07 Dec 2006 10:18:50 -0500 Received: from [10.147.65.153] (luz@kaitos [10.147.65.153]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id kB7FII424991; Thu, 7 Dec 2006 16:18:18 +0100 (MET) Message-ID: <457830BA.1030209@fokus.fraunhofer.de> Date: Thu, 07 Dec 2006 16:18:18 +0100 From: Lutz Mark User-Agent: Icedove 1.5.0.8 (X11/20061116) MIME-Version: 1.0 To: Benoit Claise , "Boschi, Elisa" , paitken@cisco.com Subject: Re: [IPFIX] An advanced for Reducing Redundancy References: <3167F18F59B81B4888A4D4C0A1717DD6670F99@mhdexc02.adhel.hitachi-eu.com> <45782EF1.7090809@cisco.com> In-Reply-To: <45782EF1.7090809@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Benoit, Elisa, Paul, >> If we allow trees, there are a few things more to worry about that >> should be addressed in the draft. > Hence the new section I proposed earlier: Section 8.5 "Cascaded Common > Properties" If we discuss and find a solution for the mentioned and probably some more special cases in the draft, I wonder if this will take more space than the description of the methods of redundancy reduction. Although I would prefer to allow the use of Common Property IDs within the Common Properties Records, I guess that dealing with all the special cases will blow up the implementation disproportionately. If we just say "the Exporter SHOULD NOT send trees of Common Properties" and "the Collector SHOULD discard them", then we can leave out the discussion from the draft and ease the implementation of the protocol. (However everybody may use CommonPropertiesIDs as Common Properties, if there are special demands.) Thoughts? Regards, Lutz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 10:50:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsLW6-0001x6-KT; Thu, 07 Dec 2006 10:50:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsLW6-0001wx-6N for ipfix@ietf.org; Thu, 07 Dec 2006 10:50:34 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsLVZ-00089H-2o for ipfix@ietf.org; Thu, 07 Dec 2006 10:50:34 -0500 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kB7Fnq2g009279 for ; Thu, 7 Dec 2006 10:49:52 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kB7Fmthr009123 for ; Thu, 7 Dec 2006 10:48:55 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kB7FmtdU009120; Thu, 07 Dec 2006 10:48:55 -0500 (EST) Received: from [131.106.59.192] (vpn-10-25-4-26.remote.cert.org [10.25.4.26]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.66) with ESMTP id kB7Fmto0026511; Thu, 7 Dec 2006 10:48:55 -0500 In-Reply-To: <45782EF1.7090809@cisco.com> References: <3167F18F59B81B4888A4D4C0A1717DD6670F99@mhdexc02.adhel.hitachi-eu.com> <45782EF1.7090809@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Brian Trammell Date: Thu, 7 Dec 2006 10:48:12 -0500 To: Benoit Claise , Elisa Boschi X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ipfix@ietf.org Subject: [IPFIX] Cascading Common Properties X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org All, Agreed that common properties cascades 1. should be allowed, and 2. addressed explicitly in the document. To keep the discussion going, I'd like to propose solutions (or at least choices of solutions) for the points Elisa raised: >> duplication (as also written by Andrew) >> >> cpID A --> src addr A, src port A >> cpID B --> src addr A, cpID A >> >> collision >> >> cpID A --> src addr A, src port A >> cpID A --> src addr B, cpID A I can think of two possible simple ways to address these concerns: 1. The principles in 3.1.2 Multiple Data Reduction could be readily extended to handle cascades: simply disallow any sort of collision, of which duplication is merely a subset. 2. Allow collision or duplication in the cascade, but ONLY to allow a common property "lower" in the hierarchy to override values of one "higher". This makes cascades potentially much more useful (giving us workable inheritance) at the expense of a fair amount of complexity. I don't personally have a strong opinion in either direction. >> withdrawal >> >> what happens to a node in the tree if one of its children (or a >> node in its subtree) is a cpID and is withdrawn? Does the >> collecting process need to search for all the CP that are defined >> in terms of it and invalidate them too? Yes... it seems to me the only real difficulty with cascading common properties (indeed, with cascading _anything_ really) is handling withdrawal. We could of course allow any of the various policies for cascading withdrawal and even provide a mechanism for setting the common properties withdrawal cascade policy via options (and even allow those options to be bound to common properties themselves, if we were feeling particularly uncharitable toward CP implementors :) ) but I don't think we want to do that for the sake of simplicity. So I think we want to pick a single withdrawal cascade policy. There is a question to answer explicitly before doing so: When a common property is withdrawn or invalid, is the record referencing it 1. invalid (as is implied by the document currently, and by most of the messages in these threads) or 2. valid but simply missing data (as has been proposed at least once, I forget by whom, but not particularly deeply discussed yet). Note that if inheritance and overrides are available in cascades as above, this second case is _not_ a valid choice. In the first case, I would propose that 1. an Exporting Process SHOULD withdraw all common properties "lower" in the cascade before withdrawing the common properties they reference; 2. a Collecting Process MUST invalidate all common properties defined in terms of a withdrawn common property; and 3. a Collecting Process MUST ignore common properties withdrawals sent by an Exporting Process that would withdraw common properties previously invalidated by a cascade withdrawal as in 2. This proposal is not particularly simple, but I think it is as simple as it can be while holding to the principle of being liberal in what you accept and conservative in what you send, and to the IPFIX design requirement to minimize complexity at the EP. In the second case, cascade withdrawal becomes simpler: simply ignore the cascade. The Exporting Process MUST explicitly withdraw any common property that is no longer valid, regardless of whether it's defined in terms of others. Partially withdrawn cascades would then merely be partially valid. (For what it's worth, I personally lean toward the first case here.) Thoughts? Regards, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 10:50:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsLW6-0001x6-KT; Thu, 07 Dec 2006 10:50:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsLW6-0001wx-6N for ipfix@ietf.org; Thu, 07 Dec 2006 10:50:34 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsLVZ-00089H-2o for ipfix@ietf.org; Thu, 07 Dec 2006 10:50:34 -0500 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kB7Fnq2g009279 for ; Thu, 7 Dec 2006 10:49:52 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kB7Fmthr009123 for ; Thu, 7 Dec 2006 10:48:55 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kB7FmtdU009120; Thu, 07 Dec 2006 10:48:55 -0500 (EST) Received: from [131.106.59.192] (vpn-10-25-4-26.remote.cert.org [10.25.4.26]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.66) with ESMTP id kB7Fmto0026511; Thu, 7 Dec 2006 10:48:55 -0500 In-Reply-To: <45782EF1.7090809@cisco.com> References: <3167F18F59B81B4888A4D4C0A1717DD6670F99@mhdexc02.adhel.hitachi-eu.com> <45782EF1.7090809@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Brian Trammell Date: Thu, 7 Dec 2006 10:48:12 -0500 To: Benoit Claise , Elisa Boschi X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ipfix@ietf.org Subject: [IPFIX] Cascading Common Properties X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org All, Agreed that common properties cascades 1. should be allowed, and 2. addressed explicitly in the document. To keep the discussion going, I'd like to propose solutions (or at least choices of solutions) for the points Elisa raised: >> duplication (as also written by Andrew) >> >> cpID A --> src addr A, src port A >> cpID B --> src addr A, cpID A >> >> collision >> >> cpID A --> src addr A, src port A >> cpID A --> src addr B, cpID A I can think of two possible simple ways to address these concerns: 1. The principles in 3.1.2 Multiple Data Reduction could be readily extended to handle cascades: simply disallow any sort of collision, of which duplication is merely a subset. 2. Allow collision or duplication in the cascade, but ONLY to allow a common property "lower" in the hierarchy to override values of one "higher". This makes cascades potentially much more useful (giving us workable inheritance) at the expense of a fair amount of complexity. I don't personally have a strong opinion in either direction. >> withdrawal >> >> what happens to a node in the tree if one of its children (or a >> node in its subtree) is a cpID and is withdrawn? Does the >> collecting process need to search for all the CP that are defined >> in terms of it and invalidate them too? Yes... it seems to me the only real difficulty with cascading common properties (indeed, with cascading _anything_ really) is handling withdrawal. We could of course allow any of the various policies for cascading withdrawal and even provide a mechanism for setting the common properties withdrawal cascade policy via options (and even allow those options to be bound to common properties themselves, if we were feeling particularly uncharitable toward CP implementors :) ) but I don't think we want to do that for the sake of simplicity. So I think we want to pick a single withdrawal cascade policy. There is a question to answer explicitly before doing so: When a common property is withdrawn or invalid, is the record referencing it 1. invalid (as is implied by the document currently, and by most of the messages in these threads) or 2. valid but simply missing data (as has been proposed at least once, I forget by whom, but not particularly deeply discussed yet). Note that if inheritance and overrides are available in cascades as above, this second case is _not_ a valid choice. In the first case, I would propose that 1. an Exporting Process SHOULD withdraw all common properties "lower" in the cascade before withdrawing the common properties they reference; 2. a Collecting Process MUST invalidate all common properties defined in terms of a withdrawn common property; and 3. a Collecting Process MUST ignore common properties withdrawals sent by an Exporting Process that would withdraw common properties previously invalidated by a cascade withdrawal as in 2. This proposal is not particularly simple, but I think it is as simple as it can be while holding to the principle of being liberal in what you accept and conservative in what you send, and to the IPFIX design requirement to minimize complexity at the EP. In the second case, cascade withdrawal becomes simpler: simply ignore the cascade. The Exporting Process MUST explicitly withdraw any common property that is no longer valid, regardless of whether it's defined in terms of others. Partially withdrawn cascades would then merely be partially valid. (For what it's worth, I personally lean toward the first case here.) Thoughts? Regards, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 11:07:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsLmK-0003YK-CO; Thu, 07 Dec 2006 11:07:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsLmJ-0003YF-9I for ipfix@ietf.org; Thu, 07 Dec 2006 11:07:19 -0500 Received: from smtp.ee.ethz.ch ([129.132.2.219]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GsLmA-0004ZH-Br for ipfix@ietf.org; Thu, 07 Dec 2006 11:07:19 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1A313D947F; Thu, 7 Dec 2006 17:07:04 +0100 (MET) Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (tardis [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09077-02-3; Thu, 7 Dec 2006 17:07:03 +0100 (MET) Received: from [192.168.0.2] (unknown [213.30.159.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5E27FD95FA; Thu, 7 Dec 2006 17:07:03 +0100 (MET) Message-ID: <45783C20.2060806@hitachi-eu.com> Date: Thu, 07 Dec 2006 17:06:56 +0100 From: Elisa Boschi User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] WG last call ondraft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com><4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com><45780A37.8010905@cisco.com> <45782D40.20002@cisco.com> In-Reply-To: <45782D40.20002@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org All, >> Description of commonPropertiesId: >> An identifier of a set of common properties between different >> Flows. >> The that is unique per Observation Domain. Typically, this >> Information Element is used >> to link to information reported in separate records. > > I suggested something quite similar to Elisa: > An identifier of a set of properties that is common across more > that one Flow. Typically, this Information Element is used to > link to information reported in separate records. The identifier > is unique per Transport Session and Observation Domain. > > Note: the uniqueness of the cpID needs redefined to include the > Transport Session. > it does. the current commonPropertiesID definition is: commonPropertiesID An identifier of a set of common properties that is locally unique per Observation Domain and Transport Session. This ID can be used to link to information reported in separate records. See [IPFIX-INFO] for the Information Element definition. This is also the definition that we agreed to have in IPFIX-INFO during last meeting (note that the definition had not been updated in the terminology section of -01, while it had in section 6 - now it's corrected) Can we actually modify IPFIX-INFO at this stage? Elisa > >>>>> Is there any need to define a new term for "Specific >>>>> Properties"? These are just part of a normal Data Record. >>>>> For example: >>>>> "... The rows are then referenced by the Specific Properties >>>>> by using the appropriate value for the Common Properties >>>>> identifier." >>>>> >>>>> could simply be: >>>>> "... The rows are then referenced by Data Records by >>>>> using the appropriate value for the Common Properties >>>>> identifier." >>>> >>>> In your example, the "Data Records" doesn't mean the full data >>>> records before applying the redundancy reduction mechanism but only >>>> a part of it. >>>> So it might be confusing... That's the trick we found. >>>> >>>> However, I could agree that the draft would work without a formal >>>> (upper case) definition.... So do you have the same idea for the >>>> Common Properties? >>> >>> Considering there is a commonPropertiesID, I am quite happy with you >>> referring to Common Properties. >> >> Ok. So let's see how the draft looks like if we remove the "Specific >> Properties" formal definition but if we keep the "Common Properties" >> one. > > Sounds good. > > >>> There seems to be a bit of a conceptual difference here though. You >>> seem to imagine that an Exporting Process has a set of IPFIX Data >>> Records which it then applies some processing to to get some new >>> special IPFIX Data Records and some Common Property options. The >>> original set of Data Records may never actually exist, depending on >>> how the scheme is implemented. >> >> Sure, this is an implementation detail, but conceptually, we want to >> reduce "something". How do you call this "something"? > > There are already several names for the something. Most common is Flows > or data. Sometimes even "Flow Record" but I think that term is too > easily confused with "Data Record". Data Record has a very specific > meaning and is not what is meant here. A Data Record is defined by > an IPFIX Template. The Flows that are sent from the Metering Process > to the Exporting Process have no set format. > > >> This document describes a bandwidth saving method for exporting >> flow or packet information using the IP Flow Information Export >> (IPFIX) protocol. >> >> Anyway, I think that we're diverging from your initial issue which >> was about "Specific >> Properties"... >> >> >>> For me, the only set of IPFIX Data >>> Records to consider are the ones which are actually sent. > [SNIP] >>>>> Are they meaningful in IPFIX? i.e. per the PROTO will an option >>>>> with scope but no data be deemed invalidated by the Collector. >>>>> Scope without data is the same as never having recieved the >>>>> mapping in the first place. I think that it would be up to the >>>>> implementation but it seems like a good idea so if we can't add >>>>> it to the PROTO can we put it in the implementation guidelines? >>>>> >>>>> How do you propose to withdraw common properties when they are >>>>> associated with a template rather than the Common Properties index? >>>> >>>> I don't ;) This is the reason why the use the Common Properties >>>> index is a cleaner design. >>> >>> I think withdrawal messages should work in general for options >>> data, so why not send an empty record with the template as scope? >> I guess that you wanted to say: >> I think withdrawal messages should work in general for options >> data, so why not send an empty record with the _common property_ >> as scope? >> Well, I prefer to have a clear design so that this draft is really >> independent, with its withdrawal mechanism. > > Then using the template ID to identify Common Properties can be > mentioned in passing, which I guess it is, in 8.3, however it is > also discussed in a little detail in section 4.1.1 (and figure 9), > and section 7. It seems that these details should be removed. > > >> Otherwise, you're telling in this I-RFC the standard track IPFIX >> protocol should consider an empty record as a withdrawal. This could >> be true a true assumption, but this is not clearly explained/specified! > > Not at all. Either withdrawing options in this way is valid in IPFIX, > in which case Reducing Redundancy can use it, or it a valid technique > for anybody. Now I'm not declaring that this is a technique for all > is within the scope of the draft. If red-red is going to use this > technique though we should decide in the WG that it is valid and say > so in the implementation guidelines or the "Managing Scope" draft. > > >>>>> 4. Specifications for bandwidth saving information export >>>>> >>>>> What is being specified here that isn't true for ALL options as >>>>> described in IPFIX-PROTO? >>>> >>>> What do you suggest? >>> >>> Well it seems that section three really explains almost the same >>> thing 3 times. The section 4 explains most of it again (with a >>> bit more info) another 3 times. >>> >>> I would prefer section 3 to simply explain the technique. Walk >>> through how the information from a Flow is split into two parts, >>> and then add the bit from section 4 how these two parts are >>> exported. >>> >>> Using more than one CPid in a record should be part of the >>> advanced techniques once the basics are made clear. Per packet >>> should just be a detailed example at the end. >>> >>>>> I think section 3 does a better job of explaining how all this >>>>> works. I'm really not sure what section 4 adds. >>>> >>>> The idea was to put the specs in section 4 while the section 3 was >>>> the high level solution. >>> >>> Rereading it, I see that now, but there seems to be a fair amount >>> of repetition. >> >> Let me ask the question differently. Do you see this repetition as >> problem? > > Yes. I think the draft would be cleared if how options work was left > to IPFIX-PROTO. red-red should reference that, then build describe > exactly how the basic Common Properties work for the simple case, from > concept to execution. > > The other variations on this can then build upon the proper foundation > of the simple case. This way the reader can understand how the system > works before you introduce the concept of including more than one > commonPropertiesId in a Template/Data Record. > > > [SNIP] >>>>> The text reads: >>>>> Common Properties IDs are unique per SCTP association and per >>>>> Observation Domain. If the Collecting Process receives a common >>>>> Properties ID which has already been received but which has not >>>>> previously been withdrawn (i.e. a commonPropertiesID from the same >>>>> Exporter Observation Domain with the same Template ID received on >>>>> the SCTP association), then the Collecting Process MUST shutdown >>>>> the association. >>>> This is similar to [IPFIX-PROTO] >>>> >>>> Template IDs are unique per SCTP association and per Observation >>>> Domain. If the Collecting Process receives a Template which has >>>> already been received but which has not previously been >>>> withdrawn (i.e. a Template Record from the same Exporter >>>> Observation Domain with the same Template ID received on the >>>> SCTP association), then the Collecting Process MUST shutdown the >>>> association. >>>> >>>>> >>>>> and: >>>>> If the Collecting Process receives a Common Properties Withdrawal >>>>> message for a Common Properties that it has not received before on >>>>> this SCTP assocation, it MUST reset the SCTP association, discard >>>>> the IPFIX Message, and SHOULD log the error as it does for >>>>> malformed IPFIX Messages. >>>>> I think this might go against IPFIX-PROTO. >>>> This is similar to [IPFIX-PROTO] >>> >>> These are similar to what IPFIX-PROTO says about templates, but that >>> doesn't mean the text can just be used to talk about Data Records sent >>> for Options Templates. >>> >>> Option data withdrawal messages are not mentioned in IPFIX-PROTO, >>> although I think they can work. However, in general options data with >>> the same scope as an earlier record will just overwrite the older >>> record. >> >> See my previous remark about an independent draft. > > What? > > AFAIK red-red is an information draft aimed at explaining how a technique > you can use with an IPFIX compliant Exporter/Collector. IPFIX-PROTO says > nothing about withdrawing options data and if this draft says: > If the Collecting Process receives a common Properties ID which has > already been received but which has not previously been withdrawn ... > then the Collecting Process MUST shutdown the association. > > Then it is expanding on what IPFIX-PROTO says and is no longer just a > way of using IPFIX but an extension to it. If we accept that withdrawing > options is part of IPFIX today then this is about the only extension > being asked for. > > I can see why you want it, but the problem you are trying to solve here > is the same for ALL options, not just Common Property definitions. > > > [SNIP] >> In this draft, we require a mechanism such as the following: >> "If the Common Properties are not refreshed before that lifetime >> has expired, the Collecting Process MUST discard the >> corresponding definition of the commonPropertiesID and any current >> and future associated Data Records. In which case, an alarm MUST be >> logged. " > > Why is it required for common properties and not other options? > Why is it ok to use a mechanism that is not part of the protocol? > >> Because there is no withdraw message with UDP: >> " If UDP is selected as the transport protocol, the commonPropertiesID >> Template Withdraw Messages MUST not be used, as this method is >> inefficient due to the unreliable nature of UDP." >> So I'm wondering why we are discussing this? > > Because you're trying to extend the protocol because you don't think > it's good enough. While I agree that the protocol could do a better > job of handling options, I think this extension is out of scope of > the draft. > > >> Let me come back to your questions: >> Q: What happened to storing it until the option turned up. >> A: >> >> If the Collecting Process has received the Specific Properties >> Data Record before the associated Common Properties Data Record, >> the Collecting Process MAY store the Specific Properties Data >> Record and await the retransmission or out-of-order arrival of the >> Common Properties Data Record. > > Fine. > > >> Q: Furthermore you shouldn't dictate the the record is discarded, >> just because you >> can't tell a piece of potentially trivial information about a flow >> doesn't mean it's meaningless. >> A: without the Common Properties, we can't decode the records. So we >> must discard them > > Surely that depends on what the Common Properties show. Perhaps the > particular properties that are common aren't important. Similarly, > if a normal full Data Record was received without something the > exporter thought was necessary, it could be discarded. > > >> Q: The Common Properties in question could be anything. >> A: I think we should limit this draft to Common Properties > > It wasn't a question and your answer makes no sense. I'm saying > that the properties defined by a particular cpID could be something > that is not important to the Collector. Perhaps it's the > classOfService field and the collector doesn't use it. > > > Andrew > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix > ************************************************************************************************** > > 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. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 11:07:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsLmK-0003YK-CO; Thu, 07 Dec 2006 11:07:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsLmJ-0003YF-9I for ipfix@ietf.org; Thu, 07 Dec 2006 11:07:19 -0500 Received: from smtp.ee.ethz.ch ([129.132.2.219]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GsLmA-0004ZH-Br for ipfix@ietf.org; Thu, 07 Dec 2006 11:07:19 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1A313D947F; Thu, 7 Dec 2006 17:07:04 +0100 (MET) Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (tardis [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09077-02-3; Thu, 7 Dec 2006 17:07:03 +0100 (MET) Received: from [192.168.0.2] (unknown [213.30.159.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5E27FD95FA; Thu, 7 Dec 2006 17:07:03 +0100 (MET) Message-ID: <45783C20.2060806@hitachi-eu.com> Date: Thu, 07 Dec 2006 17:06:56 +0100 From: Elisa Boschi User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] WG last call ondraft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com><4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com><45780A37.8010905@cisco.com> <45782D40.20002@cisco.com> In-Reply-To: <45782D40.20002@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org All, >> Description of commonPropertiesId: >> An identifier of a set of common properties between different >> Flows. >> The that is unique per Observation Domain. Typically, this >> Information Element is used >> to link to information reported in separate records. > > I suggested something quite similar to Elisa: > An identifier of a set of properties that is common across more > that one Flow. Typically, this Information Element is used to > link to information reported in separate records. The identifier > is unique per Transport Session and Observation Domain. > > Note: the uniqueness of the cpID needs redefined to include the > Transport Session. > it does. the current commonPropertiesID definition is: commonPropertiesID An identifier of a set of common properties that is locally unique per Observation Domain and Transport Session. This ID can be used to link to information reported in separate records. See [IPFIX-INFO] for the Information Element definition. This is also the definition that we agreed to have in IPFIX-INFO during last meeting (note that the definition had not been updated in the terminology section of -01, while it had in section 6 - now it's corrected) Can we actually modify IPFIX-INFO at this stage? Elisa > >>>>> Is there any need to define a new term for "Specific >>>>> Properties"? These are just part of a normal Data Record. >>>>> For example: >>>>> "... The rows are then referenced by the Specific Properties >>>>> by using the appropriate value for the Common Properties >>>>> identifier." >>>>> >>>>> could simply be: >>>>> "... The rows are then referenced by Data Records by >>>>> using the appropriate value for the Common Properties >>>>> identifier." >>>> >>>> In your example, the "Data Records" doesn't mean the full data >>>> records before applying the redundancy reduction mechanism but only >>>> a part of it. >>>> So it might be confusing... That's the trick we found. >>>> >>>> However, I could agree that the draft would work without a formal >>>> (upper case) definition.... So do you have the same idea for the >>>> Common Properties? >>> >>> Considering there is a commonPropertiesID, I am quite happy with you >>> referring to Common Properties. >> >> Ok. So let's see how the draft looks like if we remove the "Specific >> Properties" formal definition but if we keep the "Common Properties" >> one. > > Sounds good. > > >>> There seems to be a bit of a conceptual difference here though. You >>> seem to imagine that an Exporting Process has a set of IPFIX Data >>> Records which it then applies some processing to to get some new >>> special IPFIX Data Records and some Common Property options. The >>> original set of Data Records may never actually exist, depending on >>> how the scheme is implemented. >> >> Sure, this is an implementation detail, but conceptually, we want to >> reduce "something". How do you call this "something"? > > There are already several names for the something. Most common is Flows > or data. Sometimes even "Flow Record" but I think that term is too > easily confused with "Data Record". Data Record has a very specific > meaning and is not what is meant here. A Data Record is defined by > an IPFIX Template. The Flows that are sent from the Metering Process > to the Exporting Process have no set format. > > >> This document describes a bandwidth saving method for exporting >> flow or packet information using the IP Flow Information Export >> (IPFIX) protocol. >> >> Anyway, I think that we're diverging from your initial issue which >> was about "Specific >> Properties"... >> >> >>> For me, the only set of IPFIX Data >>> Records to consider are the ones which are actually sent. > [SNIP] >>>>> Are they meaningful in IPFIX? i.e. per the PROTO will an option >>>>> with scope but no data be deemed invalidated by the Collector. >>>>> Scope without data is the same as never having recieved the >>>>> mapping in the first place. I think that it would be up to the >>>>> implementation but it seems like a good idea so if we can't add >>>>> it to the PROTO can we put it in the implementation guidelines? >>>>> >>>>> How do you propose to withdraw common properties when they are >>>>> associated with a template rather than the Common Properties index? >>>> >>>> I don't ;) This is the reason why the use the Common Properties >>>> index is a cleaner design. >>> >>> I think withdrawal messages should work in general for options >>> data, so why not send an empty record with the template as scope? >> I guess that you wanted to say: >> I think withdrawal messages should work in general for options >> data, so why not send an empty record with the _common property_ >> as scope? >> Well, I prefer to have a clear design so that this draft is really >> independent, with its withdrawal mechanism. > > Then using the template ID to identify Common Properties can be > mentioned in passing, which I guess it is, in 8.3, however it is > also discussed in a little detail in section 4.1.1 (and figure 9), > and section 7. It seems that these details should be removed. > > >> Otherwise, you're telling in this I-RFC the standard track IPFIX >> protocol should consider an empty record as a withdrawal. This could >> be true a true assumption, but this is not clearly explained/specified! > > Not at all. Either withdrawing options in this way is valid in IPFIX, > in which case Reducing Redundancy can use it, or it a valid technique > for anybody. Now I'm not declaring that this is a technique for all > is within the scope of the draft. If red-red is going to use this > technique though we should decide in the WG that it is valid and say > so in the implementation guidelines or the "Managing Scope" draft. > > >>>>> 4. Specifications for bandwidth saving information export >>>>> >>>>> What is being specified here that isn't true for ALL options as >>>>> described in IPFIX-PROTO? >>>> >>>> What do you suggest? >>> >>> Well it seems that section three really explains almost the same >>> thing 3 times. The section 4 explains most of it again (with a >>> bit more info) another 3 times. >>> >>> I would prefer section 3 to simply explain the technique. Walk >>> through how the information from a Flow is split into two parts, >>> and then add the bit from section 4 how these two parts are >>> exported. >>> >>> Using more than one CPid in a record should be part of the >>> advanced techniques once the basics are made clear. Per packet >>> should just be a detailed example at the end. >>> >>>>> I think section 3 does a better job of explaining how all this >>>>> works. I'm really not sure what section 4 adds. >>>> >>>> The idea was to put the specs in section 4 while the section 3 was >>>> the high level solution. >>> >>> Rereading it, I see that now, but there seems to be a fair amount >>> of repetition. >> >> Let me ask the question differently. Do you see this repetition as >> problem? > > Yes. I think the draft would be cleared if how options work was left > to IPFIX-PROTO. red-red should reference that, then build describe > exactly how the basic Common Properties work for the simple case, from > concept to execution. > > The other variations on this can then build upon the proper foundation > of the simple case. This way the reader can understand how the system > works before you introduce the concept of including more than one > commonPropertiesId in a Template/Data Record. > > > [SNIP] >>>>> The text reads: >>>>> Common Properties IDs are unique per SCTP association and per >>>>> Observation Domain. If the Collecting Process receives a common >>>>> Properties ID which has already been received but which has not >>>>> previously been withdrawn (i.e. a commonPropertiesID from the same >>>>> Exporter Observation Domain with the same Template ID received on >>>>> the SCTP association), then the Collecting Process MUST shutdown >>>>> the association. >>>> This is similar to [IPFIX-PROTO] >>>> >>>> Template IDs are unique per SCTP association and per Observation >>>> Domain. If the Collecting Process receives a Template which has >>>> already been received but which has not previously been >>>> withdrawn (i.e. a Template Record from the same Exporter >>>> Observation Domain with the same Template ID received on the >>>> SCTP association), then the Collecting Process MUST shutdown the >>>> association. >>>> >>>>> >>>>> and: >>>>> If the Collecting Process receives a Common Properties Withdrawal >>>>> message for a Common Properties that it has not received before on >>>>> this SCTP assocation, it MUST reset the SCTP association, discard >>>>> the IPFIX Message, and SHOULD log the error as it does for >>>>> malformed IPFIX Messages. >>>>> I think this might go against IPFIX-PROTO. >>>> This is similar to [IPFIX-PROTO] >>> >>> These are similar to what IPFIX-PROTO says about templates, but that >>> doesn't mean the text can just be used to talk about Data Records sent >>> for Options Templates. >>> >>> Option data withdrawal messages are not mentioned in IPFIX-PROTO, >>> although I think they can work. However, in general options data with >>> the same scope as an earlier record will just overwrite the older >>> record. >> >> See my previous remark about an independent draft. > > What? > > AFAIK red-red is an information draft aimed at explaining how a technique > you can use with an IPFIX compliant Exporter/Collector. IPFIX-PROTO says > nothing about withdrawing options data and if this draft says: > If the Collecting Process receives a common Properties ID which has > already been received but which has not previously been withdrawn ... > then the Collecting Process MUST shutdown the association. > > Then it is expanding on what IPFIX-PROTO says and is no longer just a > way of using IPFIX but an extension to it. If we accept that withdrawing > options is part of IPFIX today then this is about the only extension > being asked for. > > I can see why you want it, but the problem you are trying to solve here > is the same for ALL options, not just Common Property definitions. > > > [SNIP] >> In this draft, we require a mechanism such as the following: >> "If the Common Properties are not refreshed before that lifetime >> has expired, the Collecting Process MUST discard the >> corresponding definition of the commonPropertiesID and any current >> and future associated Data Records. In which case, an alarm MUST be >> logged. " > > Why is it required for common properties and not other options? > Why is it ok to use a mechanism that is not part of the protocol? > >> Because there is no withdraw message with UDP: >> " If UDP is selected as the transport protocol, the commonPropertiesID >> Template Withdraw Messages MUST not be used, as this method is >> inefficient due to the unreliable nature of UDP." >> So I'm wondering why we are discussing this? > > Because you're trying to extend the protocol because you don't think > it's good enough. While I agree that the protocol could do a better > job of handling options, I think this extension is out of scope of > the draft. > > >> Let me come back to your questions: >> Q: What happened to storing it until the option turned up. >> A: >> >> If the Collecting Process has received the Specific Properties >> Data Record before the associated Common Properties Data Record, >> the Collecting Process MAY store the Specific Properties Data >> Record and await the retransmission or out-of-order arrival of the >> Common Properties Data Record. > > Fine. > > >> Q: Furthermore you shouldn't dictate the the record is discarded, >> just because you >> can't tell a piece of potentially trivial information about a flow >> doesn't mean it's meaningless. >> A: without the Common Properties, we can't decode the records. So we >> must discard them > > Surely that depends on what the Common Properties show. Perhaps the > particular properties that are common aren't important. Similarly, > if a normal full Data Record was received without something the > exporter thought was necessary, it could be discarded. > > >> Q: The Common Properties in question could be anything. >> A: I think we should limit this draft to Common Properties > > It wasn't a question and your answer makes no sense. I'm saying > that the properties defined by a particular cpID could be something > that is not important to the Collector. Perhaps it's the > classOfService field and the collector doesn't use it. > > > Andrew > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix > ************************************************************************************************** > > 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. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 11:51:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsMSP-00072m-8Q; Thu, 07 Dec 2006 11:50:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsMSO-00072h-OH for ipfix@ietf.org; Thu, 07 Dec 2006 11:50:48 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsMS0-0007u4-IT for ipfix@ietf.org; Thu, 07 Dec 2006 11:50:48 -0500 Received: from [10.147.65.153] (luz@kaitos [10.147.65.153]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id kB7GoA409086; Thu, 7 Dec 2006 17:50:10 +0100 (MET) Message-ID: <45784642.4060203@fokus.fraunhofer.de> Date: Thu, 07 Dec 2006 17:50:10 +0100 From: Lutz Mark User-Agent: Icedove 1.5.0.8 (X11/20061116) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] Cascading Common Properties References: <3167F18F59B81B4888A4D4C0A1717DD6670F99@mhdexc02.adhel.hitachi-eu.com> <45782EF1.7090809@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian, > To keep the discussion going, I'd like to propose solutions (or at least > choices of solutions) for the points Elisa raised: thanks for your assistance. >>> duplication (as also written by Andrew) >>> >>> cpID A --> src addr A, src port A >>> cpID B --> src addr A, cpID A >>> >>> collision >>> >>> cpID A --> src addr A, src port A >>> cpID A --> src addr B, cpID A > > I can think of two possible simple ways to address these concerns: > > 1. The principles in 3.1.2 Multiple Data Reduction could be readily > extended to handle cascades: simply disallow any sort of collision, of > which duplication is merely a subset. > > 2. Allow collision or duplication in the cascade, but ONLY to allow a > common property "lower" in the hierarchy to override values of one > "higher". This makes cascades potentially much more useful (giving us > workable inheritance) at the expense of a fair amount of complexity. I think it's not so easy since the protocol allows to have multiple IEs of the same type within a template. Regards, Lutz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 11:51:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsMSP-00072m-8Q; Thu, 07 Dec 2006 11:50:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsMSO-00072h-OH for ipfix@ietf.org; Thu, 07 Dec 2006 11:50:48 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsMS0-0007u4-IT for ipfix@ietf.org; Thu, 07 Dec 2006 11:50:48 -0500 Received: from [10.147.65.153] (luz@kaitos [10.147.65.153]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id kB7GoA409086; Thu, 7 Dec 2006 17:50:10 +0100 (MET) Message-ID: <45784642.4060203@fokus.fraunhofer.de> Date: Thu, 07 Dec 2006 17:50:10 +0100 From: Lutz Mark User-Agent: Icedove 1.5.0.8 (X11/20061116) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] Cascading Common Properties References: <3167F18F59B81B4888A4D4C0A1717DD6670F99@mhdexc02.adhel.hitachi-eu.com> <45782EF1.7090809@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian, > To keep the discussion going, I'd like to propose solutions (or at least > choices of solutions) for the points Elisa raised: thanks for your assistance. >>> duplication (as also written by Andrew) >>> >>> cpID A --> src addr A, src port A >>> cpID B --> src addr A, cpID A >>> >>> collision >>> >>> cpID A --> src addr A, src port A >>> cpID A --> src addr B, cpID A > > I can think of two possible simple ways to address these concerns: > > 1. The principles in 3.1.2 Multiple Data Reduction could be readily > extended to handle cascades: simply disallow any sort of collision, of > which duplication is merely a subset. > > 2. Allow collision or duplication in the cascade, but ONLY to allow a > common property "lower" in the hierarchy to override values of one > "higher". This makes cascades potentially much more useful (giving us > workable inheritance) at the expense of a fair amount of complexity. I think it's not so easy since the protocol allows to have multiple IEs of the same type within a template. Regards, Lutz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From West@artquadrum.ru Thu Dec 07 13:20:55 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsNrb-0002Js-EI for ipfix-archive@lists.ietf.org; Thu, 07 Dec 2006 13:20:55 -0500 Received: from bl7-109-116.dsl.telepac.pt ([85.240.109.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GsNrK-0008FT-E2 for ipfix-archive@lists.ietf.org; Thu, 07 Dec 2006 13:20:55 -0500 Received: from AYZ (unknown [163.136.196.104]) by telepac.pt with ESMTP id BD69524B986C for ; Thu, 7 Dec 2006 18:20:56 -0000 (GMT) Message-ID: <000c01c71a2c$5a623fe0$746df055@mariac> From: "Earth" To: ipfix-archive@lists.ietf.org Subject: Astronomy Computer Physics Date: Thu, 7 Dec 2006 18:20:20 -0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C71A2C.5A623FE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.6 (++++) X-Scan-Signature: f0ea5880a0890be2408609376fa519aa ------=_NextPart_000_0008_01C71A2C.5A623FE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01C71A2C.5A623FE0" ------=_NextPart_001_0009_01C71A2C.5A623FE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Search box, top right click. Studies food wine global issues history. Men womens geography german ancient western, jewish. Texts, writing law = english. Fiction letters literary twain electronic. Radio theatre = classics literature, language philosophy! East physical science united states landscape, criticism theory. Physics technology relations recreation, leisure gardening sports. Science united states landscape criticism theory asian china japan. = Science united states landscape, criticism theory asian china. Of = california press find books subjects art amp. Japan other south = southeast tibet guides cinema. Politics religions, cognitive economics = business. Geology wildlife ethnic chicano. Journals welcome to listings. Cinema = arts media dance television. Wine global issues history music natural = sciences. Of california press find books subjects art, amp the! Rim ethics social political thought, astronomy computer physics! Dance television radio theatre. Aging demography education psychology urban, society problems. Area if you, are looking for specific title or. Wine, global issues = history music? ------=_NextPart_001_0009_01C71A2C.5A623FE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Search box, top right = click.
Studies food wine global issues = history.
Men womens geography german ancient = western,=20 jewish. Texts, writing law english. Fiction letters literary twain = electronic.=20 Radio theatre classics literature, language philosophy!
East physical science united states = landscape,=20 criticism theory.
Physics technology relations = recreation, leisure=20 gardening sports.
Science united states landscape = criticism theory=20 asian china japan. Science united states landscape, criticism theory = asian=20 china. Of california press find books subjects art amp. Japan other = south=20 southeast tibet guides cinema. Politics religions, cognitive economics = business.
Geology wildlife ethnic chicano. = Journals welcome=20 to listings. Cinema arts media dance television. Wine global issues = history=20 music natural sciences.
Of california press find books subjects = art, amp the!
Rim ethics social political thought, = astronomy=20 computer physics!
Dance television radio = theatre.
Aging demography education psychology = urban,=20 society problems.
Area if you, are looking for specific = title or.=20 Wine, global issues history music?
------=_NextPart_001_0009_01C71A2C.5A623FE0-- ------=_NextPart_000_0008_01C71A2C.5A623FE0 Content-Type: image/gif; name="Issues.gif" Content-Transfer-Encoding: base64 Content-ID: <000701c71a2c$5a623fe0$746df055@mariac> R0lGODlhJAJoAofqAAAADYMGCAJ5BXp/AAgAfYYAdgKOdcbAyM7cvK68+UQqAFQaA3UhAZ4TALIT AdgoCAAxCC02AE5DAFlKAHgyAJI0DMdMAONGAwBTABliADVsAGRUAHpgDJVdBcZoC9lUBwaHACaL AEaLAWKOAICEC595AL+LB9GLBwCuACCRAEyVAGSYAHKkApuYBLmaAOieAADEACy8DTLCA2jJAIy7 AKyzALSxDOm0CwDVAynTAD3SCVTfAIjjAKnUCb7rAOLsAA4AQyAASEEANlgISHUFPKMAQM0KOO0B PgQWOiESQEkRRFoXPnIrSJ0nP8oXTtoSRgA6TSRKOzQ8RFZMO4lMO6MyTLhFStI4RgdfOiNbPTZj N2ZdS3hmAJ5sPrNsPd9uMQB2SBd7SE2GP1eNNnWNRa2BR7aISuB7OQapMiGTTj2qRGWpNnGsQKmn MciqQOydSQC0SivJRUW+S125NHy3PJO+SbTJNNG0OAfaORHnPD3iMVvpRozlQ5/hRMTXTOzkNAAH eCEAjj8AdmwAi34AiZMAhr0AhuENhQAVehIjjDQmjFwmjIsbjqYVisMWeusngQE5hSQ8hjE5gmtH f4Eyhq5MfMZEgNRBhwBdjBtZcj5ijmpjhYtXiZ9ijshsjtRfgA12fCB+iEN1gleLfYCOeJV8jsx2 iuKKeQCtgSGfjUGYgVGjgH6deqKhc8CTe+ehhACxdiDDjDjBhWDBdYW/dKC5irbIjOG3hgDTeCba f0rrdFTpcnflhZbVg8LTgODecQIAxCEOuUMAyGMIuHYAxa0Ls7QAvNEAyQAgyRwTzkory1cct4AW uq0YurYZzN0lvwBCshpBwDkzymdEyIRHyaJCwcU6sdtExgxTyRVkzUJcv1FjwYxZxp5WtMxiyOlo sQ59wSCJvEOAwFN8xYdztq6Awb52uO2HuACkxiiWszugvGSsw4ifxp6Yx82eye6asQC1tRq2w0zJ v2O/zYfAt6Wyyf7+85eUoYmHif8BDQ7/AP7zAAwO+vYA/wD6//Ly/yH5BADT6P8ALAAAAAAkAmgC Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePICnaG0mypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIPWDEm0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXTtRqNu3cOPKnUu3rt27ePPWZcu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnsxU r+XLmDNr3sy5s+fPoEOLHk26tOnTmimrXs26ddOZAmKbjC3AHu3btG3Lno27dsreuEn2bjmct2/h u0fmBp77JPPiyGs/P46yePPoym/rpp4denftJadv/6d+/Trq8+jT0zS/vX315Njdr2Tvnn743ezz w18O/6V5/dL1x1Jz/HFXHn4CHpgcgQr+Bp589qkn4YScSURbQRdeeJCGBHHIIUIf/vNhiAONKECH t2EYm0AaksiQiSeieKKLIK5Y4ow23hijiDaSGGKLOXqYo4pC7kija0heBVt/BTrIHYQCGnffk/ZF +J2BCPpmpUr/MSnbllM6KWV3ZI4ZZoNlOhcclE9S6OabeVk4JI847kikQUUuBCOec7LYJ4o83kmn n3Y6tKeMgzZE449B9tinjyvmSWiNOE5qaZKYrjVdncAliuillH4qKpGPRjqnozp2qhCMzNGpqqB8 Pv+nI6i0DgqkndPZaqqRf2bqK1RLYhlgm/LFB2ax9G25JpkAohlTl8IWO1+U0qKZbIJfeietscPG B+e34IYG4LZpRvfgtORhS6yZwBnnLEzQSnlsuWHWW5+6anY77ntaLjtvuAAHPFREjNYZKqyGDglp oQdLmuqoCeN66q4RHzyrpQvzibHCvRbZKMO/hvyaTONGeO26YtpLrm71vjueyv7t52W3Madb7YJZ 5jsmgzgTqyC1Agct9E1yFpphx6WCvGrStV4spIqkQqwox0ZTHHGMR1fNK9ZME7r1w54inGLTIpeN VLDyPjeedv96OyWY0O2LnLva6ux2e+Jxuea+wTH/t7bcL4sH7XFtD2344WYnrvjihx3u+OOQRy75 5JRXbvnlmGeu+eacd+7556CHLvropJdu+umop6766qy37vrrsMcu++y01y4X47jnrjtatvfu++9u 7S788MRjBfzxyCc/U/HMN+/889BHL71Xyldv/fUjTa/99twbhP334Pfe/fjkQx/++einr/767Atc /vvwxy///PTXb//9+J/d/v78Y57//wBUTP8GSEDIBfCACEygAhfIwAY68IEQjKAEKVPAClrwghjM oAY3yMEOevCDIAyhCEdIwhKa8IQoTKEKlzfBFrrwhTCMoVpmwo8a3sWGJsFh5WrID5fwECU/XKEQ /1USxJMU0R5HtIkOSbLEySWRiTh8IhKbGBQpDjF2EuEhQrQ4EC5apIYGAWNkvFgQLpKxi2Isyhll WL81CoSMboxIGtEomTiWcY5o5MdR7MhG+PHwj3r8ByAHScgzrhGPggykGcWoxUUqEoyOfCMiJflH ggySkpikJB4BqclKZtKLhOxkIMMYyjymsZR9nJ8nI5lHUyZylK+8IylbGctYsrKRjMwlLGm5yFYW EpOgzOUrH0nMT+qylm5c5TGDuctUMo+GOgziEYtITSrmsIfXLEkUtwnFkUgTm1P0JjeBaM1rYnOQ 4gTnD59YzXNus4ftnCI4iRhNG8ZTnlcUnxxPef9MWtbyn1ts5hwLycxfipKTB7mkJRXKUH7q8ZAO NeZDI6rQhFI0ogB15jNlcs9p1lOd5RSnEecpT3v+EYrrPGk6TWrFkn7TnTB9KTrZ+dF02rSj6Bwp SOFZSJvms3ZZxCgcMZpRWRrVlBMtaFIdCklPKqSSzHRlJu8oUKEuk6iatOgocdnMqWpUflEFaFiL utBZUnWpZx1mWp26EK7606nJRGRYIzlWfy50q03tKlm/ujto7tSngH2pNus5UnL+dbCHRaliEYtP fMoUpfOspk9ZuljBOjalMFUsTkEK2J/KLqh4Da0uCUpVOh71rnb9pyGxikyEDpOtcnXta6d6S6b/ OnKoSX2rbGXLVwfy8bSS7K1wy+ZXghr3uMhNrnKXy9zmOve50I2udFXq2dcx5bemLetwt+ur6npX hdwNr3jHS94Dfve86E2vevlX3va6973wNd9650vf+tr3vvjNL8Diy9/++ve/SdKvgAdM4AIb+MAI jgmAF8zgBjtYMAmOsIQnTOEKWxiED86whjfM4Q57+MMgDjFiLkxi1on4xChOsYq9V+IWu/jFMI6x jGdM4xrb+MbqWbGOd8zjHvv4x0AOsgQpFICRFNkkRzZyTZLcGSm4xckugfJPpGwXKuPEylHeCZZT suUTMvnLdzkyk5VsjyKPuSViRsmZYULlNsuk/8s0wTKcTQLlOcekzi+x851HsmU9o8TPdH4zl/98 EkAHxdCuAzNJ1gyXNCO5JIxWiaN54maSINoel16JnPPsEzxnWct8pvRMMj3oQps6L6RWXZLNvGgj B+DVan51mmFdZlnHmtZlJjOklbxqV+N60bI2M67F/OuWSNnJx+azFJb952UzG9PONnW0lf1sZ7t5 2tB+NqZDnW1Pb7vbhbZ2ti09bXGXxNzIrralu53uZLeb3NgONbbNzW5p1znZ9X43uNc973KPe9v9 Vne8qd3uTa/736PrtcJ3Lelat/rhKXH0mWdNZkUzfNi8hrix+c3xg3sc4Oems7tD/u1zj/zgeP++ dse5TXJtG9zO6V65p10u75OzXNkflzfJTY7zbyM75DQvOblzDnB327zoRPe20IX+85uHjuK5jrqu 1Sz1qkc66pN+OKt7rfGKX7zqewa5z3d+86Y7XeUoP7XO0y52bje90i0nu9tZYvax47vSdc97oJPO dLXfve94V/vS2054vcOd7WcHuuUmEoB/NF4gjX98sF9tkMk7niCTfzzmgw35zhdE8o7XfOg5/3nP e17ylIeIFP6xeoGsvvXWXnZBWu961hOE9rUfyOtvn3ve6571sc/964Nve9gT3/e4N76ze397a9v+ 98WHfvJrP/3p+174zrf+9WkP++dTH/kGsX7/8KvP+9jvHvrgRz/zld8YmrA642B/dKstTnWtT93r 74+//BU95qtLu+NzhnaJt3Jjt3drt3d1B4B0V3Z9N3gCaHeIB4EEaGUPqHcG+HcV6HSAp3gT6IBy V4ADGIKPw3iX13mgNxCiV4Khp4IsmIKal3oniHkmeHoyWHotOIM0aHopeH7R530+6H2yp33r54Pd N3vll348CITqh3vCd4SuV4Tbl4Tcl35NSH5PaIS/x308KHtYqIQ9CHxEyHxDqIVhaIXfp35NiIZk OIU/2BouuHmp93mUF3lyGIdwWIIxiII4iIeyhhB9qId8+IKAyIJimHzLF35B+IRceH3P53y6/2eI hwh8i1iEjrh+kTh7i9iIiXiFzbd72seEl9h94reJjxiJy8d+TOiFjaiIXwiEQoiKksiFx+eIQviI sXgQp8iKYihk5JOKF+GLTAGMFpGKwsiL4lWMFIGMSKGMEkGMxhhfzNgQldgU07gRzlg+OJaNBvSM 3BgY2viN65VqcKF0czFwKgFn4hhnhFZlQpGOK+RvluGOpQZo8shpIFiORLeOcSdoNdFnd1GPpZZf +KYXAImA9oiPgzeO/LiPYaeOgoeQQFGQJ3Rv2kZt8HZs8wZtPYdwF7lvZEeR4RZtAUeRcHd35jiQ M5d4I8lyJFlzIsdsPzeSFChuK/mSMNmSG/+YkR7JbzipcjIZkkoXk3KGbjUZcxs0EWy4fWWIfMZ3 hm0IhT9ohtc4ieG3i0kphV3IhpSIiVnohK04fAgxhVRZi5rYlWhYlmNYfloZhs23hGUoloy4lFno i2b4lWD4QA7pgR/ZgCiZkBFIgRw4jx9Ijjr3doMJcn+3dBkodg94gRvId4+pgUEZmIV3gIq5lxl4 eJFJeJhJmQmoQUh5lpKoiKdIfFepi1hYi6NIl0MYi1DZlednflXpidJXiGpJi5qYfQkBl2ZplWN4 fLXplnUpisDJlk5pl6rpla3IiFhZl3yVlLj4lNHZe6BYlcbZmmcJlVjZhtEXmwtBm2sZlcr/aZbX OJ3IGZer2JthiZ3nWZvF+IpyeZzVqZ5JyJzxuZwMlJcGV5mBx5Il93Jyh5H/eWoCqG76OJAJiaAp 2Zkep6B+OaAFCqAdaJAfZ3YwGXeaeXgWanhDx6Aa2WUCmpkGaEHNOImgaKIoeprYB4xBeImlmJth mYmwyIlKWYos6pbpiaPTCImvqZSryZ2hSJoxeqIoWnyVqHzlKaSsuJ25iIlFWp+dmJtaKItd2I1W eqVYmqVmAY5c6j5a+qVgGqbO06VkCi7a857DmBHR2BHIiKZVGpq5s6aLE2f0dpBDs6ABmZc3QZhP toAE+pAPypA2kY4SeWWD2o/6uDnN+Kas/9Gj6Kl6akqN36kQSQqp3BkRcmqdU5GpjyqN5qkao8Zl NYmYLlenBOd3KJeR1YaRAleR/jl3sceRNceqKQeYRYlwsepz5eZvvFqqvuqq4KZvBZirineSNPmr zUaSRklvRAmsr6qrwKpvy7qrN9mqtGqryLqTx+qsouOPE2qUlXmOjmmZ99ZzmxZ0Dcp25Xp2Rweu PCeZGkmulmlvPNmBGSpy6tqAQIegbteu47qum8mn6Sqv74p0DHiP4GqBHRqu3qqZpJOri8mh+ch3 MXmwfRloDluxiXmv9pqn5+qZ84qxILuYOdefCjuhgnqyeqmhfLmAFauvDMiyCBuwI2qBDf/7gduY prIpm+1pldXYnTmao1qpm9kJtGmYnHNJtJoqpc0JfsSotMg5fnE5n0d7nfJpndVXnKOZhqTZorhJ qUbLs8LZiYeIpKRol/YpftNJlmUDpaw5nFXqjLTJlqcJt0Y4t+mJtMe5i2lJn3Qrnn7rnFZLtXlr tWhLhfi5nkFbqXx7hN65m8rJmtLpt2mLuMHZuCO2kPIaeBF6gd46oIhncxeajw46sx7KmRX6nxIb rwkYoiMbmK4KmPkqoCILmST7qpP5rRN7sSJ4snjKnwsbs4L6l4tXoqZ4vGPJlG57tujHo80rfYnI ttA5pVOrvI5Kt9GrvHlbttFLi0eKvE//2aRVO5py+6hBeouICIlOOqWGeKnT66KuWYihOHxUCr31 uZrty5U/Kz+cOj6Myzj9q7g/FsDc87+KQ8Cf6kKaYaoDtJ/tU6jpI6YSPMEUXMEWDEGjAcFsxhl9 xq2AqhPmOLEEOcIQeagNuUH8ao8aLJiBaqihOqKfVpB6tsJ7+o8aqLkbJ645vMHt+DvuKLB92sLs CMM7LGp+uhk0rGk3fMJF/MFOrMOH5j+YurXoS7Tem4ldS8VHepdYrIrEWZp0Cb9GSqNbqKTxS7bo m8aiqMU/e8VESn0pOpdkLMa4ibxdXLbu2ZRGyr5ZjMeY65T0a6PCmH3wG8hmnLQ2Csd8/6yL+5sk yXu594ueeoy2sviaKkqJ0Lm0nFi/a3yfUxm5Vcibtnm5z0uVqanH27mejzzKX4jKxFm0aNnKk0qG Vwu5gyvKUYnLYHm14dm2oKyEhPvJlKuijuuF2gm2WRmcj1vLiMukvFy9pMzKk1u3nfrMajibz8vM yuy0k8q1h7u20KzNnjzOBixAmmuzBMhuEjqr8Ai6xQq6uWtyJzmwKBmrGUtw1QqPq3uZEQhvFotu 6Wp+QLnPQym6Ad1yAN2yMEe8DpuyNavOD52ZEIuulbOow6yel0rKUOrF2FzGixu3mhqey4yjlguk 1izN13vSQovRIG234EzMTbvN7vmdX/8rzqkZzok7toGLzAjsGHaLy4Z7zGpLneY51Hp7x9ncyVIp zLXcyYAczL550vULzOF8tltItdNbyl7JyTUa1Tu9yeB8zZSr0yrt0ZmcGC/crxU5us0Komt9qs/6 uSX51i+pl/AMzwFn18yqkzY7uvKcwv+Gd2xNzyEsknzp1/6cuv5JrIZtkQMLryA7bgKbzwPdkQ+9 b4LtqzyXxGWaE5ydwXZawz0MLp/d2SY8OYZWj0lc2nXB2p/RX42MGGva03/cX6Z92zl2wbq927xt zunhZ+gIwq3twbiNPGjBjEzdzTetyRbN3LasEbRd2709FRIC3H/6aRQqF6ntGa5d3EL/0dxD28VV zMV0/LXf66LjF8dpHL+miJpqScaMDMavDJyeqN6nLLfqXY013Z3sN90dkdb+Kq4ULbtzV7uQTdEF joAYmHTrmnL5Wq8MHeCwi68E68CGx7vefTuLOrdsO9aA6802fczLPeKr6KbGPM3jKdS/PJ6VG83k XM3+fRHq+LICbZN5R6wWi88wm+DQaqDZPazOerEgyeOtK7w8ycBDfrqEKaLynOGgTeNKjLKJ6uBS TuQte908rtf9/LtFTrMLHaCRbeGbibNOHhTJmM2sbNVV7dSkiNTxOdXNDMghPdPju7dQqOZk6dFk HbR9C4afKN0xDhLvK965SKRh/LhN/yq+UWq/rpi+SEjoSY2ai/y05Iu9kE7FOjq/6/ui92vKgZ4Y 0f3p8YUe3V3mpq5pIXzqNSbqrL4Rqv7qmNHqsi7jsF7rtn7ruJ7rur7rBTTrvt4WvB7sPfHrxF7s xq4Rwp7sOnHszN7szv7s0B7t0j7t1F7t1n7t2J7t2r7t3N7t3v7t9aPs4j7u5K7h4H7u6J7u6r7u 7B495f7uLtHu8j7v/gXv9q4S9J7v+i5iKUgR/V6DAG8U/14RA68UBc8QACARCc8UANDwC7HwEwHx jyHxS0HxDWHxZzETmZd/MRFs9+d18vcTHg/y9ecS/Rfy7vfxDEcSANASLW8PLx8TMf8PFDPP8i9R 8zJ/EjivEjH/8jtv8yPx83GB8z5vF0V/85dDfy8BZlc3cUDBfz1x8it/E00/E0ef80Kx80JvElvP El3v9Tq/El+PF2MfFGVfEmcvMEw/bLaG8vOHcVjn8cLma7PG9k5ff1sH9yM/8mAn9Xzf9sKmcLb2 91wf9A2v8w1/+InP8osf9jDf+C1/+I8P+Y0/+YYv+Zcf+ZWf+JLP+UH/+JkP9GgP85Z/+aGv+ZVP +p7v85Bf+qPf+p3f+p9P+pPf+aqP+ZxP9KC/+7XP+LLv+b0/+5XzZQvXdWum9/DHa1yn/PNn/BHH /Pi3ElnX91YndXMP8sd/f5Ev+kD/j/u0L/zc//neb/Mzv/2zr/Xgb/7i//o/f/Xk3/Pff/VHX/7C r/63H/7eP/7rf/7fT/uaDxD2BAKwR1BgwYMHARhcOBChwocOERpMmJBhRYwZNW7k2NFjxn8hRY4k WTLAyJMiT6YMybJlyX8uU86MibKmSpsyb8J0abOmzp8wce5sGcDoUaIrSQKlafLlSAD/ogqVGnKq 1aoir2otGXXr16xYt2LtSlYs1LBVx6JNe5br2qtT5bKNm9YrW65v8Wa965ZsX79tw9YFC1YtVb6I FS9m3NjxR40BEko+KPno0YqUM08WSNkyZ832LhsVzVk06c0ZPZeu3Jn15MuuTbcO/+0ZdW3ZmkfL hliwIcaLEBcOp9ibOMHiyX0TH/g7osXmzJUfR17xuEToypf3fhhcIsXqwqGPd6j9e8Tw56eT5w5+ +fDnF4tH/z0f8n38+TU6djr0Zc+lePKJJp2A8ukp/xAMMKihlDrwpp4iTCpApp6qcC/B5tILMcAO yyuwsgRLjKTCQjRrRLQMy6suFFHs8EUSU9xrLsLosuvGGM3q8EQac/yLPyCDFJIk/Voz0jXcUkPS tNV0++zI0nDTDaMkm2TyNd5uU3JJ2ro0crXXtMyOO+PGJLM8hdJDT830vBtvvebikzPO59AU7zw8 wfOOzTnJ5LM9M32zc1DnAB10ov80D10TuyIbdfTRjpLMDTPVKK1y0s9CO01MTCOjlLUnc+vMUtLA hBLUT0lNtTLLSuXtu0ItKpQh+ICLDlFZw2Pu1kTJ23U7WuuzriE3Dw1W1kXh07O7Ws2jr9hf51TW 2Fvtcw9W56Zltj5iGYX022+HFHdccss199wF0VW33LXWdffddduFl8N567X3Xnzz1RdfAPe1V15/ A64X4H0JFvjgc8FVeGGGG3YYy4cj5ihaiSu2uFH7Lk4zVo079vhjkEMWeWSSSzb5ZJRTVhkkhFt2 +WWYY5Z5ZpprtvlmnHPWeWeee/b553wNBlLDD8cV+l2DCYYLaKbNVdrEgI+WaqH/pqsWSWFrbcXY 24z1K9birs/Ek71vnQ2b7I/O1lhtcDP+Ouu101557ovnXXpIok8UV+p4FXvaR6dnZIzvogUmHG96 Aff36MOtdhyq4VYkjsTIJ+8q8h9TpNoqzL3afOrOOd/ccs9p/Nxy0D/XqnLQVxSdas9fF0t1EwGT C3PIK7edcthxzz2uzoMfvfXUeTedaLhYx13D48oq3fnTl5fed9mL/51HtRp/XOYeC2/x77yn9j72 wLoXivzsNyxf8dN/LIzF2b3/cHcVJZ8/xPqdZ19z1+ltH369tS8x+UtfAGukPg8F0EaAgxHttgc0 82UIe1RhHgP1h8AIXnB9JSrc/1gME0EYYTBxfcnb3TwoohL6b38iFJGMXHe3olWQgCGM4Y04qMD+ Ce6GDzxYka6DK291B20/hNabpBMoIVrriHcqz3WcVSftyAeJ1OlTRtq0rVq9yTp1GhsXnbjFXGmr ixvrVpng5if1DLGKcqJiG8kWRa1Ri210o1uQPoijBeIwcycU4Q4z6EcbQo2PNRygC/WGR5jQ75A5 OmG7UqjDFQpOgizcUVvumEAJ5m+Hh9RkHmu4SR7qDHh+ceAj51dBSHIukKrE5GAaaMgE0m6QI7Id DTEZPlJ+D39Q8+QgYRfJW3JydXh0pAULyUpYzvKV6pOlJ7E3Su2FMmFeK+Ox3P+GnCzmSohQNGJ1 olhN+lTrPcHKVhbFSEZpYQuI4UynFcHITuBwLGzEyubGsMjOXf2QTvb8ExfDCcdteXGN3yxnQb1o Tiuas1tzpOPKpKkvGD4UaS+LZuIkelGMZlRdEdUou2BW0fN1VKQjJanfeFlSO360byhlaUtd+lKY xlSmM6VpTW16U5zmVKc75WlPfVpS6onyp0Ml6kQTOTCEAdBoR21h0Ch40qJGVaopvShIQ/rUpGJ1 qltlqQ8VqqdrNUtZzdoOPuuJpoWS054TKShYsblQ45z1PfBsIj2z9lX5qJWtakXoFt+Kzrk2cZ8U a2hhDXtYxAbqikD8GluZyKj/uy4LsugRlBzjeMUnAhSMexqW2LCJxmyNbZ6VXae0aEWtxKZWtasN 11JnCSIUrpKQyUzlJ2GpI7d0MocLBNgMERlCXB51k5ccDCK5elycNY94y70d/Jo3XOXSdnWkG95b nlu73EZ3gsV0ZUSb+8vpsi6HQaWtMnE7O9QhV7328tobN/teNiLRn1NEG33PaChdTUyLWrtvfB97 37dthE/z0ax7GMpaBCdYwe2Nk4HNWKZkyfeJ6zQbZeGkKMpiJ7P7he+1QJuoCgPUw7a68GQzTOEg LljFK26okMQ7Pcl95XnAFV4xNQnj1AEvetErbngTuTymii+o0VWe8SYoZAdK/5e6Auwx6qy6Xihv 9cnci3KV1ctisGE5xVrmcpe9TEefTjlmYrZymbv6ZTSnWc1rZvNqzfxmOMdZznOmc53tfGc851nP e+Zzn/38Z0AHWtCDJnShDX1oRCda0YtmNGPa/GhIR1rSk25Yoy19aUxnWtN7pnSnPf1pUEt606Mm dalNfWpUp1rVq2Z1q1MdaljHWtazpnWtbX1rXNfa1bvmda99/et35VrYwyZ2sT8CbGQnOyTGZnaz nW1rZUdb2tOmdrWtfW1sZ1vbUn12t739bXCHW9zjJne5zX1udLd52+tudLrd/W54V4zd8050vO19 b3zrB11JXhyZBcYPfugL4P8kGXhGCy6Ug48k4fQWJZH9jbeH+2vh81r4xB9q8YFjPOAM5xmPxecy fu/N3yG3+D8SXvLGVHzjBl85TDReL5TTm5rI4ljIav6om2MsbADXCM8P4vNGAV0gQkcz0StidHsg fWFKzzebZ/VZuo6TjMmRaxjbOvWnizWfVZ/6s+wDcLD7POxjJzvYj86Ps6c96Whf+9DRLna28xzu bu952BMydrr/nO1rJ7rd+e53ue+d7G43e0bKfvfC/53pTf/y0yvLrV4Jqpx0yvnkH38sykvW8aSN Z69ynvi5613vcd972xGv9tAHPu+qNz3SgR76tgs99YInPd9Fz/rXv532hs///ep3z3gV23GUSIbc jz9e/GFerviq6x3yKYdM5jPudlQ5+carL5LrU7/lJrd+wMPOffB/P+PeBzv4SxLzkBRc/d1XOPnP 3/Lxhx/+7lfM9bOPfo43hjrDpM6Ohfe79Eo+VYq+4zu+/TPA/qMg5SK5+Uu/BnTA9tM+gps/ssO+ srPACkS4icvA9XPACtzABoy/+4s5+7tA88u/kZi5zrs5y+OVnEMWEKM6zoO8zIu8jrC8zys92DM9 HuxBtRO90cM7whNCxUu8uvs9HvQ7H8y707s93etB2VO6KFxCJgS+R6s5ekooGKS5OXI8L5TBzWvB iZFBzvvB1tNBJKTCKoRC/7ijPdJzQ8L7CNZjQiV0vdKrQtWbwyW0w9OTwju0QjcbGkeavgHUMQSE PnkZHUVkJQLcMWQ6ROUTnUecwAg8wRM8uOyzRE00P5WDwErsxEukP+57QAssRU4URfk7RQ8MRVMc wVbcPhQUPuN7HR1bsugjr/DyPwH8uASsHu0ynulZi0z8vlE0QVPURBD0xFekRGRcubHDQGJURmik QPYrxfjzwPIrxgccxmgsxlhUNfyTxk38RnLsqXAExXIMNEB0mMVbR3d8R3iMR3mcR3qsR3tkmXTM xzh7FEl5GE2pmE+ZjUb5R39EDfwgyIC8R4W0GHFpin5Bl4dckIhcjH5piv+GFBKLRIyJVAwA2Uh9 tLKB/BKAPEhHQchXKRKCvI+U3JL8+MeVXEiYRBnbwIxUScgw+RJL2RRWmZLYiA0qUZXa6EmD9MnM oEmdHBUtSUqi1JTd6JKaTEihVMqYnMqPqRKeFMib5BIkuUpRARWsvBQqGRUvOUmmnJLNMEivzMor oQ2uPMm03EqqjMuOAUuthJgouUssCRW8XMt+zEu3fMu9hBimxMrAfEu9FMmxDEyXfJXDlEvH7AiM HJCcGA2nUIqZoEymMIoGKYrLSBcIEZAJGQ0JeZDLRIrRZAkHkcicWM0EsRDW/MgoQ8m1rEvVuEtT gZLBTMuXpMvZLEyWlBL/0EiNtuxNvSzOsPTLl3xM5SxJ4vTL41RLxcxKMOlL3kTMusxN3AyTw7zN lDQVVxlLtOxK2lxO8oSUoLTK8DyS85zJoRxKVtkUhFyVSkHP+PzOTtnO97TLLHEV9LRLJ+GU8gxQ 5nTH5BRQA9WYi+Qzj4RNTONHQCzQA41QiWFQCoUyCb1QDI2YCt3QO1tQihQYD9VIe8lIxvBQEl2X jZzIjhySEOVQf9EPCPWI27yYGOWIGrXRjZhRGYUMHWWY5DRJ/xzQDH22G81RkSnS2hxJ/cTRj+jR hflRJiVMkhzSUAuSldBMziQQLI2JzoQQpOBSLL1SLUXNLwXTLVWJLxVT/zQt0zVdUzIN0yzdTNQ0 CdMEUzfdTDP9jy2lzDzN0o6s0zJ1yM680jj9iTNtURe1mT2tzDmtEBXlUpxY1AJ5EEaNVEpt1Nds zc9kEKLo1EVVTU41VEsd1f+41KWY088sEFTV0wRB1ESdGQMh1VAlEBGdVFlNzU6lkEwdzVbN1RXd VFxVkAkBVVwt1tDcVc8cVlq9VWTV1FftmcysU2YNVT891kjFTEo1U2ONVc5UkGD10jR1zV/tVW0V V2xlVtEc1ta8kG1FiXP11mdtGlst1WkN1nmdVV81VXTN1n3VVTxdVn2lV9ekVmsVWHJdV8nEV25V 11yN152ZV82EWIBFkP+IRVaJTZeKJdUz3Yl29VdI3dSG5VVOhVOFfc2MFdiNFVmH5FhjndaBddiA gVEm4c+ZfRL2RMoo8cmmhM+d9E+axcnGfMr/nM7v9E5PsU9UsVlM4U6cvdmm/Umknc6nLUsANcsl pVI2g9b+EClXrZeudZmvhVl0Sa3FbDMktZizLZm0xVou09pkxaiwVZcu9Zm4FVu7vVsLZVu93Vu+ 7Vu//VvADdyKwFvCLVzD7TXBTVzFXVzGbVzHfVzIjVzJnVzKrdyHOVzM7SjL3dx4zFzP/VzQVTTO Hd11DF3TfRzSTV3VXV3WbV3XTdzTjd2meV3aLTfZvV3czd3YrF3e7V3/3/3d+9Bd4bUZ4C1e4z1e 5E1e5aW04W1e533emlpe6a1S6K3emJ1e7GXeosoHgckH74UJ7kUY7w3fgCFfxTBfq4m4U9OPfEiI 9j2I9zWZ+HWY+V2Y+q2I+3VfjMjfh+Ffj/Ff/L0PsjqZxnInLHMbWgsS811gmEFfdXFgc4FgkZDg kHBgCl6XC8aXDJ5g/lCqgwmuIHsc7ore/Ijf9jVhgRjf/FXhFLYH703h8c0IFnZh+HVhFn5hG8Zh GsZhHZ7hHa5h/L1hG4ZhHo7hGVbh+X3f+r3hGA7gFs5hJdZf9zXiJj7hJQbiI9ZfKw7gJobiGrZi ANYr4TgteMqnsjrj/67DK7oKqwEOIjPmFnk6YzOuK6qzKwDjFS1TYA4mX+5lYKroYz4eCfT14z7m 4H/43goW5AoOX0QuZEN25EMmCQZG5JJg5ER+5Eu+ZAvO5EhW5ESeZE/25EmG4EAG5T0m5VIW5UMO 5KtCIUK0pfjJJUbyYFw6oPV5KiazJFs+ptgyrhtS3x5i3xaOYhoGYo04YSl+YmMuZmR+4iSWYhQe ZmiWZiemZhl25mkuZmx24mfmYmX+4WXeZmveX2bWYnO+5i+e5m42YH/ysH76r/nqIrhBYDd5ZxJj DwKjL8Yy4A17rLbV41ReZRWu5IFeYCSW5IPmZEue4IRm5UhG4oWGZP9D/mSEHl9NbmiF5mRNDuU9 zmg/VuWOFgpHNmWKBl9FhuiS1mi8GGHCWMDJ+aAke6QFFK5nwpAcs4tffB8ns2ldkiRcLClIHmnE IOlOFmmTZuWPDuWAluSUnuiH5uiINumi7uRNnupNXuimrmqiZmqsfuqQruSTPmqO9hGWRqCa7qBd oiSali1Lkq5WbiVZZiQM0a0HKpJmBud1VuYXzusrxmJtJuZvBmwU7uZorua9TmYeDmxxTmxuTmbE Puchbux03ojCBuch5t9nJmxtLud3QmAN8y/JUyz+UqwCHrE2yecGw+d3QrF9Hu0zWZYR67S+JuIV Puwl7uIpZuy/1mH/2jbmaPbhys5tyybi3fZivT7szYZfMMbs3DZh5EbsKuaIJO5iI07uZVZi6obi 4Faozo4rg/qTqssma7JByPqqg/KmYYlj7+asfYpBLKymF+xbAP5mOprviLHv/g21A8vekcFv/CaZ /26YABdwUNtvudwqCh7onNngd2HwBo8pYLZeCZ9wCudQ/r5wcjPwrXFMDd+yheG6b+vwOLI3ER9x +RIwyChxW+u/eL7BilHxj+kaGH/xtjHxcptxD2/x+mLnG99xj8BxFFcxIH8YHO8vSHOx0AnG5FHE 4akx8rmL0LGu3ikl3YnpKD8LKmfyloY+XqxF9PoxLZ8uH1sMnR7z/+fpsfuxnhubctMha1+0aSdz xL8Ic9JhrhqDnjdX8jz/rlw0sgB8c70IOR5CH1g2LwEixFgOpp7uJQt6nxDGkUXki1e2IaV6ml0W GhkbHwNsEdwCJLm2riBbpkVipiYrdTwHkRv7pEundNvSdF8urwhfF0gZMPdSbRHzK32uZ9fmGvvS CNQWLQizMH0WGwnzcTTyrPiS8W1CLQ4rLTMpsbNRE4EychT7dW76MHiG9mEP9mu3LDX7IniuddQq Im3HIvXuZ2838QILdgcLd8/aOnKK7yqKdzYaLV2fsHtH8Xx/d61bq4DSsCVSFCrCZ3CXo4IfJ3te 9m6v9m/v9ddebf/w5vVyL2But3Za5/F2yjB3Bu2FHygdH3FtXw9l33c3nix7N3lx7/giUviLJ/Zj t/UTx3c18vhsVy2qEjJDaqbaoqUY+WVUEqZXZ6ZK0iMXGa8+mmuyVqTdMiZSWqZEbPUCzBzYWumc 9yWl5+WfBy9UR3qojyVRl61SOrKzxvmMKrIYy5A7J6Zmcrhash7l+3O3N3sw5/PzKvo5ry5O+r/m GvOmqp+9F/URjnutPyW8D+E4r6QXk3NJz3S5X3y6n+srX3zHNyBHHES3vx5JHPoKr5pY16rNP93O f+vCxfCLGXL8MH3ST33VX33WJ7fPf/2xRSzUp3Halxsbv325lKv/DgdxY3cU3tfeDlacoRl14te/ RcJ0x0D+vUn+R2/+rOrl7SEz7mqcwwFhF9spBnP5/Ih2rNlw25eYA/Ns/Zqb2U8zz9ZwA5/98sey m797Q8yelmbz8cGxnqeevQdGsncfTT9zFtlpmAYIAAD+/RsocCBBhAcREkxYUGDDhREPJqRYsOHF hwwlYnTIMWJFhhg5GoTYUaNCkCVTmvxoUSNIlB5NdiT5EuXKiTR1rtz4kiXMkDuFEj1p9CjSpEqX Mm2q1B7UqFKnRgUw1arVqvaybt3KNStYql3Hiu36lWpYtGS5avXaFmrYs1fdwl2r1qxUtnUFtsWa 9+pZtn7L4tUa//jvXLJ/5ZbFyrhu37F89z4eXFiyYsdvIUPW2/nw5s6LEccFzfl0WsKqV7Nu7fo1 bKhOeVIUabDmSIcZce82ehtpypO/jwbXrRuo8N7IeQ/v7TH3Rdu8n6tM2ry58uTOqS+9Pj3jb+nS q0PPLb68cfC+03tnbh768ujos2+fbf8+/vxHYyu+LHmyYKLBtdBpAx5koFipkTZZYgFG5p9hpK1F oH9gEeigYxRuluGBni1k2X8WavhggwzmdSFiVX34VoCCrejVVwyCOGNiAja42IsLXvhiXKOFhiF/ QQo5JJFS3SeSfDGRdxyTMSE5npJOrjefelEGhx136hWn5XtLcv8JXJfznRdlkmDW9+R37ZFJ3Zjp aSdlm86Nh2STWU5JJ51fZommlPr5+SegTPGnF42mYXYoXYSqaNeNaj1m44ScebZXiowBGGmMmVH6 o4+bsmgZX4Z6WKCnig6oaYqYKUhjhKV6WmGNiErYKqmrotojrSbeWiSvvfrKq6kaHgijjIt2WGuo CN5FV1+6qkhosow6WumJg4kYolnCGuihsMMSi+C1126b4KI6Jpisg9WmxqGC3yoLY7OXhuZuf8/q OGmMMnqL62cgjkvqrwELPHCRkxJ8cJAGI7wwww0HrLDDEUtc78QVExxoU3livDHHGnP8Mcghi2yf xyObfDJTJaP/vDLLKKvcMssvwzwzzTDLXDPO+X2UM8+BWvwz0EELPTTRRRt9NNIX97w00007/TTU UUs9tchJW3011llrvTXXXTNMtZtmrsynzvi9fPPJaEet9ptgH/mn2mx/57Z+W0Oc6ry9mhpbu67d TTGw3q72t8CE+02k4az1/XPijcHWOIleB+n2zXLrR/ZsWzp1NshQWke32GZ/bHnncGcuen2gz5bw sNoCWNq/xIqYL2WHCf5safnqmiFl/664b+uJShvvurGTe66+t7tLIe+OWhjh68mzOjtq74Iaq1/7 fjti9fCiFTzwymvGLPPEOw/78jvq3rv3kr+293+nZut4i52O/6/qo3MVm67883f//Kvud5lR1S+A hMFXp/oDsftxS37om1aq+AUruVwvguQTEP80lT8c0aper6vVoTK4v8p8poMMzJv7HGdBafkrgYXC ngEPqEG8FfB/1auhaBAIJFupEIYiVA2rqJVDGcJPgi+80ahMiEEaJhCIM5yXpaZFQgvyLy04DKLX 3oae4mxEThIRz4dCwp49CeeLYZLTGec0xg9hJz5eQg4bxVabNM4NJ/QpTxfLJJQ2wic7c6KJG/3Y R/CEcYtiLOMc3/imPIZxJ3E0pOeuZJ5G1mQoqktZmozTxUgKEkxq9FwnyQhJQ1bJTmjUoyKTVDnc xAlzodxOHv/19Er6eAeUksQTHatUMltmspWLVORwdpnLJsUpbMaM2qBgyEJUuSVTNZweMyV1RGbd cIW2wuHwXMiiWfnQfvDDFN6WCatT7e1Sz6zgBp05Kx5+KpvqzFUS7fJOdlZzQ5CaZjaxZjaLuERJ bYSIQgBalKB8cmc60WNA/8nPSjrSkUUhm8YSGsmfEMcmgBQoQxOK0F8y6UkYtaguf/JRQK5JjO3x iUwQScg8zfGPWIqlRoM5UNq4aWc3kWhNLXnJnWKSp6fzKVAvF9ShEtU+KUzYUd+X1KUKCXJMfSpT i9pTqU6JqlZt21WzqtWtcrWrXv0qWMMq1rGStaxmPSta06r/1rWytasOc+rB4DokuQKsrkhFGl3p WjG9QrWvSRtbd4gTKM2lzU+EJR0unyY3wroMdW197J/eOle92ZVgelWYXONpNKcujmFw5atfQ5vU 8oXPWdrznvrQJz714c5expMU9KSHPHnlqHatpZc821c+2AJGtuNqXm9nB1zSljN2resQ+ITrOxSK trlMPeEPh7hEw0SxREoUVY0Cg11rRvOCQGrU/uzHKSgq8FHfDS91jzfBB7VoiuJ1LnyLZjpfUuml a6TSIMmIOVzeZktqGuNGR9mnMNG3v7Cs7ylrOkhfeiw8Z6xTgMMWSMhS2LBmTOVISBqUlSbyoNop cEsK+R4H/2MYwP995WE5+UlU4kSifCSTGv1IScG6WKPHmbGJSZK6CvN4c3QEZX6JidU1+feOpmSl KodpYiOjWMK7KbB8EitgK2WylCxusJU/7GQqr7jHXtbiQ0I5FEY+GcJqSiyDS+xPLotpItwZcy7R fN81G7NNGKUyKYtczOnY2cx3vLOGj/nlQWfYwE66s4dXmuGUejSiDk3phg1KZ1re5KBXQjSlG4rH TEPJ0RcNT4dhedNH6zh0LtF0qS1tUjwTeq3xfTWsjwZaYMW61ra+Na6dO+uC5brXCGs1sK9Kuo4F u9jGPjayk63sZTO72c5umq+jLe1pU5vaz742trOt7W1zu//b3v42uMMt7nGTu9zmXl21063udbO7 3e5+N7zjLW+qnLve9r43vvOt72XPu9/+/jfAAy7wgRO84AY/OMITXut9M7zhyFY4xCMu8YlTvOIW vzjGM67xjU/O4R7/uJc5LvKRk9w1ID85ylOu8pWzvOUufznMYy7zmdO85ja/Oc5zDtmS87znPv85 0IM+cZ0TvehGPzrSk670pTO96U5/OtSjLlahU73qB5c61pVu9a1zvete/zrY/5r1sRc97GY/O9rT rva1s73tbo8q2eOO87fTve52vzve4y33vdc8737/O+ADL/jBE77wueY74hOv+MUzvvGOfzzkIy/5 yVO+8pb/vzzmL2/4zXO+857/fGsyL/ptg770mx896lOv+tXXzfSuFzzrY2/s19O+9ra/Pe5zr/uB y773vv898Gm2ieHbZ/ib+Krxia8U4/+J+WBzPt2g3xTpW5761PfT9f+RfOhnHz/db8j3P/Z97itf P+HfmPPPD/7yJ2X76l9K8jGSfuK/X/7sP0r247/+48Of/fXXNn8Y31QIoK8Q4AAOH1QQoAEWyQKK RQMizANGhQFGIGxQoMAoIAK2hgVKxQRuIGtsnwRmoAB6IFWQYASCYAJm4GosIAla3H1Y3/1hXwxq X/kx3//51PjV4AzOxg1iTP29Hwzyn/fpHw0K4f4V3w5O/x8R/qDy9SC2BaAKpuAmhGADuh8HWmEJ quAIut8U2gMGdiEWeqEWJh8VUuEXomBZoGEYmiEXkiEbEkYbXiELoiAXyqEY0qEaRiEc6uEd3mEL YuEX9qEb+mEXSiEbFuIJ4mEhrqAIRuEa1qEUnuEgEmIZ9iF8veD9zd/xkd8RFiFB5J8ObqImfuL2 kSL/jaIn0qApkuIR6l/32WAoIgX5NSEtiqIR2l8triIqwiL9xWIqsuIq/mL7xSAv3uIwimIw8uIv KmMyCiEqdgQsBmP/naIOduIuOmMv5qInamIptlUbMqMwtqIvQmMszqIpPiMuhqM0pqM5nkQ75iA2 xuMyzv+gOdYjMfoiOpIjNRqjUVwfODKFMo6i+3ViKoLiPvZjNqqjLFLjQtoiQbJjOeJjN3pjJiak NHLhPPLjNcpjEXKj/1mkPu5f/LVjSDYjP15kRHJkSW5jSpLkRuqjKyZhOobkDc5fQWbjR3LkLMak RtKiQuLfRJ4jOO7kUIKkR56kVEHhIgpiHFriFiIiHxLiGEIlVS4iJD6lAzYiGCJgBy6lIX6lBXZl GX5jVlKlJTqlFYolWlqlVn4lI3olVr6GJG7lFKLhWQbiWrqlHUqlXNplIKrlX07lXWplCyYVJt7i PxJkUfYkYyqmQR6kQWakZLqjRCKlS4LkMYqjSp7jZD7/4zvK5EMCY02GYi4OJEpCZmUiZDyCJkzO JEvKoz3C5jgS4VYp5QHWZVSKpVreZllWoh+mYVsmIm6a5W7uZV4Cp1ka4h8KZnEqp2Ae52DSpQbq IV66RlcGJyA+Z1xCp3Ha5QfOIXEyp3iGZ3L+JrtVYVum4FpK5yT6Znc+J1imJwY6J10Op3vaYXO+ Z3J2YG/Gp33mZXUGKGG6ZXtGZ3nep166IVYqKFeOZyTqpXsO4gZO4hnS53+SIWA2KFtG5bShZ1VO ZR56J4QSKHxGInyGqIluZ1hSKIem6ImKKIl+qBzO5Ya+YVPmp1RSJx8K54zS54NSYiXeaG46Io5e YRaG/+FV1uFuimiL+lVZOaG2QSkSIqW+SanUWSm2YSlAsqa5aaPkaemzgenycWm5mWbwnWnq7Z6a rimbtmm/oSmcqpWbzmnVxamdmhWd5qme7imfQtWd/unU9amgahygFqqhHqrLDaqiXhyiNipVLSqk RqqkTqqvOKqlDhWlZirBXSqndqqncpumhirAfSqplqqpFpuopuq8nSqrtqqrviqslpuqziqt1qqt 3iqu5qqu7iqv7mqs/iqwBitR9SqxxpewHuvHFKuyLiuzNquzQiqyRqvPPCu1ZpG0Xmt+VKu2biu3 Fhy2fqtRdau4jiu5rhu4nquglKu6riu7whq6vitStCurvH4NvNarvd4rvuYrQcwrvyqNvv4rwAas wA4swdppvx4swias0RTstQYEADs= ------=_NextPart_000_0008_01C71A2C.5A623FE0-- From ipfix-bounces@ietf.org Thu Dec 07 14:10:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsOcO-0000cg-Ay; Thu, 07 Dec 2006 14:09:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsOcM-0000bC-I1 for ipfix@ietf.org; Thu, 07 Dec 2006 14:09:14 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsOcK-0004fs-UP for ipfix@ietf.org; Thu, 07 Dec 2006 14:09:14 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Dec 2006 20:09:13 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB7J9C5W008064; Thu, 7 Dec 2006 20:09:12 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB7J9BAJ019839; Thu, 7 Dec 2006 20:09:11 +0100 (MET) Received: from [10.61.65.30] (ams3-vpn-dhcp286.cisco.com [10.61.65.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA04063; Thu, 7 Dec 2006 19:09:11 GMT Message-ID: <457866B8.4010301@cisco.com> Date: Thu, 07 Dec 2006 19:08:40 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] Cascading Common Properties References: <3167F18F59B81B4888A4D4C0A1717DD6670F99@mhdexc02.adhel.hitachi-eu.com> <45782EF1.7090809@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5904; t=1165518552; x=1166382552; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Cascading=20Common=20Properties |Sender:=20; bh=zK+ypRqQDXeW+p9CZDKrSJsOPjzDcq8TZDP/JtwdnEI=; b=MqGQ5qb3SVFqMdluytcmRJ/34am9LuCRipxgbH3LCWnQB2wzd7YqiGNsaenOrENlLHFVBu7x VuSZuskpkKRpYzTeFadSUBFDbZ4awKQSZEmdvqtlJI0NXEcL2N5ehEOx; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: Elisa Boschi , ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi all May I propose a relatively simple solution. I think cascades of identifiers is valid in IPFIX and useful. I also think that they are a lot simpler than people imagine. NORMAL OPTIONS ============== An option can be thought of as a substitution. When a Data Record is received containing Flow information then any identifiers in that Record can be immediately substituted for the data associated with it. For example, a Data Record containing: commonPropertiesID = 5 ipv4SourceAddress = 192.168.0.1 If we have a definition of cpID 5, say ipv4DestinationAddress = 192.168.0.2) then the collector can immediately expand that into: ipv4DestinationAddress = 192.168.0.1 ipv4SourceAddress = 192.168.0.1 If cpId 5 is withdrawn or redefined at a later date then that does NOT redefine this expanded Record. If cpId 5 is not defined, the collector can hold off decoding the Data Record for a short while before discarding it. CASCADING OPTIONS ================= If a Data Record is received which is definition then any identifiers in that Record an be immediately substituted for the data associated with it. For example: commonProperties ID = 6 (scope) commonPropertiesID = 5 ipv4SourceAddress = 192.168.0.1 Can be immediately expanded into: commonProperties ID = 6 (scope) ipv4DestinationAddress = 192.168.0.1 ipv4SourceAddress = 192.168.0.1 If cpId 5 is withdrawn or redefined at a later date then that does NOT redefine this expanded Record. If cpId 5 is not defined, the collector can hold off decoding the Data Record for a short while before discarding it. A circular definition will sit on the waiting queue until it is discarded. A "collision" will immediately expand out to contain the IE twice. Today we can send Data Records with the same IE twice so why not. It should be noted that ordering should be preserved. Andrew Brian Trammell wrote: > All, > > Agreed that common properties cascades 1. should be allowed, and 2. > addressed explicitly in the document. > > To keep the discussion going, I'd like to propose solutions (or at least > choices of solutions) for the points Elisa raised: > >>> duplication (as also written by Andrew) >>> >>> cpID A --> src addr A, src port A >>> cpID B --> src addr A, cpID A >>> >>> collision >>> >>> cpID A --> src addr A, src port A >>> cpID A --> src addr B, cpID A > > I can think of two possible simple ways to address these concerns: > > 1. The principles in 3.1.2 Multiple Data Reduction could be readily > extended to handle cascades: simply disallow any sort of collision, of > which duplication is merely a subset. > > 2. Allow collision or duplication in the cascade, but ONLY to allow a > common property "lower" in the hierarchy to override values of one > "higher". This makes cascades potentially much more useful (giving us > workable inheritance) at the expense of a fair amount of complexity. > > I don't personally have a strong opinion in either direction. > >>> withdrawal >>> >>> what happens to a node in the tree if one of its children (or a node >>> in its subtree) is a cpID and is withdrawn? Does the collecting >>> process need to search for all the CP that are defined in terms of it >>> and invalidate them too? > > Yes... it seems to me the only real difficulty with cascading common > properties (indeed, with cascading _anything_ really) is handling > withdrawal. We could of course allow any of the various policies for > cascading withdrawal and even provide a mechanism for setting the common > properties withdrawal cascade policy via options (and even allow those > options to be bound to common properties themselves, if we were feeling > particularly uncharitable toward CP implementors :) ) but I don't think > we want to do that for the sake of simplicity. So I think we want to > pick a single withdrawal cascade policy. > > There is a question to answer explicitly before doing so: When a common > property is withdrawn or invalid, is the record referencing it 1. > invalid (as is implied by the document currently, and by most of the > messages in these threads) or 2. valid but simply missing data (as has > been proposed at least once, I forget by whom, but not particularly > deeply discussed yet). Note that if inheritance and overrides are > available in cascades as above, this second case is _not_ a valid choice. > > In the first case, I would propose that 1. an Exporting Process SHOULD > withdraw all common properties "lower" in the cascade before withdrawing > the common properties they reference; 2. a Collecting Process MUST > invalidate all common properties defined in terms of a withdrawn common > property; and 3. a Collecting Process MUST ignore common properties > withdrawals sent by an Exporting Process that would withdraw common > properties previously invalidated by a cascade withdrawal as in 2. This > proposal is not particularly simple, but I think it is as simple as it > can be while holding to the principle of being liberal in what you > accept and conservative in what you send, and to the IPFIX design > requirement to minimize complexity at the EP. > > In the second case, cascade withdrawal becomes simpler: simply ignore > the cascade. The Exporting Process MUST explicitly withdraw any common > property that is no longer valid, regardless of whether it's defined in > terms of others. Partially withdrawn cascades would then merely be > partially valid. > > (For what it's worth, I personally lean toward the first case here.) > > Thoughts? > > Regards, > > Brian > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 14:10:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsOcO-0000cg-Ay; Thu, 07 Dec 2006 14:09:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsOcM-0000bC-I1 for ipfix@ietf.org; Thu, 07 Dec 2006 14:09:14 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsOcK-0004fs-UP for ipfix@ietf.org; Thu, 07 Dec 2006 14:09:14 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Dec 2006 20:09:13 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB7J9C5W008064; Thu, 7 Dec 2006 20:09:12 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB7J9BAJ019839; Thu, 7 Dec 2006 20:09:11 +0100 (MET) Received: from [10.61.65.30] (ams3-vpn-dhcp286.cisco.com [10.61.65.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA04063; Thu, 7 Dec 2006 19:09:11 GMT Message-ID: <457866B8.4010301@cisco.com> Date: Thu, 07 Dec 2006 19:08:40 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] Cascading Common Properties References: <3167F18F59B81B4888A4D4C0A1717DD6670F99@mhdexc02.adhel.hitachi-eu.com> <45782EF1.7090809@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5904; t=1165518552; x=1166382552; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Cascading=20Common=20Properties |Sender:=20; bh=zK+ypRqQDXeW+p9CZDKrSJsOPjzDcq8TZDP/JtwdnEI=; b=MqGQ5qb3SVFqMdluytcmRJ/34am9LuCRipxgbH3LCWnQB2wzd7YqiGNsaenOrENlLHFVBu7x VuSZuskpkKRpYzTeFadSUBFDbZ4awKQSZEmdvqtlJI0NXEcL2N5ehEOx; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: Elisa Boschi , ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi all May I propose a relatively simple solution. I think cascades of identifiers is valid in IPFIX and useful. I also think that they are a lot simpler than people imagine. NORMAL OPTIONS ============== An option can be thought of as a substitution. When a Data Record is received containing Flow information then any identifiers in that Record can be immediately substituted for the data associated with it. For example, a Data Record containing: commonPropertiesID = 5 ipv4SourceAddress = 192.168.0.1 If we have a definition of cpID 5, say ipv4DestinationAddress = 192.168.0.2) then the collector can immediately expand that into: ipv4DestinationAddress = 192.168.0.1 ipv4SourceAddress = 192.168.0.1 If cpId 5 is withdrawn or redefined at a later date then that does NOT redefine this expanded Record. If cpId 5 is not defined, the collector can hold off decoding the Data Record for a short while before discarding it. CASCADING OPTIONS ================= If a Data Record is received which is definition then any identifiers in that Record an be immediately substituted for the data associated with it. For example: commonProperties ID = 6 (scope) commonPropertiesID = 5 ipv4SourceAddress = 192.168.0.1 Can be immediately expanded into: commonProperties ID = 6 (scope) ipv4DestinationAddress = 192.168.0.1 ipv4SourceAddress = 192.168.0.1 If cpId 5 is withdrawn or redefined at a later date then that does NOT redefine this expanded Record. If cpId 5 is not defined, the collector can hold off decoding the Data Record for a short while before discarding it. A circular definition will sit on the waiting queue until it is discarded. A "collision" will immediately expand out to contain the IE twice. Today we can send Data Records with the same IE twice so why not. It should be noted that ordering should be preserved. Andrew Brian Trammell wrote: > All, > > Agreed that common properties cascades 1. should be allowed, and 2. > addressed explicitly in the document. > > To keep the discussion going, I'd like to propose solutions (or at least > choices of solutions) for the points Elisa raised: > >>> duplication (as also written by Andrew) >>> >>> cpID A --> src addr A, src port A >>> cpID B --> src addr A, cpID A >>> >>> collision >>> >>> cpID A --> src addr A, src port A >>> cpID A --> src addr B, cpID A > > I can think of two possible simple ways to address these concerns: > > 1. The principles in 3.1.2 Multiple Data Reduction could be readily > extended to handle cascades: simply disallow any sort of collision, of > which duplication is merely a subset. > > 2. Allow collision or duplication in the cascade, but ONLY to allow a > common property "lower" in the hierarchy to override values of one > "higher". This makes cascades potentially much more useful (giving us > workable inheritance) at the expense of a fair amount of complexity. > > I don't personally have a strong opinion in either direction. > >>> withdrawal >>> >>> what happens to a node in the tree if one of its children (or a node >>> in its subtree) is a cpID and is withdrawn? Does the collecting >>> process need to search for all the CP that are defined in terms of it >>> and invalidate them too? > > Yes... it seems to me the only real difficulty with cascading common > properties (indeed, with cascading _anything_ really) is handling > withdrawal. We could of course allow any of the various policies for > cascading withdrawal and even provide a mechanism for setting the common > properties withdrawal cascade policy via options (and even allow those > options to be bound to common properties themselves, if we were feeling > particularly uncharitable toward CP implementors :) ) but I don't think > we want to do that for the sake of simplicity. So I think we want to > pick a single withdrawal cascade policy. > > There is a question to answer explicitly before doing so: When a common > property is withdrawn or invalid, is the record referencing it 1. > invalid (as is implied by the document currently, and by most of the > messages in these threads) or 2. valid but simply missing data (as has > been proposed at least once, I forget by whom, but not particularly > deeply discussed yet). Note that if inheritance and overrides are > available in cascades as above, this second case is _not_ a valid choice. > > In the first case, I would propose that 1. an Exporting Process SHOULD > withdraw all common properties "lower" in the cascade before withdrawing > the common properties they reference; 2. a Collecting Process MUST > invalidate all common properties defined in terms of a withdrawn common > property; and 3. a Collecting Process MUST ignore common properties > withdrawals sent by an Exporting Process that would withdraw common > properties previously invalidated by a cascade withdrawal as in 2. This > proposal is not particularly simple, but I think it is as simple as it > can be while holding to the principle of being liberal in what you > accept and conservative in what you send, and to the IPFIX design > requirement to minimize complexity at the EP. > > In the second case, cascade withdrawal becomes simpler: simply ignore > the cascade. The Exporting Process MUST explicitly withdraw any common > property that is no longer valid, regardless of whether it's defined in > terms of others. Partially withdrawn cascades would then merely be > partially valid. > > (For what it's worth, I personally lean toward the first case here.) > > Thoughts? > > Regards, > > Brian > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 14:36:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsP2T-0003mT-Bd; Thu, 07 Dec 2006 14:36:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsP2S-0003mN-3M for ipfix@ietf.org; Thu, 07 Dec 2006 14:36:12 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsP2Q-0008Fx-F4 for ipfix@ietf.org; Thu, 07 Dec 2006 14:36:12 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Dec 2006 20:36:10 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB7Ja9mR025630; Thu, 7 Dec 2006 20:36:09 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB7Ja9AJ009620; Thu, 7 Dec 2006 20:36:09 +0100 (MET) Received: from [10.61.65.30] (ams3-vpn-dhcp286.cisco.com [10.61.65.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA06614; Thu, 7 Dec 2006 19:36:08 GMT Message-ID: <45786D1E.8030906@cisco.com> Date: Thu, 07 Dec 2006 19:35:58 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] Cascading Common Properties Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6241; t=1165520169; x=1166384169; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Cascading=20Common=20Properties |Sender:=20; bh=HG3Ihr+hvnh+j9Dl1irD87Nfmu8A0LBr3O5H/xAtkh8=; b=ULJrzwAk8i5oUBf+88yRNnnxDcuXXe0m04l+6FqGtLcaOULYH82jBfIt8Dgv3A/V7Mz3fbuU Rl0tTChpXyLMeZlRJNhtCd0t+SZpNiswiKH4HScJidbZVKqtfY+kJAlU; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Repeated email with correction to the example: ipv4DestinationAddress of 192.168.0.1 -> 192.168.0.2 Thanks to Danny Llewallyn for pointing it out. Cheers Andrew -------- Original Message -------- Hi all May I propose a relatively simple solution. I think cascades of identifiers is valid in IPFIX and useful. I also think that they are a lot simpler than people imagine. NORMAL OPTIONS ============== An option can be thought of as a substitution. When a Data Record is received containing Flow information then any identifiers in that Record can be immediately substituted for the data associated with it. For example, a Data Record containing: commonPropertiesID = 5 ipv4SourceAddress = 192.168.0.1 If we have a definition of cpID 5, say ipv4DestinationAddress = 192.168.0.2) then the collector can immediately expand that into: ipv4DestinationAddress = 192.168.0.2 ipv4SourceAddress = 192.168.0.1 If cpId 5 is withdrawn or redefined at a later date then that does NOT redefine this expanded Record. If cpId 5 is not defined, the collector can hold off decoding the Data Record for a short while before discarding it. CASCADING OPTIONS ================= If a Data Record is received which is definition then any identifiers in that Record an be immediately substituted for the data associated with it. For example: commonProperties ID = 6 (scope) commonPropertiesID = 5 ipv4SourceAddress = 192.168.0.1 Can be immediately expanded into: commonProperties ID = 6 (scope) ipv4DestinationAddress = 192.168.0.2 ipv4SourceAddress = 192.168.0.1 If cpId 5 is withdrawn or redefined at a later date then that does NOT redefine this expanded Record. If cpId 5 is not defined, the collector can hold off decoding the Data Record for a short while before discarding it. A circular definition will sit on the waiting queue until it is discarded. A "collision" will immediately expand out to contain the IE twice. Today we can send Data Records with the same IE twice so why not. It should be noted that ordering should be preserved. Andrew Brian Trammell wrote: > All, > > Agreed that common properties cascades 1. should be allowed, and 2. > addressed explicitly in the document. > > To keep the discussion going, I'd like to propose solutions (or at least > choices of solutions) for the points Elisa raised: > >>> duplication (as also written by Andrew) >>> >>> cpID A --> src addr A, src port A >>> cpID B --> src addr A, cpID A >>> >>> collision >>> >>> cpID A --> src addr A, src port A >>> cpID A --> src addr B, cpID A > > I can think of two possible simple ways to address these concerns: > > 1. The principles in 3.1.2 Multiple Data Reduction could be readily > extended to handle cascades: simply disallow any sort of collision, of > which duplication is merely a subset. > > 2. Allow collision or duplication in the cascade, but ONLY to allow a > common property "lower" in the hierarchy to override values of one > "higher". This makes cascades potentially much more useful (giving us > workable inheritance) at the expense of a fair amount of complexity. > > I don't personally have a strong opinion in either direction. > >>> withdrawal >>> >>> what happens to a node in the tree if one of its children (or a node >>> in its subtree) is a cpID and is withdrawn? Does the collecting >>> process need to search for all the CP that are defined in terms of it >>> and invalidate them too? > > Yes... it seems to me the only real difficulty with cascading common > properties (indeed, with cascading _anything_ really) is handling > withdrawal. We could of course allow any of the various policies for > cascading withdrawal and even provide a mechanism for setting the common > properties withdrawal cascade policy via options (and even allow those > options to be bound to common properties themselves, if we were feeling > particularly uncharitable toward CP implementors :) ) but I don't think > we want to do that for the sake of simplicity. So I think we want to > pick a single withdrawal cascade policy. > > There is a question to answer explicitly before doing so: When a common > property is withdrawn or invalid, is the record referencing it 1. > invalid (as is implied by the document currently, and by most of the > messages in these threads) or 2. valid but simply missing data (as has > been proposed at least once, I forget by whom, but not particularly > deeply discussed yet). Note that if inheritance and overrides are > available in cascades as above, this second case is _not_ a valid choice. > > In the first case, I would propose that 1. an Exporting Process SHOULD > withdraw all common properties "lower" in the cascade before withdrawing > the common properties they reference; 2. a Collecting Process MUST > invalidate all common properties defined in terms of a withdrawn common > property; and 3. a Collecting Process MUST ignore common properties > withdrawals sent by an Exporting Process that would withdraw common > properties previously invalidated by a cascade withdrawal as in 2. This > proposal is not particularly simple, but I think it is as simple as it > can be while holding to the principle of being liberal in what you > accept and conservative in what you send, and to the IPFIX design > requirement to minimize complexity at the EP. > > In the second case, cascade withdrawal becomes simpler: simply ignore > the cascade. The Exporting Process MUST explicitly withdraw any common > property that is no longer valid, regardless of whether it's defined in > terms of others. Partially withdrawn cascades would then merely be > partially valid. > > (For what it's worth, I personally lean toward the first case here.) > > Thoughts? > > Regards, > > Brian > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 14:36:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsP2T-0003mT-Bd; Thu, 07 Dec 2006 14:36:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsP2S-0003mN-3M for ipfix@ietf.org; Thu, 07 Dec 2006 14:36:12 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsP2Q-0008Fx-F4 for ipfix@ietf.org; Thu, 07 Dec 2006 14:36:12 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Dec 2006 20:36:10 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB7Ja9mR025630; Thu, 7 Dec 2006 20:36:09 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB7Ja9AJ009620; Thu, 7 Dec 2006 20:36:09 +0100 (MET) Received: from [10.61.65.30] (ams3-vpn-dhcp286.cisco.com [10.61.65.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA06614; Thu, 7 Dec 2006 19:36:08 GMT Message-ID: <45786D1E.8030906@cisco.com> Date: Thu, 07 Dec 2006 19:35:58 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] Cascading Common Properties Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6241; t=1165520169; x=1166384169; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Cascading=20Common=20Properties |Sender:=20; bh=HG3Ihr+hvnh+j9Dl1irD87Nfmu8A0LBr3O5H/xAtkh8=; b=ULJrzwAk8i5oUBf+88yRNnnxDcuXXe0m04l+6FqGtLcaOULYH82jBfIt8Dgv3A/V7Mz3fbuU Rl0tTChpXyLMeZlRJNhtCd0t+SZpNiswiKH4HScJidbZVKqtfY+kJAlU; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Repeated email with correction to the example: ipv4DestinationAddress of 192.168.0.1 -> 192.168.0.2 Thanks to Danny Llewallyn for pointing it out. Cheers Andrew -------- Original Message -------- Hi all May I propose a relatively simple solution. I think cascades of identifiers is valid in IPFIX and useful. I also think that they are a lot simpler than people imagine. NORMAL OPTIONS ============== An option can be thought of as a substitution. When a Data Record is received containing Flow information then any identifiers in that Record can be immediately substituted for the data associated with it. For example, a Data Record containing: commonPropertiesID = 5 ipv4SourceAddress = 192.168.0.1 If we have a definition of cpID 5, say ipv4DestinationAddress = 192.168.0.2) then the collector can immediately expand that into: ipv4DestinationAddress = 192.168.0.2 ipv4SourceAddress = 192.168.0.1 If cpId 5 is withdrawn or redefined at a later date then that does NOT redefine this expanded Record. If cpId 5 is not defined, the collector can hold off decoding the Data Record for a short while before discarding it. CASCADING OPTIONS ================= If a Data Record is received which is definition then any identifiers in that Record an be immediately substituted for the data associated with it. For example: commonProperties ID = 6 (scope) commonPropertiesID = 5 ipv4SourceAddress = 192.168.0.1 Can be immediately expanded into: commonProperties ID = 6 (scope) ipv4DestinationAddress = 192.168.0.2 ipv4SourceAddress = 192.168.0.1 If cpId 5 is withdrawn or redefined at a later date then that does NOT redefine this expanded Record. If cpId 5 is not defined, the collector can hold off decoding the Data Record for a short while before discarding it. A circular definition will sit on the waiting queue until it is discarded. A "collision" will immediately expand out to contain the IE twice. Today we can send Data Records with the same IE twice so why not. It should be noted that ordering should be preserved. Andrew Brian Trammell wrote: > All, > > Agreed that common properties cascades 1. should be allowed, and 2. > addressed explicitly in the document. > > To keep the discussion going, I'd like to propose solutions (or at least > choices of solutions) for the points Elisa raised: > >>> duplication (as also written by Andrew) >>> >>> cpID A --> src addr A, src port A >>> cpID B --> src addr A, cpID A >>> >>> collision >>> >>> cpID A --> src addr A, src port A >>> cpID A --> src addr B, cpID A > > I can think of two possible simple ways to address these concerns: > > 1. The principles in 3.1.2 Multiple Data Reduction could be readily > extended to handle cascades: simply disallow any sort of collision, of > which duplication is merely a subset. > > 2. Allow collision or duplication in the cascade, but ONLY to allow a > common property "lower" in the hierarchy to override values of one > "higher". This makes cascades potentially much more useful (giving us > workable inheritance) at the expense of a fair amount of complexity. > > I don't personally have a strong opinion in either direction. > >>> withdrawal >>> >>> what happens to a node in the tree if one of its children (or a node >>> in its subtree) is a cpID and is withdrawn? Does the collecting >>> process need to search for all the CP that are defined in terms of it >>> and invalidate them too? > > Yes... it seems to me the only real difficulty with cascading common > properties (indeed, with cascading _anything_ really) is handling > withdrawal. We could of course allow any of the various policies for > cascading withdrawal and even provide a mechanism for setting the common > properties withdrawal cascade policy via options (and even allow those > options to be bound to common properties themselves, if we were feeling > particularly uncharitable toward CP implementors :) ) but I don't think > we want to do that for the sake of simplicity. So I think we want to > pick a single withdrawal cascade policy. > > There is a question to answer explicitly before doing so: When a common > property is withdrawn or invalid, is the record referencing it 1. > invalid (as is implied by the document currently, and by most of the > messages in these threads) or 2. valid but simply missing data (as has > been proposed at least once, I forget by whom, but not particularly > deeply discussed yet). Note that if inheritance and overrides are > available in cascades as above, this second case is _not_ a valid choice. > > In the first case, I would propose that 1. an Exporting Process SHOULD > withdraw all common properties "lower" in the cascade before withdrawing > the common properties they reference; 2. a Collecting Process MUST > invalidate all common properties defined in terms of a withdrawn common > property; and 3. a Collecting Process MUST ignore common properties > withdrawals sent by an Exporting Process that would withdraw common > properties previously invalidated by a cascade withdrawal as in 2. This > proposal is not particularly simple, but I think it is as simple as it > can be while holding to the principle of being liberal in what you > accept and conservative in what you send, and to the IPFIX design > requirement to minimize complexity at the EP. > > In the second case, cascade withdrawal becomes simpler: simply ignore > the cascade. The Exporting Process MUST explicitly withdraw any common > property that is no longer valid, regardless of whether it's defined in > terms of others. Partially withdrawn cascades would then merely be > partially valid. > > (For what it's worth, I personally lean toward the first case here.) > > Thoughts? > > Regards, > > Brian > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 17:33:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsRmg-0005LC-7h; Thu, 07 Dec 2006 17:32:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsRmf-0005Kb-3G for ipfix@ietf.org; Thu, 07 Dec 2006 17:32:05 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsRmd-00024H-S1 for ipfix@ietf.org; Thu, 07 Dec 2006 17:32:05 -0500 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kB7MVrGj027517 for ; Thu, 7 Dec 2006 17:31:58 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kB7MVAjS027443 for ; Thu, 7 Dec 2006 17:31:10 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kB7MV98o027441; Thu, 07 Dec 2006 17:31:10 -0500 (EST) Received: from [131.106.59.192] (vpn-10-25-4-10.remote.cert.org [10.25.4.10]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.66) with ESMTP id kB7MV9ZA000455; Thu, 7 Dec 2006 17:31:09 -0500 In-Reply-To: <45784642.4060203@fokus.fraunhofer.de> References: <3167F18F59B81B4888A4D4C0A1717DD6670F99@mhdexc02.adhel.hitachi-eu.com> <45782EF1.7090809@cisco.com> <45784642.4060203@fokus.fraunhofer.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <936FE56F-AD87-416F-B403-913A4357D81A@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] Cascading Common Properties Date: Thu, 7 Dec 2006 17:30:25 -0500 To: Lutz Mark X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Lutz, Ah, yes. I keep forgetting about this feature (largely, I think, because though we do support it now, we don't use it :) ). While I still think it would be useful to support inheritance with common properties cascades, it doesn't appear that the changes necessary to actually support it (i.e. you'd need some way to note one IE can override another) would be worth the effort. So, point 2. of proposal withdrawn. Of course, as Andrew points out, this does not actually solve the problem with reconciling multiple IEs with common properties. See my reply to his message, forthcoming... Regards, Brian On Dec 7, 2006, at 11:50 AM, Lutz Mark wrote: > > > Brian, > >> To keep the discussion going, I'd like to propose solutions (or at >> least choices of solutions) for the points Elisa raised: > > thanks for your assistance. > >>>> duplication (as also written by Andrew) >>>> >>>> cpID A --> src addr A, src port A >>>> cpID B --> src addr A, cpID A >>>> >>>> collision >>>> >>>> cpID A --> src addr A, src port A >>>> cpID A --> src addr B, cpID A >> I can think of two possible simple ways to address these concerns: >> 1. The principles in 3.1.2 Multiple Data Reduction could be >> readily extended to handle cascades: simply disallow any sort of >> collision, of which duplication is merely a subset. >> 2. Allow collision or duplication in the cascade, but ONLY to >> allow a common property "lower" in the hierarchy to override >> values of one "higher". This makes cascades potentially much more >> useful (giving us workable inheritance) at the expense of a fair >> amount of complexity. > > I think it's not so easy since the protocol allows to have > multiple IEs of the same type within a template. > > Regards, > Lutz > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 17:33:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsRmg-0005LC-7h; Thu, 07 Dec 2006 17:32:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsRmf-0005Kb-3G for ipfix@ietf.org; Thu, 07 Dec 2006 17:32:05 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsRmd-00024H-S1 for ipfix@ietf.org; Thu, 07 Dec 2006 17:32:05 -0500 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kB7MVrGj027517 for ; Thu, 7 Dec 2006 17:31:58 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kB7MVAjS027443 for ; Thu, 7 Dec 2006 17:31:10 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kB7MV98o027441; Thu, 07 Dec 2006 17:31:10 -0500 (EST) Received: from [131.106.59.192] (vpn-10-25-4-10.remote.cert.org [10.25.4.10]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.66) with ESMTP id kB7MV9ZA000455; Thu, 7 Dec 2006 17:31:09 -0500 In-Reply-To: <45784642.4060203@fokus.fraunhofer.de> References: <3167F18F59B81B4888A4D4C0A1717DD6670F99@mhdexc02.adhel.hitachi-eu.com> <45782EF1.7090809@cisco.com> <45784642.4060203@fokus.fraunhofer.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <936FE56F-AD87-416F-B403-913A4357D81A@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] Cascading Common Properties Date: Thu, 7 Dec 2006 17:30:25 -0500 To: Lutz Mark X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Lutz, Ah, yes. I keep forgetting about this feature (largely, I think, because though we do support it now, we don't use it :) ). While I still think it would be useful to support inheritance with common properties cascades, it doesn't appear that the changes necessary to actually support it (i.e. you'd need some way to note one IE can override another) would be worth the effort. So, point 2. of proposal withdrawn. Of course, as Andrew points out, this does not actually solve the problem with reconciling multiple IEs with common properties. See my reply to his message, forthcoming... Regards, Brian On Dec 7, 2006, at 11:50 AM, Lutz Mark wrote: > > > Brian, > >> To keep the discussion going, I'd like to propose solutions (or at >> least choices of solutions) for the points Elisa raised: > > thanks for your assistance. > >>>> duplication (as also written by Andrew) >>>> >>>> cpID A --> src addr A, src port A >>>> cpID B --> src addr A, cpID A >>>> >>>> collision >>>> >>>> cpID A --> src addr A, src port A >>>> cpID A --> src addr B, cpID A >> I can think of two possible simple ways to address these concerns: >> 1. The principles in 3.1.2 Multiple Data Reduction could be >> readily extended to handle cascades: simply disallow any sort of >> collision, of which duplication is merely a subset. >> 2. Allow collision or duplication in the cascade, but ONLY to >> allow a common property "lower" in the hierarchy to override >> values of one "higher". This makes cascades potentially much more >> useful (giving us workable inheritance) at the expense of a fair >> amount of complexity. > > I think it's not so easy since the protocol allows to have > multiple IEs of the same type within a template. > > Regards, > Lutz > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 17:46:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsS0X-0003BJ-L7; Thu, 07 Dec 2006 17:46:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsS0W-0003BE-FL for ipfix@ietf.org; Thu, 07 Dec 2006 17:46:24 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsS0U-0004fB-0w for ipfix@ietf.org; Thu, 07 Dec 2006 17:46:24 -0500 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kB7MkCgq010832 for ; Thu, 7 Dec 2006 17:46:17 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kB7Mj8uY010741 for ; Thu, 7 Dec 2006 17:45:08 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kB7Mj7Sp010737; Thu, 07 Dec 2006 17:45:08 -0500 (EST) Received: from [131.106.59.192] (vpn-10-25-4-10.remote.cert.org [10.25.4.10]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.66) with ESMTP id kB7Mj7Ms002457; Thu, 7 Dec 2006 17:45:07 -0500 In-Reply-To: <45786D1E.8030906@cisco.com> References: <45786D1E.8030906@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <658B4059-38B5-4C20-AF57-783EE3F8949E@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] Cascading Common Properties Date: Thu, 7 Dec 2006 17:44:23 -0500 To: Andrew Johnson X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Andrew, Let me make sure I understand this by restating it a bit: 1. When the Collecting Process receives Common Properties that reference other Common Properties themselves, it MUST resolve the references to Common Properties. A Collecting Process MAY hold Common Properties for later resolution if the referenced Common Properties are not yet defined. 2. An Exporting Process MUST NOT export Common Properties that reference themselves directly, and a Collecting Process MUST drop any Common Properties that reference themselves directly and SHOULD log the error. 3. If a given Information Element appears both in a Record and by reference to Common Properties (whether in cascaded Common Properties or not), it MUST be treated as a multiple Information Element. The order of the multiple Information Elements MUST be determined from the arrangement of the commonPropertiesId and referenced Information Elements in the Data Record, and this order MUST be preserved. Note that this third point would modify the present section 3.1.2 multiple data reduction treatment of collisions. (Also, I just realized something... if the three points above accurately describe what you're proposing, this could also be used to, somewhat inefficiently, build variable-length arrays in IPFIX...) Hmmm.... I like it. It's simple, it's useful, it's implementable, and it requires fewer changes to the document at this point. Unless I'm missing something. :) Cheers, Brian On Dec 7, 2006, at 2:35 PM, Andrew Johnson wrote: > Repeated email with correction to the example: > ipv4DestinationAddress of 192.168.0.1 -> 192.168.0.2 > > Thanks to Danny Llewallyn for pointing it out. > > Cheers > > Andrew > > -------- Original Message -------- > > Hi all > > May I propose a relatively simple solution. I think cascades of > identifiers is valid in IPFIX and useful. I also think that they > are a lot simpler than people imagine. > > > NORMAL OPTIONS > ============== > An option can be thought of as a substitution. When a Data Record > is received containing Flow information then any identifiers in > that Record can be immediately substituted for the data associated > with it. > > For example, a Data Record containing: > commonPropertiesID = 5 > ipv4SourceAddress = 192.168.0.1 > > If we have a definition of cpID 5, say ipv4DestinationAddress = > 192.168.0.2) then the collector can immediately expand that into: > ipv4DestinationAddress = 192.168.0.2 > ipv4SourceAddress = 192.168.0.1 > > If cpId 5 is withdrawn or redefined at a later date then that > does NOT redefine this expanded Record. > > If cpId 5 is not defined, the collector can hold off decoding > the Data Record for a short while before discarding it. > > CASCADING OPTIONS > ================= > If a Data Record is received which is definition then any > identifiers in that Record an be immediately substituted for > the data associated with it. For example: > commonProperties ID = 6 (scope) > commonPropertiesID = 5 > ipv4SourceAddress = 192.168.0.1 > > Can be immediately expanded into: > commonProperties ID = 6 (scope) > ipv4DestinationAddress = 192.168.0.2 > ipv4SourceAddress = 192.168.0.1 > > If cpId 5 is withdrawn or redefined at a later date then that > does NOT redefine this expanded Record. > > If cpId 5 is not defined, the collector can hold off decoding > the Data Record for a short while before discarding it. > > A circular definition will sit on the waiting queue until it > is discarded. A "collision" will immediately expand out to > contain the IE twice. Today we can send Data Records with > the same IE twice so why not. It should be noted that > ordering should be preserved. > > Andrew > > > Brian Trammell wrote: >> All, >> Agreed that common properties cascades 1. should be allowed, and >> 2. addressed explicitly in the document. >> To keep the discussion going, I'd like to propose solutions (or at >> least choices of solutions) for the points Elisa raised: >>>> duplication (as also written by Andrew) >>>> >>>> cpID A --> src addr A, src port A >>>> cpID B --> src addr A, cpID A >>>> >>>> collision >>>> >>>> cpID A --> src addr A, src port A >>>> cpID A --> src addr B, cpID A >> I can think of two possible simple ways to address these concerns: >> 1. The principles in 3.1.2 Multiple Data Reduction could be >> readily extended to handle cascades: simply disallow any sort of >> collision, of which duplication is merely a subset. >> 2. Allow collision or duplication in the cascade, but ONLY to >> allow a common property "lower" in the hierarchy to override >> values of one "higher". This makes cascades potentially much more >> useful (giving us workable inheritance) at the expense of a fair >> amount of complexity. >> I don't personally have a strong opinion in either direction. >>>> withdrawal >>>> >>>> what happens to a node in the tree if one of its children (or a >>>> node in its subtree) is a cpID and is withdrawn? Does the >>>> collecting process need to search for all the CP that are >>>> defined in terms of it and invalidate them too? >> Yes... it seems to me the only real difficulty with cascading >> common properties (indeed, with cascading _anything_ really) is >> handling withdrawal. We could of course allow any of the various >> policies for cascading withdrawal and even provide a mechanism for >> setting the common properties withdrawal cascade policy via >> options (and even allow those options to be bound to common >> properties themselves, if we were feeling particularly >> uncharitable toward CP implementors :) ) but I don't think we want >> to do that for the sake of simplicity. So I think we want to pick >> a single withdrawal cascade policy. >> There is a question to answer explicitly before doing so: When a >> common property is withdrawn or invalid, is the record referencing >> it 1. invalid (as is implied by the document currently, and by >> most of the messages in these threads) or 2. valid but simply >> missing data (as has been proposed at least once, I forget by >> whom, but not particularly deeply discussed yet). Note that if >> inheritance and overrides are available in cascades as above, this >> second case is _not_ a valid choice. >> In the first case, I would propose that 1. an Exporting Process >> SHOULD withdraw all common properties "lower" in the cascade >> before withdrawing the common properties they reference; 2. a >> Collecting Process MUST invalidate all common properties defined >> in terms of a withdrawn common property; and 3. a Collecting >> Process MUST ignore common properties withdrawals sent by an >> Exporting Process that would withdraw common properties previously >> invalidated by a cascade withdrawal as in 2. This proposal is not >> particularly simple, but I think it is as simple as it can be >> while holding to the principle of being liberal in what you accept >> and conservative in what you send, and to the IPFIX design >> requirement to minimize complexity at the EP. >> In the second case, cascade withdrawal becomes simpler: simply >> ignore the cascade. The Exporting Process MUST explicitly withdraw >> any common property that is no longer valid, regardless of whether >> it's defined in terms of others. Partially withdrawn cascades >> would then merely be partially valid. >> (For what it's worth, I personally lean toward the first case here.) >> Thoughts? >> Regards, >> Brian >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipfix > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 17:46:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsS0X-0003BJ-L7; Thu, 07 Dec 2006 17:46:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsS0W-0003BE-FL for ipfix@ietf.org; Thu, 07 Dec 2006 17:46:24 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsS0U-0004fB-0w for ipfix@ietf.org; Thu, 07 Dec 2006 17:46:24 -0500 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kB7MkCgq010832 for ; Thu, 7 Dec 2006 17:46:17 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kB7Mj8uY010741 for ; Thu, 7 Dec 2006 17:45:08 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kB7Mj7Sp010737; Thu, 07 Dec 2006 17:45:08 -0500 (EST) Received: from [131.106.59.192] (vpn-10-25-4-10.remote.cert.org [10.25.4.10]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.66) with ESMTP id kB7Mj7Ms002457; Thu, 7 Dec 2006 17:45:07 -0500 In-Reply-To: <45786D1E.8030906@cisco.com> References: <45786D1E.8030906@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <658B4059-38B5-4C20-AF57-783EE3F8949E@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] Cascading Common Properties Date: Thu, 7 Dec 2006 17:44:23 -0500 To: Andrew Johnson X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Andrew, Let me make sure I understand this by restating it a bit: 1. When the Collecting Process receives Common Properties that reference other Common Properties themselves, it MUST resolve the references to Common Properties. A Collecting Process MAY hold Common Properties for later resolution if the referenced Common Properties are not yet defined. 2. An Exporting Process MUST NOT export Common Properties that reference themselves directly, and a Collecting Process MUST drop any Common Properties that reference themselves directly and SHOULD log the error. 3. If a given Information Element appears both in a Record and by reference to Common Properties (whether in cascaded Common Properties or not), it MUST be treated as a multiple Information Element. The order of the multiple Information Elements MUST be determined from the arrangement of the commonPropertiesId and referenced Information Elements in the Data Record, and this order MUST be preserved. Note that this third point would modify the present section 3.1.2 multiple data reduction treatment of collisions. (Also, I just realized something... if the three points above accurately describe what you're proposing, this could also be used to, somewhat inefficiently, build variable-length arrays in IPFIX...) Hmmm.... I like it. It's simple, it's useful, it's implementable, and it requires fewer changes to the document at this point. Unless I'm missing something. :) Cheers, Brian On Dec 7, 2006, at 2:35 PM, Andrew Johnson wrote: > Repeated email with correction to the example: > ipv4DestinationAddress of 192.168.0.1 -> 192.168.0.2 > > Thanks to Danny Llewallyn for pointing it out. > > Cheers > > Andrew > > -------- Original Message -------- > > Hi all > > May I propose a relatively simple solution. I think cascades of > identifiers is valid in IPFIX and useful. I also think that they > are a lot simpler than people imagine. > > > NORMAL OPTIONS > ============== > An option can be thought of as a substitution. When a Data Record > is received containing Flow information then any identifiers in > that Record can be immediately substituted for the data associated > with it. > > For example, a Data Record containing: > commonPropertiesID = 5 > ipv4SourceAddress = 192.168.0.1 > > If we have a definition of cpID 5, say ipv4DestinationAddress = > 192.168.0.2) then the collector can immediately expand that into: > ipv4DestinationAddress = 192.168.0.2 > ipv4SourceAddress = 192.168.0.1 > > If cpId 5 is withdrawn or redefined at a later date then that > does NOT redefine this expanded Record. > > If cpId 5 is not defined, the collector can hold off decoding > the Data Record for a short while before discarding it. > > CASCADING OPTIONS > ================= > If a Data Record is received which is definition then any > identifiers in that Record an be immediately substituted for > the data associated with it. For example: > commonProperties ID = 6 (scope) > commonPropertiesID = 5 > ipv4SourceAddress = 192.168.0.1 > > Can be immediately expanded into: > commonProperties ID = 6 (scope) > ipv4DestinationAddress = 192.168.0.2 > ipv4SourceAddress = 192.168.0.1 > > If cpId 5 is withdrawn or redefined at a later date then that > does NOT redefine this expanded Record. > > If cpId 5 is not defined, the collector can hold off decoding > the Data Record for a short while before discarding it. > > A circular definition will sit on the waiting queue until it > is discarded. A "collision" will immediately expand out to > contain the IE twice. Today we can send Data Records with > the same IE twice so why not. It should be noted that > ordering should be preserved. > > Andrew > > > Brian Trammell wrote: >> All, >> Agreed that common properties cascades 1. should be allowed, and >> 2. addressed explicitly in the document. >> To keep the discussion going, I'd like to propose solutions (or at >> least choices of solutions) for the points Elisa raised: >>>> duplication (as also written by Andrew) >>>> >>>> cpID A --> src addr A, src port A >>>> cpID B --> src addr A, cpID A >>>> >>>> collision >>>> >>>> cpID A --> src addr A, src port A >>>> cpID A --> src addr B, cpID A >> I can think of two possible simple ways to address these concerns: >> 1. The principles in 3.1.2 Multiple Data Reduction could be >> readily extended to handle cascades: simply disallow any sort of >> collision, of which duplication is merely a subset. >> 2. Allow collision or duplication in the cascade, but ONLY to >> allow a common property "lower" in the hierarchy to override >> values of one "higher". This makes cascades potentially much more >> useful (giving us workable inheritance) at the expense of a fair >> amount of complexity. >> I don't personally have a strong opinion in either direction. >>>> withdrawal >>>> >>>> what happens to a node in the tree if one of its children (or a >>>> node in its subtree) is a cpID and is withdrawn? Does the >>>> collecting process need to search for all the CP that are >>>> defined in terms of it and invalidate them too? >> Yes... it seems to me the only real difficulty with cascading >> common properties (indeed, with cascading _anything_ really) is >> handling withdrawal. We could of course allow any of the various >> policies for cascading withdrawal and even provide a mechanism for >> setting the common properties withdrawal cascade policy via >> options (and even allow those options to be bound to common >> properties themselves, if we were feeling particularly >> uncharitable toward CP implementors :) ) but I don't think we want >> to do that for the sake of simplicity. So I think we want to pick >> a single withdrawal cascade policy. >> There is a question to answer explicitly before doing so: When a >> common property is withdrawn or invalid, is the record referencing >> it 1. invalid (as is implied by the document currently, and by >> most of the messages in these threads) or 2. valid but simply >> missing data (as has been proposed at least once, I forget by >> whom, but not particularly deeply discussed yet). Note that if >> inheritance and overrides are available in cascades as above, this >> second case is _not_ a valid choice. >> In the first case, I would propose that 1. an Exporting Process >> SHOULD withdraw all common properties "lower" in the cascade >> before withdrawing the common properties they reference; 2. a >> Collecting Process MUST invalidate all common properties defined >> in terms of a withdrawn common property; and 3. a Collecting >> Process MUST ignore common properties withdrawals sent by an >> Exporting Process that would withdraw common properties previously >> invalidated by a cascade withdrawal as in 2. This proposal is not >> particularly simple, but I think it is as simple as it can be >> while holding to the principle of being liberal in what you accept >> and conservative in what you send, and to the IPFIX design >> requirement to minimize complexity at the EP. >> In the second case, cascade withdrawal becomes simpler: simply >> ignore the cascade. The Exporting Process MUST explicitly withdraw >> any common property that is no longer valid, regardless of whether >> it's defined in terms of others. Partially withdrawn cascades >> would then merely be partially valid. >> (For what it's worth, I personally lean toward the first case here.) >> Thoughts? >> Regards, >> Brian >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipfix > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 18:27:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsSdf-00028d-2D; Thu, 07 Dec 2006 18:26:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsSdc-00028S-Sy for ipfix@ietf.org; Thu, 07 Dec 2006 18:26:48 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsSdb-0002pT-Je for ipfix@ietf.org; Thu, 07 Dec 2006 18:26:48 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Dec 2006 00:26:45 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB7NQiv6028000; Fri, 8 Dec 2006 00:26:44 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB7NQiAJ004532; Fri, 8 Dec 2006 00:26:44 +0100 (MET) Received: from [10.61.81.117] (ams3-vpn-dhcp4470.cisco.com [10.61.81.117]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA25255; Thu, 7 Dec 2006 23:26:39 GMT Message-ID: <4578A312.3090305@cisco.com> Date: Thu, 07 Dec 2006 23:26:10 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: Brian Trammell , ipfix@ietf.org Subject: Re: [IPFIX] Cascading Common Properties References: <45786D1E.8030906@cisco.com> <658B4059-38B5-4C20-AF57-783EE3F8949E@cert.org> In-Reply-To: <658B4059-38B5-4C20-AF57-783EE3F8949E@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=301; t=1165534004; x=1166398004; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20Cascading=20Common=20Properties |Sender:=20; bh=fkuc0K4xF0AtPR1aZxblJh1LsmCRXD1EijBlR6UG79k=; b=tg8Fiv0Hli7lZIhmb+yfnaGm2fWSyQd7MW5M6WFVtNwlEZ2vlvhK4ZPQ9DM/phtHOko1G04r MimorfuNVmn+aVs9DulKAVWT0dBDrJ83uRNQp40qRdyuKzqKJXU5sKEK; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian, > 3. If a given Information Element appears both in a Record and by > reference to Common Properties Or indeed, not in the record at all but in multiple CP. I'd just say "IE ordering MUST be preserved when expanding CP." -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 18:27:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsSdf-00028d-2D; Thu, 07 Dec 2006 18:26:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsSdc-00028S-Sy for ipfix@ietf.org; Thu, 07 Dec 2006 18:26:48 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsSdb-0002pT-Je for ipfix@ietf.org; Thu, 07 Dec 2006 18:26:48 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Dec 2006 00:26:45 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB7NQiv6028000; Fri, 8 Dec 2006 00:26:44 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB7NQiAJ004532; Fri, 8 Dec 2006 00:26:44 +0100 (MET) Received: from [10.61.81.117] (ams3-vpn-dhcp4470.cisco.com [10.61.81.117]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA25255; Thu, 7 Dec 2006 23:26:39 GMT Message-ID: <4578A312.3090305@cisco.com> Date: Thu, 07 Dec 2006 23:26:10 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: Brian Trammell , ipfix@ietf.org Subject: Re: [IPFIX] Cascading Common Properties References: <45786D1E.8030906@cisco.com> <658B4059-38B5-4C20-AF57-783EE3F8949E@cert.org> In-Reply-To: <658B4059-38B5-4C20-AF57-783EE3F8949E@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=301; t=1165534004; x=1166398004; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20Cascading=20Common=20Properties |Sender:=20; bh=fkuc0K4xF0AtPR1aZxblJh1LsmCRXD1EijBlR6UG79k=; b=tg8Fiv0Hli7lZIhmb+yfnaGm2fWSyQd7MW5M6WFVtNwlEZ2vlvhK4ZPQ9DM/phtHOko1G04r MimorfuNVmn+aVs9DulKAVWT0dBDrJ83uRNQp40qRdyuKzqKJXU5sKEK; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian, > 3. If a given Information Element appears both in a Record and by > reference to Common Properties Or indeed, not in the record at all but in multiple CP. I'd just say "IE ordering MUST be preserved when expanding CP." -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 18:34:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsSk9-0006Yq-HY; Thu, 07 Dec 2006 18:33:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsSk8-0006Yk-5b for ipfix@ietf.org; Thu, 07 Dec 2006 18:33:32 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsSk6-0003xY-SI for ipfix@ietf.org; Thu, 07 Dec 2006 18:33:32 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Dec 2006 00:33:30 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB7NXTnj031291; Fri, 8 Dec 2006 00:33:29 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB7NXSAJ007941; Fri, 8 Dec 2006 00:33:28 +0100 (MET) Received: from [10.61.81.117] (ams3-vpn-dhcp4470.cisco.com [10.61.81.117]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA25799; Thu, 7 Dec 2006 23:33:28 GMT Message-ID: <4578A4AB.7020707@cisco.com> Date: Thu, 07 Dec 2006 23:32:59 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: Lutz Mark Subject: Re: [IPFIX] An advanced for Reducing Redundancy References: <3167F18F59B81B4888A4D4C0A1717DD6670F99@mhdexc02.adhel.hitachi-eu.com> <45782EF1.7090809@cisco.com> <457830BA.1030209@fokus.fraunhofer.de> In-Reply-To: <457830BA.1030209@fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=764; t=1165534409; x=1166398409; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20An=20advanced=20for=20Reducing=20Redundancy |Sender:=20; bh=M2PGHIoOfjhG6f3h6VbDoF57XLyhPGabQGcC7wL23nE=; b=K8fYKFwgKdnFqaIE/0LbCNkorqZcKon6Y6OPHJFirg3NJCqnUiOtAmVYX4FUuVyZLlxxDSFY OOZoUj9vQe8GTe7Wyy49QFRp+cIM8j+uB/yHw5UKg/a+Aog/Y7xi61xH; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "Boschi, Elisa" , ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Lutz, > If we just say "the Exporter SHOULD NOT send trees of > Common Properties" and "the Collector SHOULD discard them", > then we can leave out the discussion from the draft and > ease the implementation of the protocol. We should be careful not to prohibit things just because we don't fully understand them - because then we make life difficult for the future, when someone has a better understanding but has to work around unnecessary limitations that we've imposed. So if we decided not to proceed with this, then I would prefer not to include any text either explicitly for or against it. There are precedents for this in the existing drafts, if you read them carefully. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 07 18:34:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsSk9-0006Yq-HY; Thu, 07 Dec 2006 18:33:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsSk8-0006Yk-5b for ipfix@ietf.org; Thu, 07 Dec 2006 18:33:32 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsSk6-0003xY-SI for ipfix@ietf.org; Thu, 07 Dec 2006 18:33:32 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Dec 2006 00:33:30 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB7NXTnj031291; Fri, 8 Dec 2006 00:33:29 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB7NXSAJ007941; Fri, 8 Dec 2006 00:33:28 +0100 (MET) Received: from [10.61.81.117] (ams3-vpn-dhcp4470.cisco.com [10.61.81.117]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA25799; Thu, 7 Dec 2006 23:33:28 GMT Message-ID: <4578A4AB.7020707@cisco.com> Date: Thu, 07 Dec 2006 23:32:59 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: Lutz Mark Subject: Re: [IPFIX] An advanced for Reducing Redundancy References: <3167F18F59B81B4888A4D4C0A1717DD6670F99@mhdexc02.adhel.hitachi-eu.com> <45782EF1.7090809@cisco.com> <457830BA.1030209@fokus.fraunhofer.de> In-Reply-To: <457830BA.1030209@fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=764; t=1165534409; x=1166398409; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20An=20advanced=20for=20Reducing=20Redundancy |Sender:=20; bh=M2PGHIoOfjhG6f3h6VbDoF57XLyhPGabQGcC7wL23nE=; b=K8fYKFwgKdnFqaIE/0LbCNkorqZcKon6Y6OPHJFirg3NJCqnUiOtAmVYX4FUuVyZLlxxDSFY OOZoUj9vQe8GTe7Wyy49QFRp+cIM8j+uB/yHw5UKg/a+Aog/Y7xi61xH; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "Boschi, Elisa" , ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Lutz, > If we just say "the Exporter SHOULD NOT send trees of > Common Properties" and "the Collector SHOULD discard them", > then we can leave out the discussion from the draft and > ease the implementation of the protocol. We should be careful not to prohibit things just because we don't fully understand them - because then we make life difficult for the future, when someone has a better understanding but has to work around unnecessary limitations that we've imposed. So if we decided not to proceed with this, then I would prefer not to include any text either explicitly for or against it. There are precedents for this in the existing drafts, if you read them carefully. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From power@andreasroom.com Thu Dec 07 19:18:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsTRd-0003ej-Ca for ipfix-archive@lists.ietf.org; Thu, 07 Dec 2006 19:18:29 -0500 Received: from [67.77.34.24] (helo=host24.mesquiteweb.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsTRZ-0004gV-BY for ipfix-archive@lists.ietf.org; Thu, 07 Dec 2006 19:18:29 -0500 Received: from OLV (unknown [167.192.193.95]) by andreasroom.com with ESMTP id D604B4CEC059 for ; Thu, 7 Dec 2006 16:18:30 -0800 (GMT) Message-ID: <001201c71a5e$59e02be0$00000000@DAHAT> From: "kinder" To: ipfix-archive@lists.ietf.org Subject: October Date: Thu, 7 Dec 2006 16:18:14 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000E_01C71A1B.4BBCEBE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.9 (+) X-Scan-Signature: f4e722e9456ead69ba4cdd21dd3d3600 ------=_NextPart_000_000E_01C71A1B.4BBCEBE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C71A1B.4BBCEBE0" ------=_NextPart_001_000F_01C71A1B.4BBCEBE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mpaa, lawsuit still, pending, although recent judgement ninth circuit. = Unsereins spielchen duck nein falsch lulu. Hos engine, note, reprinting article? Meinst, gewimmwer ob eines groe jahres mutig eisi. Face paying, dollars damages labels, instigated december? Servers = utilities xi soft vid. Edit once, summer, winners skateboard selected = winning. Owner program, provides, only saphie number limited reg. Haben = april senfmssen, zur mayonaise. Fall talersie denkbaren betrag verdientps ideepps mach. Geliefert agbuechse stimmt googlen standalone fullscreen. Angeklickt = werdennaja tagoder schauen katrinps biger, wartender wolln. Groartig echt cool karen einstellen, verstehen! Kriege, nichtwas, mache euch yoshik gibts uns wrstchen stephanbo. Day = after discovery california mans body, mile. Ganze wochenende weder freitag noch. Laboratory cosponsor, none, set winters clogging full story? Tftp thumbnail player talkgoogle flash java firefox mpdoctor fd. Our sponsors contact jobsbet. Sonne orngh ah, bisl zocken gttlich, = sebastian, guter dgreetz. Puzzles multimedia, education graphic apps hobby servers. Google, zok = sehn lars ok passiert. Hobby servers utilities xi soft vid gp bearshare. = Pp risks users legally example. Kinder lasst leute sonst kriegen, tube. Wieso senfi halts nich. ------=_NextPart_001_000F_01C71A1B.4BBCEBE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Mpaa, lawsuit still, pending, although = recent=20 judgement ninth circuit. Unsereins spielchen duck nein falsch = lulu.
Hos engine, note, reprinting = article?
Meinst, gewimmwer ob eines groe jahres = mutig eisi.
Face paying, dollars damages labels, = instigated=20 december? Servers utilities xi soft vid. Edit once, summer, winners = skateboard=20 selected winning. Owner program, provides, only saphie number limited = reg. Haben=20 april senfmssen, zur mayonaise.
Fall talersie denkbaren betrag = verdientps ideepps mach.
Geliefert agbuechse stimmt googlen = standalone=20 fullscreen. Angeklickt werdennaja tagoder schauen katrinps biger, = wartender wolln.
Groartig echt cool karen einstellen, = verstehen!
Kriege, nichtwas, mache euch yoshik = gibts uns=20 wrstchen stephanbo. Day after discovery california mans body, = mile.
Ganze wochenende weder freitag = noch.
Laboratory cosponsor, none, set winters = clogging=20 full story?
Tftp thumbnail player talkgoogle flash = java firefox=20 mpdoctor fd.
Our sponsors contact jobsbet. Sonne = orngh ah, bisl=20 zocken gttlich, sebastian, guter dgreetz.
Puzzles multimedia, education graphic = apps hobby=20 servers. Google, zok sehn lars ok passiert. Hobby servers utilities xi = soft vid=20 gp bearshare. Pp risks users legally example.
Kinder lasst leute sonst kriegen, tube. = Wieso senfi=20 halts nich.
------=_NextPart_001_000F_01C71A1B.4BBCEBE0-- ------=_NextPart_000_000E_01C71A1B.4BBCEBE0 Content-Type: image/gif; name="MB.gif" Content-Transfer-Encoding: base64 Content-ID: <000d01c71a5e$59e02be0$00000000@DAHAT> R0lGODlhDAJYAofqAAAJAIwAAAByBHR3CAENfYkBgwB4g7LIusHeuZnY8DkuAGsRAHEtAKspAMIV ANcmCABNABlJAEk/AG4+DHVFDKpLCr42AOFAAABVABtuADZrDVdoAIRaCJNeC7RqCupdDQB4CiCB ADGLAGR8CX5+DZNzAsdxDtZ7AACiAyyTADWkAFukAIWjAJafDrKjAN+XCQjOAR67AEPACWPCBnHA Bay5AM22ANTEAQDgACHhAznsC1PgBHPlAKXtC7HjAOThCwAGSBYASUcASFEATX8LQJ8APMkKNdwJ SQAcOCEnND0ZMV0tTYYRMaAlPccqSt4bNgAzPxw3OE5HRWFMM446MZJKRLY2TN87PABuOytpPTpt QFVZSYVlAJlWTM1eReNVRQOBTCZzQTqHSld6O4eMTpWMPcyHRN2KMQeeRSGUPUWsN1GgQI2UTqCq SryWNtWSQAC6Sy3LSze/TFjHSYS0Q66/RrLESt+xPAPtQi7rODjXO1beO4ztQ5bmRrLeTNbtPgAA gRwNgkUOd2gAjIkAfacAcscAjewLewMijRgmc0obelYpdHIniKkSjbUsdOsfcwBHiBhKiDs3gGgx gnI3f646dL88g+tGeQBYeR5Xij5fc2paeHlrjaxogLVid9NVdA6AjiiKf0CGfmiNg4SCeqV8hs6C gNd3fQCYhS2hdzatjGyid4adhpiVjcuYd9mZiAC/eCrBdTjBdWe2joa0cq3EgL7BidW+cQDacyfq eEHYhW7ciXXmh5bYccLmgNnXdAgAwC0AxT0MyWoLtogIva4Ay78AxtsNywcbsygSuTkmx1chwoMe zaokw80Xu9YZtwBDvyY7skY4uFg7voBEzKAxxLRJs99MwQBUuBhXxkFjuVpVyoxavaZpwLdjutFs wg2MxRd5uUiEu1F1uHOIypeOzrJ2zNdzxACZziqVyzGdy1WfvHqswKapuLmpzuWlwAO5xRbDuDi2 y2m1u4rMtquztv/w4aupmIhyhPYACAn4AP/2AAwA8v8I/wT//f/7+CH5BAAVw5EALAAAAAAMAlgC Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQCH+G0q0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rVunQePKnUu3rt27ePPq3cu378u3gAMLHky4sOHDiBMrXsy4sePHkCMT9Uu5 suXLmDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tWuPkmPLnk27tu3GAnIbzS3gH+/fvH3r3g28d9Li wIkWb7qcuHHlw4cGRx78KPXm0Htff460efXs0n8L/+ceHnt58UW3j+f+/fvt9/DXuh9Pv3t08PWX zq+/P/3w+QDeN919T7kXoHYEMlXdgOS191+CDka3YITHoZdff/FlqKFXB+bnnHUSJvihf+yJ6KGA FpanoocFotigbhjaVyKLFLJI44PP1QiijjFu6OOPU3WI4X46VlgieTYmmR2BExrXo5EkfvgkfjuO yB+EWCKYY4hInocjlUCGKSZUQppIJJcKuljlmhUKN2KTQaoZ5ZQrslknnFaCx6OZMDqJ5piABmok destd+aWXUYJZp3OZXljeEuaJyOJhKpnJ6XI4XdolXh6mRyDF5oo6Ki0McRbQaeeepCqBKnKakKv vv8qkKyo/tZqbvbIWtxAtJqKK6+/AitArsEu1Cuxw96aLLKzFtvsssIia6uyCLk6LKvHvqZtR8wx 2Weih6aolIGOdououNjRmWeZiV66aI2bSvltnoqmKyqp+EbmK7TMHktrttUW+6+zASeLrbPTPitR rAjjCjC1qza8rLX8MlurwhZjbNDBHG/rcUjmygtuuWR6e2Sbmv65pKJRkfuiliXP2OGK8absp8pW JpfvzvDtW+u1BGscLUQDGxw0xgdfrCy0D0fMtMQZ72s00Px2HLXGCXM8dcFLD/3x1xuFPOd1hYLa soiS7ljko5jqPK6cepL9Nnozf5opoSyvV7Z4LiP/yvPfgAcu+OCEF14U2IgnrvjijDfuuOKGRy75 5JQr9fjlmGeu+eacd05T5aCHLvropJdu+umop6766ql77vrrsMcu++yZs2777bjnrvvuvPfu++/A By/88MQXb/zxyCev/PLMN+/885PTLv30YENv/fXYZ6/99kZR7/33rHEv/vjkl28+6uCnr/767Lfv Psjnxy8/W+/Xb39e8+evP1n39+///wAMoAAHSMACGvCACEygAhc4l/058IFbYaAEJxgRCFrwghjM oAY3yMEOevCDINwKP0bIFhIaxYR/GyE/nKJCpLQwhPN74VFk+A8aWgWFRMHhzmyYQxPysIY6DMsP /2EoOYaoECFHHEgSLTJCgzSRNEssSBKjqMQnjoSKFOQcFgUSxS1GxIpVLI0XpQjGKvKjJGPMosea osI2rhCIboyjHN/YQzr2cIZvfKEeSbjHPPLRh4C0Y1HiOEg3DqWPddShIeG4SDgeEoVyfGQbkzLH QsowkkSknBGn+MQuWrGN9vDkGQlSxlCO0pSj5OQZVcnFJrISlQd55SddKcdWrnKWqbxlJ3eZy17a EpbAJCMvf7nENKpRW2yEZCAtWcdmLiWIOFwmEO/oyGk+UpLXdGEQ8ejHSVbTkTy8pDRbKM4VDpGZ 2CwnNjMJuk2e8pW/jGcwkXjKMJpxjvespS3xGf9LNwoTlKiE5xGxWMxhwrKguhwjQoMJz2MiLpl0 RKQzv3lOaxbyhJNspCE1mlFvanOREiUkIzcKTWV2M50mlaRH0QnOSn6TndFbyELnOdN5OrGerfxn Qt8JSn/uc6fu1KUZ7znUm+KUoQYdKC7/2U+eCrWpDoUcU9T5Uqq+FI9YxegfFUlOG3Z0mx+lqEkj us1wprSaXSWrIK+6zpauta0wRR1VaTjXaCozq1qdaFu9etZmIrKParWjONe5VWeGdKvmlKZbDXtX tsaVdFYF6Rz5Sla8spSyehWrIAE71pWW1LPerOtJVcpZwRZ2r40c6WMNRxJjkvKopYyqbME22dr/ 2va2uM2tbnfL29769rfADa4+Z4tMslT0ohhdrXLHRNzmOve50I2udKdL3epa9y7LzW7zrsvd7nr3 u+ANr3gxot3yJm+86E2vetcLE/O6973wje9s2Evfxcn3vrurr373y9/+NgS/AA6wgAcsFv8a+MAI Xi+BF0y6BDv4wRCeLoMn3M4IW1gzFM5wES/M4Q57+MMgDrGIR+wXDZuYcCROsYpXvLkTuxhwLI4x 5gIgEBoXxMY1pgiObSIFkfS4IT/2SJBVMuSLFBnIGjkyQpRcvx07eSU23nGO7UFjKTMkygex8kOG zOWIMHkiR/5yQX4sZoiQ2SFlNrNAlJzmg7R5/8xeXrKbDfJmkNT5Mk0JQFH0TBQ+q4XPfu7znqUC aK9IoSiHJkqiobLorDR6KI9WSqSxkuhJI8XSVKk0VzAt6a1MOtKcLkuoBXXlgVTZ1DUOgKqzrGos r5rKrWb1q6k8ZYK4GtWwnrWpW13lWUdZ1wwJco+FvWYpGNvNxj62PZId5mUr29nKZjZBhv1saa/5 2tA+M7atPW1pJ3sg1uZ2saMNbWwvO9vUJna6wS3uc3973MJut7vJTGx0z5vez743u8n97nXD+9rv 7vax5d3lcmcGx6fO8ZMT0mtc1zrLU7byrWlN8YdHHOEKd3iwwX1ugE8bzhwvOLtD/vGOd5vkHP/v +LA/ru6Sl7zadDa3nGFeb3qnnNool7mzU85yl4985yo3+bxvTud6s1zdLQ+50YnOc5mvXOeVmTiW NW6QhD9cy7ieuq0zjnGqU3zhVo+zu7ftc6E/XeddLnizcx70sRNd21CHu9DJrpCzB73mLze73n3e bJHzHO9pzzvI4673wLN97X4vPF+comc/N34ovFb1USL/j0BHPtCQ5zXkN2+UQku+z5TvPOc5D+jP M/ofiz50pZn96EarHtFGcT3qYT/72MOe9ZqePe4hXfvd2772vEc9s4Mf++HLXveKJn7vgY/85NM+ +KxnPqidv3zZH3/6zo++9W+v/edn3/vSh7T/sXtWaoxrHeKoXjhCwG7xr9O66wy/usWxPnOUi9nw aO850/k+d7Kzue0JIXd2J3dOt3dnJ4Aed3iD53YJSHjmdmb4B4BNN4CKx3YFCHKJl4F4wXiVJ2iF JmiDlnkdCIKjN3qf94Eh+HgjaHmTV4KeB4KOR4K8l3rLR33EN37HZ4Ov932/N4O0p2k5SIM2CH23 p2i593w4iIQ/uITbJ3492HzCB3zj14NCuINReH1H0YRXWITJp4XMR4RDmHpWeIRAgnmW12pIgYYq CHqmt2eS94GYt4IjuIJomIZtCIemF4MlqHzSl2yXloTCN4Xet3qCGIVG6IfiJ4i5N3w6iIhZ/1iI hCiFrZeEQVh8WHh9gHiIigiIfoh9Ugh9lIiEOdh7lMiI0ZeIZPhpqueIiMaJivhixTNqUiGLovYV nng7MtYSd4ZmMbGLSLaAjgOLkEGLTcGIbWGMXXGLwriMzNiMzjhfuRiNMmE4xKgWZIgWrLgUmFaN jnZpbMGNUQGO0BNs5PYSvviLb3aOYEZ3KLF0ARhz/bdxFPF/RBYS6hhA7rgS91h3UCdn7diPI7GL iCcR90iPKbGPC4GQ3+MUhDiJYriJrziFEPmIOJiN4ReIFFmRD9mQSgiKhXiDPHiNq7iRIBmIQOiQ rzeSmoiSKomKGbmKLhl+LUmKH6l7HCmTGP+JiqCGiNtXk6dojKZoiNslj/2XdA2ocjbHgAPZdBVY lMXGlBL4gArocngXlTSnfww4dHMGcEbplECXlYi3dBQIc2A5ZmJZeF1ZZBGIc/B4lGOpkJjDkEP4 hV54hDTIaan4hFbojRe5hFmIfHlpeykZknp5kTvohVSIk3OZl6MIhsq3l5Dpg2E4iIopmXxYl1+o g5UJhc/zi/HYb6yHbnBXc/m2f3OndqXJjkjZb3O2cvgWcCR3gKqJluG2mt/2ZWm5d4LHlQR3gW5p gKK5gGvZlKeJlVnJf8MJl7STj8bZj0anlvCogUy5lL/5mWNHgDHnmkwHnRaYgGu3lWWZeBL/aHdb 6XdjmXf3h5zGSYHq2Z0FmJwFlI+5qXZ/Z3LUWZxPKZ/v+XNM9pxlJ5XbKZy6eZa4qYDxFp3riaAT aJ/syZ4LmnMDh5WliX8RCp4V+pvceT8BN6HVtqEbWp8GV3TZhmxPB5sC93IXmppiaaIgSncZapt8 x5r+WJblxmb59ppLxqEd6prchqPA2KMRiprkOaLjdpwn6qNE+qLT84xMqiHS+KRQGqVSOqVUWqUI 1KRYCmB4eRXi+JdrEWpb+oSZdjtdCjqneHqBsojayKVacY1kAaZ8qYyZGafdaBVlaot2WhWfJjit Z6Z8KKaz2KbfyBRhCn5oeqd/Go6EUaZd/7qngWNpQOmIKQmRPmmRQkiTd7l6mjiDPkl9J9mJnSqp PCmUnEqSNrmRi8iTo7qqlLqSGXmqIYmMPmipxteqFKmThhipEmmRJYmpf8mqMVmrEpmTJtmnorqr kAiqNXkbRNme/peb70iVUxlt2MmW+GmfLuqOV6l0yAaV1tqg8citXGmgZaeWVemg4uqV25p/2bqg 9Bmt2JqBSPegCLiupwmt9CiemBGaxAmBCQqvsTmeAOqU4qmd51quCdqf/3meb8eP8DmV0yl46Fqd u0mj3uqbNFpmBoux/SqxCYuw01qe/9kZ6Xab/Mqwcdeb2gmcABqaBXudARqxSudtM2qbKP97d0V3 mwnrsiBLrxQLsaZZsipKllzmsiebkDAbnM6qtK95oRa7n6YZtKMxpP83nPwHZyv7rvH6rz0nmwK7 tAD5sNVJnmJrpNLps0/7s6o5pP6IgMAIkAGLnUubr22ZtlZLt1BpF8UomFxIhFr4kWLIl5/Ig58Y uI3ZqzXYmJgJqX2biVA4rH3qhIvbuJGrmdVnhL9qqIwJflX4mH1bg3M6uH3puaOopl1IuYWJhV56 uLYBZEC6o/jqtEVqkEVLlthao7oprX93owKapDWLbxlboT6qsyf7uvFGtTobs8nLtSd6cywaotBL pNK7cwrrdCx6tAJXtL7rvGSLojcaZiX/yznK+Trf+TjjO76eIxiISjxyqjrra6juJavc077P877B Y6X4+xFZur/827/Ew2O6WBM2mo4f8bxwG8AIbBIKKZDfw5zyiL5IG5UccY7li44bkWYQnBEZbMEW cWfp2ayeWcAl5mmUlqhvasJuQb+dZmh7axj2G6ihi6ZPUahrqqhi8cKFsXEeSq3CC5pDa7LHO69f 2aIQ6G2pOb3iuq5Iyq/7Fr7/5n8hysRN/MT7xptTPK5fKW++u8M/3LJAx2+wC2/+5sAQGsVa/G8q G8ZYq8b+Jr0+vMEuUYx36ZecObqgeLrZp6l06alg+Ior3IpOmLigy5nYh5nVN8eTSbh8/+zHP6jH kdlpEcm5eEyKgQyTf5qqkwyngWuZMTzIkzjJdInInArKY4jCtdGs4HqUubu2LHu7XXu7bluzA6tt Jcq8rPyuN/ui1dq7uwmt9Qe0BEvEq9x29KmxUquvUju3Alq2VDvCNczJdhnK8suYP8nHfFvKnvyS Xjq4l7p7h9uQGjmqhGzHqmuJnlusvTqStNqJn7uTotzNhhmUhtnJ3NzONay43Cerk9uFP8nIo2LI omzK2eyoonu62ByYltuRguym33zJdGrIlrulAL3IzzzOrOu31mzRfnmJhCrP0HzPkgzK26zRIv17 OEwYqNzK3XuxHevKtOuxMjvEswzFTf+polDrojWtyw4YnvxZn2frtAeYoWcplRRKy7q70xja0wrK rmrLzDU9sPvqvdo7vAYMm0vcokfNoAUruy7dgEvM1UF8xTjLvUX5oTl7gcnrn0g8uwYI1rwrzEy8 vFb9oAgrpBKcn9drvHU7vFJdxSMHxyvxXicdG7Rov4MNv7Zx2P77x/lCjO+r2AItG5C92Jv6N44t qJSd2ZrNFPnb2WGz2aB9OrK4jZiNjcsa2rYDFG12n/y41COrZuAJwkaWZJ7tMavt2q2Ngf/IiwBc 2zih1lpcmzw8wOVovOYKxFcsbkZLmlWblKuJxqw5cMqtb1TsvdnJxiZam7EJvL7tEC3/XLiIPcrn HNGZu5iBnJluSskYfcmObJmmK96OaZOkXN6hPN/obc+MPNmLjWRZ+9o/q9PBzNIva53A+cGwrK7N Wa+2bKTuWrE3nbbdzRByOZjF6s6O63vkjc4NHc/ibNIbvazwTJOKvJcDnc+Wmogj/ci3GJkOidrW CJimDNGCe7n2TcfjPKeBWbkZLZLxTeKbW9JiquMqnuKbGd4uLhW87crXCtQ9y29//XMVG9TOidZK PtNKecu6nZ8L7rUNHrU5PaAHHOGeWbsDfJzBLbxsjbtnTdYHapa4fMTAXaQPKKMnR7x9HZ02zb3a m71VTLa2K+ZxAdiArkaOod9Hfugm/4noir7ojG45g/7okB7p/9XolF7plm4Ykp7p9nDpnG4Vmv7p oA7onT7qSB7qpn7qqJ7qKkbqrN7qrn4Vqh7rsr5ir17rtn7ruJ7rkzHrvN7rHabrr+7rwj7sxF7s sgXsrm7sUorszN7szv7s0B7t0j7tMKTs1n7tD0Z/EKHtEncS2i4R314S4Z4QACAR5a4SAJDuC3Hu E8HuouHuKQHvDSHvP3F5YfcQvNZ+7ndjIJHvERd/DiFlAm8R51d1BUHvBy8QCK8QC58R9N7wBAHx DG8QEj8Q7H7uDX/xLSHvGI/uCv8QFb8T6ofvW8ftBu8R7LcRA791GGHyEdHxLy8SD//vECF/EDVv 8xQ/8Tdx8x3B8/bg8zbxZLGWasBWcSXvaxcXaw2Xa67ma0WPdbc29F839P5u9Fb/a07f9Oan9FIv ZRiv7gef7uou9hZP9jn/82Zf7mAv9mtv9mj/9WCv8GTP9mWf9mmP9nIf9xz/829f93mv9m8f93xP 93Df8W5v8X0/+IX/8Yxf+Iaf+IG/921f9xdP93wf+H+P+HbhZObH8l4Ha1mXcekHf+/X+fO3fgrX dffO71fP70I/+qFv9f8e8Zdf+5qv97a/9wmP+4jv7oDf+Dif+8Lv+3gf/JKv8Rpf+zBP/Mo//Mlf 9r3//IN/+8Kv+L1P+2Ev9x9P/Mz///sIAfM3ARUs6IEhKIMyCIdz2IHjv3ksGIfmD4Pp/4JKgYKZ R3ntL3rwn/75TxQA8A/9DxD/BA4cCECgwYL/EB4kyLChwYUKCUKcKPFhQ4cRKSbUaBGjxYgMO4b0 iNBkxZIeJXZEKbIlyJQsN7pMeNHhyooyVWI8+dHnT6BBhQ79F4Cg0YFGAyxl2hCp06MCkSqN+rQo 06VFo161KtXnVK1JvXblmjWs2Kpbm54NC1YqVq8oAcz92FPkXLw8D+KdqRIiX5N0b8oF7Fdh4ZCF d+KsmfdmT500Je8c+fLkwr6Xc758zBGx3MWKSRIlXRqjPdSpVa8OoLp16tavV8Oe/21Ptm3Ur2O7 xk2bNW/gvmfr7p3b+O3ivZEvT878NnHlwJEDWE29Omrr2O1lr73de2rq3MV/726dO3jt19GfJ9/e /Ozwqs+/T0+//nr57tVrH4/ee/b4/AuQv/z2A7C99O6br0D2unPwQQgjlFC45ir8jbbnjMNNtqUs PI43DoeT7kPfdguuw+RSNJHEDUeMLjfo8EtQwPz6qxG8AcmbS78DEbxPxu1yFBLHGQkE0j76AESS xwL9M3LGHp/c8b8bsWMvyiGVfDLBKRuc8Esww6QwQ9uY6g4rDTWEzswVYUSRTDNrQ1NNC3WLk800 81QuzjLt5JPD2DqMsb4p4Sv0O/++ajNvxxyDDDBRK8VbMFIlH8WryEvtAxLRQxklMtNPKYWyOkjn u9RJTh/Vz1EfsRQ1UkRfBdVHMWu19VZcc9V1V14lRK5XYG/1Mlhii+11WGPLS3ZZZpt19llofY12 WmSntdbYap/N9lpuu/X2W2B/BTdXSMc1d9dtsT31XHbbdfddeOOVd156643QNHzz1Xdffvv191+A AxZ4YIILNvhghBMm2F6GG3b4YYgjljjg0fa1azCLFa4rqIoxXkxjkENWuOPQRLZJKMdMVjlhW6+E T1hM0S2S2Wob1HRmXG2k9eUw003WZ5h5dnk/miUEWuJnKdZL34s/xpfkg6EmmST/qE1jyeONrV6Z s4KnXnrlqp3eemyAjV530XVFLVe+s2M++9TwCgWM0C7hZvU/ud9OW+27Y3XU07q77FvRI19lO9MB TWV0b8NLhdvuxw/9mz/BZ0407h7RlpxKxjHHMW/QN3dc8lJv3BzpaN/T+UecaURQ7pdh76/R62Q/ cLzVTXU9yyjxRtVAHVdl0FX1Vq+daB4zhzDuwpu0cnfh1+s9yE2zdH7VobdkHvVgtWbM44u9hsky vSprTOzv08/MMM4iW/9q9YHSbHzwMe7r/Jp8uj+xzfD/af302Q808bsI/Axjvsnwz3/5i1/YyPbA //ElgUsz4GEc0zSZSBCBMKGa/wb7dxcPMpAyA3zfRD4jwgJyZC8StAn/RhM+noRQhIAB4AtlyMGv DQYy7PvgCD2jwRMKcIE6PCAEjei9jPBwgQpMog8nuMH5MbCEKjyZE4mIQyrWD4Uf3IjUBPjCK0rR iiUbYhHPR7Uq7rCCABQjGtP4RjI+8Yhz/EeEtESl5xXvene8Ge5CdSTVGch61dPRpFCVpEJGb0i0 SpzfLPdIwkUvkYYc1ex4Rj0b2YxoiLxjlWJGSD/m8ZCQlBLtuOesWaGNkZizmaccOSpWLTKVsgLc 6EL3uVbN6keqbFTpXHdJKDEOVshj2+QMZanAaY5SkiJVfDJZHl36jZex2+Pwbv8Jqyu17ZiVwuMp e0VHcHLNgeEEGwTHSZpzklOd6yyYN4tGTHcG62jYkmc87XlPfH4pe/k81rjmuTx+BrRd7CRoQQ16 UIQmVKEGE2hDHfpQiEZUohOlaEUtms+FZtRigjloOjX6UZCG9CP0jCRJrzW9oOmxW8Pa50Vd+tLZ mMyjHSWY+LbWsZmKVKc7TajZQIdLuqkNctdcG35q2TjB6a1SrOymMrdpOMotzmVKpZys7nY52B2P qsb0HfWgClOwxrORylNe7G63SbMSqZLSA+Ulx1rNXzKIS6T6XVeTB73W2bWXw8vjIsP611Pu9Xjw HOQoBwvLLTFpU3PFY+7kKrT/vBrPr92UptEUa1hXGQ+wm63X3PqmTW3+rbDLnKrzaDhM3M0te4EU LSVvxrrOWdOVpMUeUJUVSsw6iZWn42xv3+XYx+JVe68DqM6QNVpSsva4wWXuJ4cr2ebujLKChe1i fXtdeWnprAoS7mwpK8npmjZ4uP1u8Bjr3Fd2F63aFa8lzUs48tZ2ru7Fbn2dNZS8BAYzHNWvCS1I QBayMIUzTNkFBXzgAs9EIykzIX+zdpj/PgTBFEnMBVtCFwaXjzCCOXD+9IsZnoZYxCM2Yk7JaWIS p1jFKx4IYP8JrxfbV8bYZfHTeIriGudYxzvmcY99/GMgq3PGQyZykb0ZZCQn/1nJS2Zyk538ZChH WcpTpnKVRWpkLGdZy/Kycpe9/GUdb1nMYyZzmc18ZjRHDMxrZnObQZpmOMdZzg9yc53tfGc851nP ewbynP38Z0AHWtCDljGfDX1oRPOL0ItmdKMd/WhIR1rSk6Z0pS19aUxnWtOb5nSnPf1pUIda1KMm tZETfWpUp1rVq2Z1q139alh3udSzpjWvYn1rXEu51rvmda99/WtgB1vYwyZ2sSeUa2QnO8nGZnaz RbnSGI+LH/yA1rRXY21+Yrs72lYNt519rtM+m1u8tZe3k+Vtc9sz3dZeN7W/PS2U7Xcv5sRxDAXG UYxM2yf6Hgi/9eVvgQCcxP8CbwjB/2HwgCFc2RqzIzPJDa2H1yriPRtWuu3BbYtPCN3uzjbHa9Pu ZWX83dAs5jU/FzpJRTzcXKVhypOZzOXZcnPTpjm2a35znNP82h6/OM9t7u6f9xw1QQ+60D9e824j 3ehD57jSU6P0nDN96Thnus6PfvOka5vqI4+3fzkcmILIm79gh7D+5F32r5997PMOO9vrovaO0bzf /Ag43ec+d7sDXOB7z3vf635wvwNe8IM3uL/5bXi66z3wiP+73Buf+MALnvH5nvzh7T74haus4Wpd XDEN5VXPi/vZnf8UMz8P+k5tq24OwjjQPa711/N857MXOtLZTW3b4173tz//eoSKXnSpm7v1tdd9 0pfO+tgfH/gjt0e8EWxBxUA/7Q2Ovn/bjm8MLzjsAd4vDSPI/Z8o/u93H3/5KV/wywMe53i/Oftr Hn6Cr5/wfV9//NOvb/xDniCWT//5757zyMs8OsK366uYtds+t5Mf7cO+v7C+AzzArmM7Aty/+wvA yTM/9MtA93M89Wu/upM/+Lu8C3w/DCxB8cs/zEtBDtTAx9u3/hNAhos5RdkeulKrklM9h8vBG/S8 vDEbHqy45FO+pgvC3jO+p/u5IXS9JKw6CeG9IzxC2CtCIwy+4hs+2rtC4ts22fu2CJQwt8s+BHzA s7O3CPu6BATDFTrDMbS+/zKMuwo0vxF8Qwy0vzkMwPnTQMZDPDkkvzuUvDdEwfnTv/KzPAocRDuE QYXZvNMTrZOLnNQTpkZcKhv0qpY7uWVykEr8KiGEQiWMuincuNlYPqMDxeObOqfzRKnbOaurOtcz PifsOahzulEkQqzjROZDRKJQOBYsQVzsxbIZNZF7wilkPknzxaDQRWNMxpAhRmZsRmd8RrBSRmmc RnACEzIxFnHBRhS5kFvJxmDhky8RF3CExjQjDbcgC4FBR4xwi3xBR3bUF3UMinf8iXgUCrKoR2rM R3tEC3zsl37cinb8iHnEl3+kx6EoSIFcR31cSIKYED8RlG2ckxMpkTvpE//YiMg+CZRtdI07AUes 0MiL3MiQ3I0/qcg3ycgQ4UiP3JCIlEg30UjiEElyhDM4CZFrTBObBJGcpJMX0RM4kRMYwZDg8MmU 1EkXKcoSMUoWSZGeZMmZHLODVIu0QIu0oAq2sMqxUMi2AMi4iAt37EqtsIquGEuuzEqpNEuouEq1 FEutZEuEZMhYk5akxJCPFBGSfElBkQ6M3BOXrBOgrJCPZI6hfMg26cnC5MmlbJNfGZTDfEqadJGl BMq7ZMqbfJFBEZG5vJAM8UYVARHPhMzGZEzAHErEbBHH3LKo5MepBEuqfAq3XM1zBEuyVM22XE22 uM3XfAvclM2v6MqsyM3/q6hNsXhLuMRFsTQLr1wLrbzKtfjIpEBO11QK5TwK5VTH6ZyK6XzO31SL 7ZzN4LzN1uxO7sTK8DQL4ixOGDxPQ1NP9GzPoQjHRuPM0/S00mBPPLNP98xPn5hP/uxP//zPa9FP AR3QoIgQ+XTIazlQA2WWy1xQuVTQboQQzlxMW4FQAB0XC32QBl2WDD2TXfHGDdVQBGXKcJHQv6TQ Cr3QeulQD7UWFsXMZAlRB4FQGf1QE51RGK2VF1XRaAHJlzyOlqzIjPxRlozJIAWUcRzSIh3JxTzS kVSTP2GRJs3LktzLhwRSJH2TKpVJNPFRy+zSMiFSLyVRHoUWe3RNhYRO/7UMS6CQzuFEU+AEz6qA 07Kk0+FcTtrESu/UTdbcSjZ90zsNVLTcTerM07VEU0DlTQIdMQfVE9NMzMj8jc38TEjF0UmlkM4U Sm6cy5jMUQ/h1NHUVEitTMHkScX81FPF1DI1U3kcz+0U1K28R7iIU+mc1bIsC/LM1XU0T9tMzub0 SvDcU+z81bB0TlrFVV2t07PU1eO0VaqU00VlsWM91j99Vmbt1TW11rW8VVglz0GNzWp91m011Hu0 TW/NVtZky1g1VzxV12jlqUZ91LwU1ZMs1XkdVUoVSUAJ1TCdyEvN1zVR1UyV0oD9V3k91X0lzZ88 WFRtWDJdVW6pycmEUv8TuVKLhEnCfFI3oUwq1cvD3FKN9RPLFNghldiRVVKTtdiLHQ48AdWVXQ4h xUmShdhiUadyzTH8JJicXZmdfddqfBcUFagdjVGHGVqavaegDSij7ZW+pJelPVqojdos81mqzU+p vVqLqlqtLU6s7VqJ2lqwDVuxHdtV81qzdSiyTVu1XVu2tbKzfVt+alu5nVu6rVu7vVu8LQ243Vu+ 7VtLy1vANTS/HVzCLVxAC1zEzTPDXdx6SVzHfVzIjVzJnVxUY1zLjRfKzdwou1zOHSjN/Vwm61zR HV3SvSjQPV3UTV2yLV3WbV3XfV3YnTEqy4eVyQfb/QjaHRvbzV2V4d3/oPDdj6o3ZYyQfFCN4k2N 4/2W5CWW5e2V5l2N5zXe2YjeYqFeaLFe6NWnyvmW11KWwCopilpe8R0X7M2V8rUV7E3f6X2W82WW 9rWH9z0vb+le8EUaTYrb3x0I2uXd3N1d4BUI/wXgf7jdAd5d3DXgAdbfAjZgAg5gAW5g/kXgBOZf jPDf/S1gAEbgAHZgCyaI/m2IDZZgBRbgBf7gEdZfBtZgDPbgEeZgFt5f4IXhCCbgCV5g+VkhFyI7 6Nu+yxi7DsovH/6wC8PhMOLhuyDiAgrizhCwHWbiK8qwn32Q5C3eKYZf6XUQKq5i5M3eLbZiLbbd LkaN4wVj+B1jK+5i/yoOYzGWXjJe3zMe3ze+4uc1YzU+Yy9m4yuWYzaO3ioeXz/m4z7W4za2XpSi RNZ6JNmpq0VR5OS6LOnSqz3aLu7CGU1xrfdyl6H4YBP23f99YRY+YRIm4QsW5U8m5VAeZVNGZVBW ZRA25VT+5P814VBWYFmuYVB2ZVvG3QTe5Qf2ZF2mZVjmZWE+GTBaYnEyI/0p4iYaMCi6YfhhIgBL CQpqnx4CKVQeZQuO5Q324A7mZgcW5lrO5lOm5W7W5Ar2ZRRW4RJu4FmuZVyO5V3mZHA+53nu5F6u Z3RuZXJ2YXlOZqwBMRAysPzasKzJIAvTMGQOjRvyPvJhaCVaIjiCYv86kpA0XmM67g4/zuPa4GM7 vmg7zuNAduOK1uiR/mg65miTXmMuhmM8TmmWRuOW3ug43uKMlmmalumXBh63si7yoiTWCS9GeqXJ cuTlsq6miiTgQi/PzV8KDmd9xuB+nuV5zmWnbuETVmVZ7uQInuoVruqsdud4LuVSluet1meyBgoK BuYMHuZVnmqslmppJuYs+h4M46JpziIO82dkJkCxI5+GBg2AbiFqnrfA1qgY9matvl1W/mbEHucM jmEJTut4juxbTudcfmxeVmzKxmywhmoRFutvZmB6LmG4Bu3IVmy2bufHburQlrA1jGshTsMamsA0 bIy6TkAdSrD7+a///YFig7aL14YwJ5bt2kZPexZrcjpuhFHug2HuGhNe1eUX507tOZpugrHu60Yy 6I7ufTluxk7u2t0a7Cax7a7c2D1v9E5v9V5v34o2fQq1F3PvhpPvzaJv+n6XrgEYA0QfrtFrPGs5 /v4fhCnvAfdvcBJeNwqpYrnvorajCbnvv9Isy/oZ1IFwYrFvYJoY5+vh7ptA7strgUZDCsvrH/oL Dwdi2g6wzTjxtAMxMzzistvhlUjxEEdAJOaYnFDiGQduuZZxAwIiEGei2F4j3bZxkGhxH48wH/dt tLMw3UbyGb/x6mtiiVZxFaLtAYxxNhIiGB8f7NNy9oEhwZ6hHmrA/xwKc7JL8yiKci7fGBfv7zQq 7C7voq+ZIi0aiWJuIDiXDAXj838Gc2iusDZ687k284R2ox8v8xg3mZ4hauTp6Z8OL/eCLkmCdC+x 5PdakueCq9tCK4AyLE/inE53dJVKrCqBdEwkrsOqK0n3dFBv9bYaJUpPalgP0A238zFqZvqRI/xx aIj+67ke7GUG6MDGdWjG4f6Svqp5ZmQ/IJza9S1f5gDqH12nvmRX8mvvcFxX9jhfaGdf6CAio0Qv 9AA/GAePdaVG9T4idfqNK0uOr9+hr7Iar1D3acc6GuNydFNqrHqHLKM2ElR/dVWflEp25Eem9E13 dYEX6vUKdXjDcf/C5qJj13UM2usdQiExb6PrM/DIkOZiP/QqKok+7/gcQqDbpon9JqLghiGbMnkh H/kz6vWND/ZxV3mJB3m8RnRhp+vdHsC6NmiFhvKryTAT92GRl3F7G26kH2icqvHOGHbbJnHwEegj 7/AtKuL+svM8X/qT97CD9u8JC/qqN/JrF+6f37DYbp+vH/shd+3u+5jso3Gj73nuXjECJ4q7H1v2 fhALf2+prXuVyXuUQd29L3zDP3zET/yI6vtlYXx48t7Hvx74Pp1/gsQM5xXLfyifbvSDJxdKPvcJ 5/uc8fvIZ/Vx+/zvxXykFhN8zyvWB6vNlzjRlxnZf/B3Cn3Jv3z/cHF8fLrfeWr9eoIpgtebqJIe qUKpchEmprKmbWIeS0J+vNH05Meeocqc2NoqY/KloNLE6B/+VkoqyrcbAhkqpOImulGd8Ie5Rvys zkEckwskpcom9Q+owVd0Fyf2P0efPh/zARP3wgYIAP/+CRQ40ODAgwQRFkyI0KHChw8jMoyYkODF hRAlYsx4seHGkBAzGpxoUaHHjRU/ssRYsiKAlSddjgRJcSTOjiZ1wmzZkiNHnRpndsxZMiXSpEqX Mm3q1GnMqDGL0vQplGpNpTZTHvW41SvKsFe/Ej2606zVsmqtbiXLEijJtFfj7uRKdWJQkHCNYjXZ 9m7crGABB/35/9Zw1bV8sT5t7PgxZKR4AS/sitKyVMsOpR6cOvhsZ9CULxMVSZoh58Q8o1IumDkw Rc5+Zf/0nNmv2JqeSdLOWZl12L2hgQOvbFr1ZMGBgb5e/vr26cO+80aubv0608mF13alzha28rS4 R49ljPwkdeHnVQ8u3Vd6breIwb8/npyu2L9Jk//d3touYUtpllt09oE3IHYJKuiRPQ06+GCDAEAo oYQOUmihPRVGuGGGHGZYoYYextShhxiSOOGJIXIYooYjpgghhiyamCKINNooY4c4zpjjgxf2aKGP H76oo4kqbtgiihEGeWKJNdYY449QHlkkk0uqiKORJMpI5Io/Yv85pZRCRtkljGWaeSaaaaq55pnZ ObcbcakVNRVrCNYZGoBD6VZXcXhiJtloEtF52aDGuVbcS7tthiijthV6p3HD5anoalwN6t9vwf02 oJyN7qnZbHBKpmiiomUqaYGEktXpgq26+ip9sMpaXV2z2norrq3WmiuvvZrnK7BMsTnsmMQaeyyy w2aZLLPNOvsstNGWuay01Vp7bYnYarvtttRy+y2a3oI7LrnlKmsuuuVKlS67xAb7LrzxyjsvvfXa ey++KbW7L7/9+vsvwAELPDDBBRt8MMIJK7www+jmu6tcs94HGcSAClhvxflG/FTGGrtpXccENhby vQOLuyPK0V7/ieyTxp58MstRsQlztTSvafO0KmfbLs45n3tsyw0/DFWvE3Ms8sdavYppnh5fTKur JEt8HclSk+Z0UjfL/KGLOYLo5NddZ6ak2C5SKLbXWa6bNpBbx2i2mGuP7bbccb+YZN0ruu0zjGtz 3XXbYYOtdtxInk12izJ/+XeTZIe5MpR0M+73jmFPu/XZie995NeBi4h431xzDvrfmXvutePsJp1f Z627xGeAprmWlaj76anfZiot9pKBpM4JlnC4t/edf7vOTqCjp8E+MVq90z7dWyt1Jx58xt9Onuu2 AX91fDDJNFZPumsarJqQkznkmVZWyeT6PKbsJfwob1nsk/OH/9kl4V8GTS3h95ufM5fupiX2xa9y YDqg+6K0pMYtbn9JQmC41hdAJO3sQhTMlv0aN0D/te9g/2uZ4Sa0ri2NTXTtU58IFVdA9mXwhAyc G94ImMABCg5wD1QhB4uFOBSOiYILhCH9EIhCyc2QgQrUG+VOaMMdSlCHAqyhmHb4wQ5ukIQjTKHB pvhEKqrPW0OkYhNzaEAi1W+FGISgEMFEs5W18H9hrOCMnBRELXZRh2U0UhvJ5EU7PnCGPIwjB4O0 RzFW0YwyPGS/6AhIHY0ocW/8IpccmUEb5pFKbyziBVHESAPKMI+O5KOSwLhFPwKJhaUkpSQt2clS NlCDcRTkDf/rGMobPs5HDpxjEDeYxk2mqympYZWm8PKoYcJJe7ST00cuVZuvNEeYpPLdqe4Du1Pl B1GjilMxV4XN9fhEen0hZqLAl81Kjc8rylQOnfq0KHLypiF5KVQ395SYUpmTOO0U1DuNuc53Nexn /SRWz/4pUL4NtKAGPShBERo6hTI0fQ19KEQVFtCGTTSiCauoRTN6LaxxtKMe/ShIQyrSkZK0pCY9 KUpTqtLGaLSlLn0pTGMqUYBhlGXN4p+0aootjOpUXTL9qbRgVbFpUg1psrLafHxztFjNy2oIwhVS kbrSqY5Uqr9yzFOnBjWLPWY893KqUbWKVaqStV5agxvdkmj/Qi2ZTXGYKxweR1i2uZ6uh5Gbq9ry VsK3aU5wdjUd6S4YV7x6DrAphGJa0Wo+v6ZOroplIuMECNTJlmmsoire867GHJyM57LVw55MjsdN 1o32et5BjGdlBz2lMvN7/zFt9CYVu/KID3vzLCtuMTbb+sAnPML7TG+ZKRd3zqW06aGegRhjE/Wg ZVXD5S10p+c8QIFKuazbTmevmtvtSqw3itknO0sFTzwBN7nYVCdN9BLcA313t3bC7n+Ie09HQWox u7vuc2wn3nCqqr6t+aV2uSvgp5RvhX+M4REJuCw8GlF+iJySLQ3cRzk6OIcMziQki6hgM0YywS3c mZQGGTRX/5JSw5Q9sT2SNt7lSnMm0lVMdqdb2nIyFzbaQw17TyuYGpeTeLljHnuL2x+lXXfH620d jkk74CXr6pyqUm7t+pROfZK3nstEDZaJ+j16Wrk74/3vM+OZz8LwyVP0xBQypYwq6y0Ky8mMZjsr tWUm07kpKL4znhfKr57m+aB1/jOgI2PVBQ060LjtM6JPzGdnLTrRjn40pCMt6ZgautKWvjSmOzrp TXO6057+NKhDLWqIZrrUpj41qlOt6lWzutX8HDWsYy3rf7q61ra+9aVnretd8xpguP41sIN96F4T u9jGPjayk63sZTO72c5+NrSjLe1yCbva1r42trOt7W1zu//b3v42uIU17XGT+9PhPje6062UcrO7 3e5+N7zj3S9107ve55Y3vvOt733zu9/+/jfAD2bvgRM82wE/OMJ9XfCFM/zWCX84xB3W8IlTvOIW vzjG5RXxjXO84x7/OMhDLnKDZrzkJj85ylOO8pGzvOUQUjnMYw5Sl9O85ja/ecRlrvOd5wvnPv85 0IM+bp4TvejwEjrS+230pTO96U5/+keTLvV8Q73qVnfM1LMO76tzvetI0TrYwy72sb/U62Y3O9nT 3uyzs/3qan97stsu96fDve7Fnjvel273vfO9736vVt4Dz/O/E77whj+8gwSv+MUzvvHYRjzkHW2v TVDeMZT/34SAL1/5pVz+Op3n6Oc9GnqnjJ7raro8hFAfLdWnXvOUdxDrnRX7Ms1+W7WH/esbdHti 7d5aqu996zexJtcDn02af9DvX198GC3/9sfHvfBPn3vdT3/Zs1/+sJyf++RH/1nFxz60es968J+J /M3ivvGrX/7pPz9Zroc+9YVvfns0X/3xZ7/9aV/9+cf6+vl3f/6Nn/L9H0OJH/51HwAiILmAH/b5 nwLyXvvV3vzxH/JFIAEGX/z1GlOUXui5XkYQ30UQH+Z5RAdWngiO4OeloAcORAm2YEKA4D+coFKs YAzS4AueIAyyoOYlhQze4OjBoAiGoAkCIQ2WHlIYYefl/+AMrqAKYl4StuDm6eAI1uAOSmFKEOEU ct7m/aANBqEUNmEXViEVWqFHSZ8Cop8Awh/9bV8AHuAasmH0EV8GvuEcJl8ddh/qPd/u5aEbmokA wmEG7iH60eEg8uEA4iEg4p4aNqD9GeIDrp/8xSEgGiL8/SH1LWIbRuIcmuEm9mEhImIkJiIlvuH7 KRQOHqIaYqAlMp8brqIc0iErhqL+PeIowiIG3uEjdmIr9uEtEuIuPqArJuIsbiKaSCAqZh8qomEp 2uIg3qL2ySL5sSEkMmMmUqMs4iIFqo4WZuEYuuAXPuEUGuEYjqM3YiEXOmEUCmE4gqA3fmAUNiEP vqM8ov/jOnIjGXbjPFJhO8LjOPpgFYojCaajFQLkEW4hPQ6kGPYjP+rjQqqjDvbjBtogQw5hPfoj OPqgQhpkQnIUJ1ZgKL6iMoLiLFqgSN6fR+rhMTrjJPKiR2JiLlpjJZ7gMAaiJ8phMEoiAn7iS7ak Kl5gLN7fSsbeTeIiMbpkNC4jLNaiTsLkTWYjwTigLfKkL5ZkL0rlH9JiSA6jJa5iLzbjT+riNabJ VrIkKcJkUvKiV05j6xWlWB5gUHJlVhLlV5LiTsZiTv5iTIrkWFJl+5mi+tWiVabkM86kNeZiXPak XpIlWLJlKu7l8OElWyqlKKKlMBbjX1ZmR9IlTZbiUA7/5VwipRneZWKOZl6WJljWpcBEJDcuJEV+ IUIK5D065D2eIxnyo0aS40XGpkO2Y0BWZG3K4xXmIz6i4G2y5m3+5nHqY2/6I0a6oz1C5D+2ZnQe 5Gu6JkQ2p3Vep3NmIRi+JnXuYDm2JnNOFQfOIxSKoRc6Z3D65nXm4Hk2pwzy5nZyJ2yqYxGaZ31m ZD2moznS5jdOZHKKYw9iJ4ES6HTipkbyZ4Ie6HKOp3a6Y2/eJxMG4T5uZA2KlEs5Za9paPqhZrlx 6MGB6K6JqGV6aLRhZp9xF0Ha24omSIsWnBKaWuTNaJ45no1eHI3m6IndKI/2qI/+6IDpqJAOKZEW qZEejSmSJmmiASmTNqmTPimURqncKSmVVqmVXimWZqmWbqmxSKmXfimYhul1cCmZlqmZLqmYpqma rimbtqmbvimcxqmczimd1qmd3ime5qme7imf9qmfRumZBqqgDqpL/amhRh2hJqqiLiqjNiqKHSqk Yo2jTiqlVqqlXiqmZqqmbupDRaqnfiqohqqoZlxAAAA7 ------=_NextPart_000_000E_01C71A1B.4BBCEBE0-- From ipfix-bounces@ietf.org Fri Dec 08 04:30:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsc2e-0006ww-DI; Fri, 08 Dec 2006 04:29:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsc2d-0006wq-IZ for ipfix@ietf.org; Fri, 08 Dec 2006 04:29:15 -0500 Received: from gatekeeper.hitachi-eu.com ([194.36.128.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsc2X-00052z-Se for ipfix@ietf.org; Fri, 08 Dec 2006 04:29:15 -0500 X-ASG-Debug-ID: 1165570138-56c9002f0000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: primary.hitachi-eu.net[193.39.225.234] X-Barracuda-Start-Time: 1165570138 X-ASG-Whitelist: Client Received: from mhd-esafe-int.hitachi-eu.com (primary.hitachi-eu.net [193.39.225.234]) by gatekeeper.hitachi-eu.com (Spam Firewall) with SMTP id 2F6F8441C1 for ; Fri, 8 Dec 2006 09:28:58 +0000 (GMT) Received: from MHDEXC99.adhel.hitachi-eu.com ([IP=193.39.227.52]) by eSafe SMTP Relay 1165510268; Fri Dec 8 09:28:58 2006 Received: from mhdexc02.adhel.hitachi-eu.com ([193.39.227.51]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 09:28:57 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Specific Properties Date: Fri, 8 Dec 2006 09:26:52 -0000 Message-ID: <3167F18F59B81B4888A4D4C0A1717DD6670F9B@mhdexc02.adhel.hitachi-eu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Specific Properties Thread-Index: Accaqv6RzQz8N3GTT9ii2AnTnnsrhA== From: "Boschi, Elisa" To: X-OriginalArrivalTime: 08 Dec 2006 09:28:57.0667 (UTC) FILETIME=[49689930:01C71AAB] X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: ipfix@ietf.org Subject: [IPFIX] Specific Properties X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1360992638==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1360992638== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71AAB.49174779" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71AAB.49174779 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andrew, I've changed the subject to help us keeping track of the different thread= s... > > >> >>> Is there any need to define a new term for "Specific >> >>> Properties"? These are just part of a normal Data Record. >> >>> For example: >> >>> "... The rows are then referenced by the Specific Properties >> >>> by using the appropriate value for the Common Properties >> >>> identifier." >> >>> >> >>> could simply be: >> >>> "... The rows are then referenced by Data Records by >> >>> using the appropriate value for the Common Properties >> >>> identifier." >> >> >> >> >> >> In your example, the "Data Records" doesn't mean the full data >> >> records before applying the redundancy reduction mechanism but onl= y >> a part of it. >> >> So it might be confusing... That's the trick we found. >> > >> >> The Specific Properties are "what is left" of the Data Record when the= Common Properties have been defined. In your example above using Data Re= cords is wrong... > > Wrong? It wouldn't be the first time, but perhaps you would like to > explain your reasoning for saying so. "...The rows are then referenced by the Specific Properties by using the = appropriate value for the Common Properties identifier." and "... The rows are then referenced by Data Records by using the appropria= te value for the Common Properties identifier." do not mean the same thing and can be confusing. Specific Properties are just a subset of the Data Record's fields, a subs= et which is complementary to the Common Properties Of course then both Common Properties and Specific Properties will eventu= ally be exported in Data Records, but it is not too clear which Data Reco= rds you are referring to in the text above... (ok so maybe instead of "wrong" it is just "confusing") > > A Flow is handed from the Metering Process to the Exporting Process. > The Exporting Process performs some magic, possibly including some > reducing redundancy type stuff and produces and IPFIX export stream. > >> From IPFIX-PROTO: > Data Record A Data Record is a record that contains values of the par= ameters corresponding to a Template Record... > > The Data Records are something that the Exporting Process produces, > it is not right to talk about Data Records before something is > exported. > > >> Using the term Specific Properties seems clearer... (and it seemed int= uitive after the term Common Properties had been used) > > By all means say that the Data Record that is sent contains properties > specific to the Flow. I'm not complaining about calling them specific > properties, but I don't think there is any need to have a new definitio= n > of "Specific Properties". I think it makes the whole draft clearer and easier to understand. Specif= ic Properties are complementary to Common Properties, everything has a na= me... we will not have to use things like "fileds of the Data Record which are = not Part of the Common Properties"... Regards, Elisa *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* ------_=_NextPart_001_01C71AAB.49174779 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Specific Properties

Andrew,

I've changed the subject to help us keeping track of the different thread= s...

>
>
>>  >>> Is there any need to define a new term for &q= uot;Specific
>>  >>> Properties"? These are just part of a no= rmal Data Record.
>>  >>> For example:
>>  >>> "... The rows are then referenced by the= Specific Properties
>>  >>> by using the appropriate value for the Common= Properties
>>  >>> identifier."
>>  >>>
>>  >>> could simply be:
>>  >>> "... The rows are then referenced by Dat= a Records by
>>  >>> using the appropriate value for the Common Pr= operties
>>  >>> identifier."
>>  >>
>>  >>
>>  >> In your example, the "Data Records" doe= sn't mean the full data
>>  >> records before applying the redundancy reduction = mechanism but only  >> a part of it.
>>  >> So it might be confusing... That's the trick we f= ound.
>>  >
>>
>> The Specific Properties are "what is left" of the Data= Record when the Common Properties have been defined. In your example abo= ve using Data Records is wrong...
>
> Wrong?  It wouldn't be the first time, but perhaps you would li= ke to
> explain your reasoning for saying so.



"...The rows are then referenced by the Specific Properties by using= the appropriate value for the Common Properties identifier."
and
 "... The rows are then referenced by Data Records by using the= appropriate value for the Common Properties identifier."

do not mean the same thing and can be confusing.

Specific Properties are just a subset of the Data Record's fields, a subs= et which is complementary to the Common Properties

Of course then both Common Properties and Specific Properties will eventu= ally be exported in Data Records, but it is not too clear which Data Reco= rds you are referring to in the text above...

(ok so maybe instead of "wrong" it is just "confusing"= ;)

>
> A Flow is handed from the Metering Process to the Exporting Process.=
> The Exporting Process performs some magic, possibly including some > reducing redundancy type stuff and produces and IPFIX export stream.=
>
>> From IPFIX-PROTO:
> Data Record   A Data Record is a record that contains valu= es of the parameters   corresponding to a Template Record... >
> The Data Records are something that the Exporting Process produces,<= BR> > it is not right to talk about Data Records before something is
> exported.
>
>
>> Using the term Specific Properties seems clearer... (and it seem= ed intuitive after the term Common Properties had been used)
>
> By all means say that the Data Record that is sent contains properti= es
> specific to the Flow.  I'm not complaining about calling them s= pecific
> properties, but I don't think there is any need to have a new defini= tion
> of "Specific Properties".


I think it makes the whole draft clearer and easier to understand. Specif= ic Properties are complementary to Common Properties, everything has a na= me...
we will not have to use things like "fileds of the Data Record which= are not Part of the Common Properties"...


Regards,
Elisa

 

*************************************************************************=
*************************
=20
 E-mail Confidentiality Notice and Disclaimer.
=20
  This email and any files transmitted with it are confidential and are i=
ntended solely for=20
the use of the individual or entity to which they are addressed. Access t=
o this e-mail by=20
anyone else is unauthorised. If you are not the intended recipient, any d=
isclosure,=20
copying, distribution or any action taken or omitted to be taken in relia=
nce on it, is=20
prohibited.=20
  E-mail messages are not necessarily secure.  Hitachi does not accept re=
sponsibility=20
for any changes made to this message after it was sent.=20
  Please note that Hitachi checks outgoing e-mail messages for the presen=
ce of=20
computer viruses.

*************************************************************************=
*************************
------_=_NextPart_001_01C71AAB.49174779-- --===============1360992638== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1360992638==-- From ipfix-bounces@ietf.org Fri Dec 08 04:30:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsc2e-0006ww-DI; Fri, 08 Dec 2006 04:29:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsc2d-0006wq-IZ for ipfix@ietf.org; Fri, 08 Dec 2006 04:29:15 -0500 Received: from gatekeeper.hitachi-eu.com ([194.36.128.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsc2X-00052z-Se for ipfix@ietf.org; Fri, 08 Dec 2006 04:29:15 -0500 X-ASG-Debug-ID: 1165570138-56c9002f0000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: primary.hitachi-eu.net[193.39.225.234] X-Barracuda-Start-Time: 1165570138 X-ASG-Whitelist: Client Received: from mhd-esafe-int.hitachi-eu.com (primary.hitachi-eu.net [193.39.225.234]) by gatekeeper.hitachi-eu.com (Spam Firewall) with SMTP id 2F6F8441C1 for ; Fri, 8 Dec 2006 09:28:58 +0000 (GMT) Received: from MHDEXC99.adhel.hitachi-eu.com ([IP=193.39.227.52]) by eSafe SMTP Relay 1165510268; Fri Dec 8 09:28:58 2006 Received: from mhdexc02.adhel.hitachi-eu.com ([193.39.227.51]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 09:28:57 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Specific Properties Date: Fri, 8 Dec 2006 09:26:52 -0000 Message-ID: <3167F18F59B81B4888A4D4C0A1717DD6670F9B@mhdexc02.adhel.hitachi-eu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Specific Properties Thread-Index: Accaqv6RzQz8N3GTT9ii2AnTnnsrhA== From: "Boschi, Elisa" To: X-OriginalArrivalTime: 08 Dec 2006 09:28:57.0667 (UTC) FILETIME=[49689930:01C71AAB] X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: ipfix@ietf.org Subject: [IPFIX] Specific Properties X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1360992638==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1360992638== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71AAB.49174779" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71AAB.49174779 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andrew, I've changed the subject to help us keeping track of the different thread= s... > > >> >>> Is there any need to define a new term for "Specific >> >>> Properties"? These are just part of a normal Data Record. >> >>> For example: >> >>> "... The rows are then referenced by the Specific Properties >> >>> by using the appropriate value for the Common Properties >> >>> identifier." >> >>> >> >>> could simply be: >> >>> "... The rows are then referenced by Data Records by >> >>> using the appropriate value for the Common Properties >> >>> identifier." >> >> >> >> >> >> In your example, the "Data Records" doesn't mean the full data >> >> records before applying the redundancy reduction mechanism but onl= y >> a part of it. >> >> So it might be confusing... That's the trick we found. >> > >> >> The Specific Properties are "what is left" of the Data Record when the= Common Properties have been defined. In your example above using Data Re= cords is wrong... > > Wrong? It wouldn't be the first time, but perhaps you would like to > explain your reasoning for saying so. "...The rows are then referenced by the Specific Properties by using the = appropriate value for the Common Properties identifier." and "... The rows are then referenced by Data Records by using the appropria= te value for the Common Properties identifier." do not mean the same thing and can be confusing. Specific Properties are just a subset of the Data Record's fields, a subs= et which is complementary to the Common Properties Of course then both Common Properties and Specific Properties will eventu= ally be exported in Data Records, but it is not too clear which Data Reco= rds you are referring to in the text above... (ok so maybe instead of "wrong" it is just "confusing") > > A Flow is handed from the Metering Process to the Exporting Process. > The Exporting Process performs some magic, possibly including some > reducing redundancy type stuff and produces and IPFIX export stream. > >> From IPFIX-PROTO: > Data Record A Data Record is a record that contains values of the par= ameters corresponding to a Template Record... > > The Data Records are something that the Exporting Process produces, > it is not right to talk about Data Records before something is > exported. > > >> Using the term Specific Properties seems clearer... (and it seemed int= uitive after the term Common Properties had been used) > > By all means say that the Data Record that is sent contains properties > specific to the Flow. I'm not complaining about calling them specific > properties, but I don't think there is any need to have a new definitio= n > of "Specific Properties". I think it makes the whole draft clearer and easier to understand. Specif= ic Properties are complementary to Common Properties, everything has a na= me... we will not have to use things like "fileds of the Data Record which are = not Part of the Common Properties"... Regards, Elisa *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* ------_=_NextPart_001_01C71AAB.49174779 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Specific Properties

Andrew,

I've changed the subject to help us keeping track of the different thread= s...

>
>
>>  >>> Is there any need to define a new term for &q= uot;Specific
>>  >>> Properties"? These are just part of a no= rmal Data Record.
>>  >>> For example:
>>  >>> "... The rows are then referenced by the= Specific Properties
>>  >>> by using the appropriate value for the Common= Properties
>>  >>> identifier."
>>  >>>
>>  >>> could simply be:
>>  >>> "... The rows are then referenced by Dat= a Records by
>>  >>> using the appropriate value for the Common Pr= operties
>>  >>> identifier."
>>  >>
>>  >>
>>  >> In your example, the "Data Records" doe= sn't mean the full data
>>  >> records before applying the redundancy reduction = mechanism but only  >> a part of it.
>>  >> So it might be confusing... That's the trick we f= ound.
>>  >
>>
>> The Specific Properties are "what is left" of the Data= Record when the Common Properties have been defined. In your example abo= ve using Data Records is wrong...
>
> Wrong?  It wouldn't be the first time, but perhaps you would li= ke to
> explain your reasoning for saying so.



"...The rows are then referenced by the Specific Properties by using= the appropriate value for the Common Properties identifier."
and
 "... The rows are then referenced by Data Records by using the= appropriate value for the Common Properties identifier."

do not mean the same thing and can be confusing.

Specific Properties are just a subset of the Data Record's fields, a subs= et which is complementary to the Common Properties

Of course then both Common Properties and Specific Properties will eventu= ally be exported in Data Records, but it is not too clear which Data Reco= rds you are referring to in the text above...

(ok so maybe instead of "wrong" it is just "confusing"= ;)

>
> A Flow is handed from the Metering Process to the Exporting Process.=
> The Exporting Process performs some magic, possibly including some > reducing redundancy type stuff and produces and IPFIX export stream.=
>
>> From IPFIX-PROTO:
> Data Record   A Data Record is a record that contains valu= es of the parameters   corresponding to a Template Record... >
> The Data Records are something that the Exporting Process produces,<= BR> > it is not right to talk about Data Records before something is
> exported.
>
>
>> Using the term Specific Properties seems clearer... (and it seem= ed intuitive after the term Common Properties had been used)
>
> By all means say that the Data Record that is sent contains properti= es
> specific to the Flow.  I'm not complaining about calling them s= pecific
> properties, but I don't think there is any need to have a new defini= tion
> of "Specific Properties".


I think it makes the whole draft clearer and easier to understand. Specif= ic Properties are complementary to Common Properties, everything has a na= me...
we will not have to use things like "fileds of the Data Record which= are not Part of the Common Properties"...


Regards,
Elisa

 

*************************************************************************=
*************************
=20
 E-mail Confidentiality Notice and Disclaimer.
=20
  This email and any files transmitted with it are confidential and are i=
ntended solely for=20
the use of the individual or entity to which they are addressed. Access t=
o this e-mail by=20
anyone else is unauthorised. If you are not the intended recipient, any d=
isclosure,=20
copying, distribution or any action taken or omitted to be taken in relia=
nce on it, is=20
prohibited.=20
  E-mail messages are not necessarily secure.  Hitachi does not accept re=
sponsibility=20
for any changes made to this message after it was sent.=20
  Please note that Hitachi checks outgoing e-mail messages for the presen=
ce of=20
computer viruses.

*************************************************************************=
*************************
------_=_NextPart_001_01C71AAB.49174779-- --===============1360992638== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1360992638==-- From ipfix-bounces@ietf.org Fri Dec 08 05:30:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gscz4-0004Ub-96; Fri, 08 Dec 2006 05:29:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gscz2-0004Tf-T1 for ipfix@ietf.org; Fri, 08 Dec 2006 05:29:37 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gscy6-0007Na-NP for ipfix@ietf.org; Fri, 08 Dec 2006 05:28:40 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Dec 2006 11:28:36 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB8ASZFY031892; Fri, 8 Dec 2006 11:28:35 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB8ASZAJ012646; Fri, 8 Dec 2006 11:28:35 +0100 (MET) Received: from [10.61.65.30] (ams3-vpn-dhcp286.cisco.com [10.61.65.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA04884; Fri, 8 Dec 2006 10:28:32 GMT Message-ID: <45793E32.4050507@cisco.com> Date: Fri, 08 Dec 2006 10:28:02 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] Cascading Common Properties References: <45786D1E.8030906@cisco.com> <658B4059-38B5-4C20-AF57-783EE3F8949E@cert.org> In-Reply-To: <658B4059-38B5-4C20-AF57-783EE3F8949E@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9595; t=1165573715; x=1166437715; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Cascading=20Common=20Properties |Sender:=20; bh=CyM+9dF4Hlr0c6yfREk7PgGzFeo5JUWynziyjyrX5es=; b=ET9LUThm8tvO7Eo3AwJ59jo/Y5GcsGBhOTZ7oZ/TdxaCNu3tQ58LjNs/ihukZTFbGsxD2cjq OFdf51UjnTcdxwJhoIxKhOrSdqoFS3fylUx/qiB5H6CyjKJ0GlEjsVNF; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Brian As usual your understanding seems quite complete. Some commentary inline anyway. BTW, I think Reducing Redundancy can, and should, be made to work with the protocol as it stands today without any extra requirements on either the Exporter or Collector. Brian Trammell wrote: > Andrew, > > Let me make sure I understand this by restating it a bit: > > 1. When the Collecting Process receives Common Properties that reference > other Common Properties themselves, it MUST resolve the references to > Common Properties. A Collecting Process MAY hold Common Properties for > later resolution if the referenced Common Properties are not yet defined. Absolutely. Remember option data is received in a Data Record. The same rules should apply to Data Records that contain option data or flow data. > 2. An Exporting Process MUST NOT export Common Properties that reference > themselves directly, and a Collecting Process MUST drop any Common > Properties that reference themselves directly and SHOULD log the error. Well, I don't want to add any MUST, MUST NOT or SHOULDs beyond what the protocol already says. However if a Data Record is received that references itself then this seems the fairest approach. Perhaps it should be added to the implementation guidelines as it is a general issue for all options, not just CPs. > 3. If a given Information Element appears both in a Record and by > reference to Common Properties (whether in cascaded Common Properties or > not), it MUST be treated as a multiple Information Element. The order of > the multiple Information Elements MUST be determined from the > arrangement of the commonPropertiesId and referenced Information > Elements in the Data Record, and this order MUST be preserved. Yes. > Note that this third point would modify the present section 3.1.2 > multiple data reduction treatment of collisions. Good :). I would like all requirements that aren't taken from the protocol to be removed, with the possible exceptions of ones, like you mention above, that are really holes in the protocol document and should probably also be covered in the implementation guidelines. > (Also, I just realized something... if the three points above accurately > describe what you're proposing, this could also be used to, somewhat > inefficiently, build variable-length arrays in IPFIX...) > > Hmmm.... I like it. It's simple, it's useful, it's implementable, and it > requires fewer changes to the document at this point. > > Unless I'm missing something. :) I don't think so. Simple and implementable has always been my angle. I also don't think that changing the document at this point should really be much of a consideration. It's blocked until PSAMP and it's the first real test of options, so let's get it right. The decisions made here will have implications for all options, which we know aren't dealt with properly/fully in the protocol. regards Andrew > On Dec 7, 2006, at 2:35 PM, Andrew Johnson wrote: > >> Repeated email with correction to the example: >> ipv4DestinationAddress of 192.168.0.1 -> 192.168.0.2 >> >> Thanks to Danny Llewallyn for pointing it out. >> >> Cheers >> >> Andrew >> >> -------- Original Message -------- >> >> Hi all >> >> May I propose a relatively simple solution. I think cascades of >> identifiers is valid in IPFIX and useful. I also think that they >> are a lot simpler than people imagine. >> >> >> NORMAL OPTIONS >> ============== >> An option can be thought of as a substitution. When a Data Record >> is received containing Flow information then any identifiers in >> that Record can be immediately substituted for the data associated >> with it. >> >> For example, a Data Record containing: >> commonPropertiesID = 5 >> ipv4SourceAddress = 192.168.0.1 >> >> If we have a definition of cpID 5, say ipv4DestinationAddress = >> 192.168.0.2) then the collector can immediately expand that into: >> ipv4DestinationAddress = 192.168.0.2 >> ipv4SourceAddress = 192.168.0.1 >> >> If cpId 5 is withdrawn or redefined at a later date then that >> does NOT redefine this expanded Record. >> >> If cpId 5 is not defined, the collector can hold off decoding >> the Data Record for a short while before discarding it. >> >> CASCADING OPTIONS >> ================= >> If a Data Record is received which is definition then any >> identifiers in that Record an be immediately substituted for >> the data associated with it. For example: >> commonProperties ID = 6 (scope) >> commonPropertiesID = 5 >> ipv4SourceAddress = 192.168.0.1 >> >> Can be immediately expanded into: >> commonProperties ID = 6 (scope) >> ipv4DestinationAddress = 192.168.0.2 >> ipv4SourceAddress = 192.168.0.1 >> >> If cpId 5 is withdrawn or redefined at a later date then that >> does NOT redefine this expanded Record. >> >> If cpId 5 is not defined, the collector can hold off decoding >> the Data Record for a short while before discarding it. >> >> A circular definition will sit on the waiting queue until it >> is discarded. A "collision" will immediately expand out to >> contain the IE twice. Today we can send Data Records with >> the same IE twice so why not. It should be noted that >> ordering should be preserved. >> >> Andrew >> >> >> Brian Trammell wrote: >>> All, >>> Agreed that common properties cascades 1. should be allowed, and 2. >>> addressed explicitly in the document. >>> To keep the discussion going, I'd like to propose solutions (or at >>> least choices of solutions) for the points Elisa raised: >>>>> duplication (as also written by Andrew) >>>>> >>>>> cpID A --> src addr A, src port A >>>>> cpID B --> src addr A, cpID A >>>>> >>>>> collision >>>>> >>>>> cpID A --> src addr A, src port A >>>>> cpID A --> src addr B, cpID A >>> I can think of two possible simple ways to address these concerns: >>> 1. The principles in 3.1.2 Multiple Data Reduction could be readily >>> extended to handle cascades: simply disallow any sort of collision, >>> of which duplication is merely a subset. >>> 2. Allow collision or duplication in the cascade, but ONLY to allow a >>> common property "lower" in the hierarchy to override values of one >>> "higher". This makes cascades potentially much more useful (giving us >>> workable inheritance) at the expense of a fair amount of complexity. >>> I don't personally have a strong opinion in either direction. >>>>> withdrawal >>>>> >>>>> what happens to a node in the tree if one of its children (or a >>>>> node in its subtree) is a cpID and is withdrawn? Does the >>>>> collecting process need to search for all the CP that are defined >>>>> in terms of it and invalidate them too? >>> Yes... it seems to me the only real difficulty with cascading common >>> properties (indeed, with cascading _anything_ really) is handling >>> withdrawal. We could of course allow any of the various policies for >>> cascading withdrawal and even provide a mechanism for setting the >>> common properties withdrawal cascade policy via options (and even >>> allow those options to be bound to common properties themselves, if >>> we were feeling particularly uncharitable toward CP implementors :) ) >>> but I don't think we want to do that for the sake of simplicity. So I >>> think we want to pick a single withdrawal cascade policy. >>> There is a question to answer explicitly before doing so: When a >>> common property is withdrawn or invalid, is the record referencing it >>> 1. invalid (as is implied by the document currently, and by most of >>> the messages in these threads) or 2. valid but simply missing data >>> (as has been proposed at least once, I forget by whom, but not >>> particularly deeply discussed yet). Note that if inheritance and >>> overrides are available in cascades as above, this second case is >>> _not_ a valid choice. >>> In the first case, I would propose that 1. an Exporting Process >>> SHOULD withdraw all common properties "lower" in the cascade before >>> withdrawing the common properties they reference; 2. a Collecting >>> Process MUST invalidate all common properties defined in terms of a >>> withdrawn common property; and 3. a Collecting Process MUST ignore >>> common properties withdrawals sent by an Exporting Process that would >>> withdraw common properties previously invalidated by a cascade >>> withdrawal as in 2. This proposal is not particularly simple, but I >>> think it is as simple as it can be while holding to the principle of >>> being liberal in what you accept and conservative in what you send, >>> and to the IPFIX design requirement to minimize complexity at the EP. >>> In the second case, cascade withdrawal becomes simpler: simply ignore >>> the cascade. The Exporting Process MUST explicitly withdraw any >>> common property that is no longer valid, regardless of whether it's >>> defined in terms of others. Partially withdrawn cascades would then >>> merely be partially valid. >>> (For what it's worth, I personally lean toward the first case here.) >>> Thoughts? >>> Regards, >>> Brian >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ipfix >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Dec 08 05:30:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gscz4-0004Ub-96; Fri, 08 Dec 2006 05:29:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gscz2-0004Tf-T1 for ipfix@ietf.org; Fri, 08 Dec 2006 05:29:37 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gscy6-0007Na-NP for ipfix@ietf.org; Fri, 08 Dec 2006 05:28:40 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Dec 2006 11:28:36 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB8ASZFY031892; Fri, 8 Dec 2006 11:28:35 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB8ASZAJ012646; Fri, 8 Dec 2006 11:28:35 +0100 (MET) Received: from [10.61.65.30] (ams3-vpn-dhcp286.cisco.com [10.61.65.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA04884; Fri, 8 Dec 2006 10:28:32 GMT Message-ID: <45793E32.4050507@cisco.com> Date: Fri, 08 Dec 2006 10:28:02 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] Cascading Common Properties References: <45786D1E.8030906@cisco.com> <658B4059-38B5-4C20-AF57-783EE3F8949E@cert.org> In-Reply-To: <658B4059-38B5-4C20-AF57-783EE3F8949E@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9595; t=1165573715; x=1166437715; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Cascading=20Common=20Properties |Sender:=20; bh=CyM+9dF4Hlr0c6yfREk7PgGzFeo5JUWynziyjyrX5es=; b=ET9LUThm8tvO7Eo3AwJ59jo/Y5GcsGBhOTZ7oZ/TdxaCNu3tQ58LjNs/ihukZTFbGsxD2cjq OFdf51UjnTcdxwJhoIxKhOrSdqoFS3fylUx/qiB5H6CyjKJ0GlEjsVNF; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Brian As usual your understanding seems quite complete. Some commentary inline anyway. BTW, I think Reducing Redundancy can, and should, be made to work with the protocol as it stands today without any extra requirements on either the Exporter or Collector. Brian Trammell wrote: > Andrew, > > Let me make sure I understand this by restating it a bit: > > 1. When the Collecting Process receives Common Properties that reference > other Common Properties themselves, it MUST resolve the references to > Common Properties. A Collecting Process MAY hold Common Properties for > later resolution if the referenced Common Properties are not yet defined. Absolutely. Remember option data is received in a Data Record. The same rules should apply to Data Records that contain option data or flow data. > 2. An Exporting Process MUST NOT export Common Properties that reference > themselves directly, and a Collecting Process MUST drop any Common > Properties that reference themselves directly and SHOULD log the error. Well, I don't want to add any MUST, MUST NOT or SHOULDs beyond what the protocol already says. However if a Data Record is received that references itself then this seems the fairest approach. Perhaps it should be added to the implementation guidelines as it is a general issue for all options, not just CPs. > 3. If a given Information Element appears both in a Record and by > reference to Common Properties (whether in cascaded Common Properties or > not), it MUST be treated as a multiple Information Element. The order of > the multiple Information Elements MUST be determined from the > arrangement of the commonPropertiesId and referenced Information > Elements in the Data Record, and this order MUST be preserved. Yes. > Note that this third point would modify the present section 3.1.2 > multiple data reduction treatment of collisions. Good :). I would like all requirements that aren't taken from the protocol to be removed, with the possible exceptions of ones, like you mention above, that are really holes in the protocol document and should probably also be covered in the implementation guidelines. > (Also, I just realized something... if the three points above accurately > describe what you're proposing, this could also be used to, somewhat > inefficiently, build variable-length arrays in IPFIX...) > > Hmmm.... I like it. It's simple, it's useful, it's implementable, and it > requires fewer changes to the document at this point. > > Unless I'm missing something. :) I don't think so. Simple and implementable has always been my angle. I also don't think that changing the document at this point should really be much of a consideration. It's blocked until PSAMP and it's the first real test of options, so let's get it right. The decisions made here will have implications for all options, which we know aren't dealt with properly/fully in the protocol. regards Andrew > On Dec 7, 2006, at 2:35 PM, Andrew Johnson wrote: > >> Repeated email with correction to the example: >> ipv4DestinationAddress of 192.168.0.1 -> 192.168.0.2 >> >> Thanks to Danny Llewallyn for pointing it out. >> >> Cheers >> >> Andrew >> >> -------- Original Message -------- >> >> Hi all >> >> May I propose a relatively simple solution. I think cascades of >> identifiers is valid in IPFIX and useful. I also think that they >> are a lot simpler than people imagine. >> >> >> NORMAL OPTIONS >> ============== >> An option can be thought of as a substitution. When a Data Record >> is received containing Flow information then any identifiers in >> that Record can be immediately substituted for the data associated >> with it. >> >> For example, a Data Record containing: >> commonPropertiesID = 5 >> ipv4SourceAddress = 192.168.0.1 >> >> If we have a definition of cpID 5, say ipv4DestinationAddress = >> 192.168.0.2) then the collector can immediately expand that into: >> ipv4DestinationAddress = 192.168.0.2 >> ipv4SourceAddress = 192.168.0.1 >> >> If cpId 5 is withdrawn or redefined at a later date then that >> does NOT redefine this expanded Record. >> >> If cpId 5 is not defined, the collector can hold off decoding >> the Data Record for a short while before discarding it. >> >> CASCADING OPTIONS >> ================= >> If a Data Record is received which is definition then any >> identifiers in that Record an be immediately substituted for >> the data associated with it. For example: >> commonProperties ID = 6 (scope) >> commonPropertiesID = 5 >> ipv4SourceAddress = 192.168.0.1 >> >> Can be immediately expanded into: >> commonProperties ID = 6 (scope) >> ipv4DestinationAddress = 192.168.0.2 >> ipv4SourceAddress = 192.168.0.1 >> >> If cpId 5 is withdrawn or redefined at a later date then that >> does NOT redefine this expanded Record. >> >> If cpId 5 is not defined, the collector can hold off decoding >> the Data Record for a short while before discarding it. >> >> A circular definition will sit on the waiting queue until it >> is discarded. A "collision" will immediately expand out to >> contain the IE twice. Today we can send Data Records with >> the same IE twice so why not. It should be noted that >> ordering should be preserved. >> >> Andrew >> >> >> Brian Trammell wrote: >>> All, >>> Agreed that common properties cascades 1. should be allowed, and 2. >>> addressed explicitly in the document. >>> To keep the discussion going, I'd like to propose solutions (or at >>> least choices of solutions) for the points Elisa raised: >>>>> duplication (as also written by Andrew) >>>>> >>>>> cpID A --> src addr A, src port A >>>>> cpID B --> src addr A, cpID A >>>>> >>>>> collision >>>>> >>>>> cpID A --> src addr A, src port A >>>>> cpID A --> src addr B, cpID A >>> I can think of two possible simple ways to address these concerns: >>> 1. The principles in 3.1.2 Multiple Data Reduction could be readily >>> extended to handle cascades: simply disallow any sort of collision, >>> of which duplication is merely a subset. >>> 2. Allow collision or duplication in the cascade, but ONLY to allow a >>> common property "lower" in the hierarchy to override values of one >>> "higher". This makes cascades potentially much more useful (giving us >>> workable inheritance) at the expense of a fair amount of complexity. >>> I don't personally have a strong opinion in either direction. >>>>> withdrawal >>>>> >>>>> what happens to a node in the tree if one of its children (or a >>>>> node in its subtree) is a cpID and is withdrawn? Does the >>>>> collecting process need to search for all the CP that are defined >>>>> in terms of it and invalidate them too? >>> Yes... it seems to me the only real difficulty with cascading common >>> properties (indeed, with cascading _anything_ really) is handling >>> withdrawal. We could of course allow any of the various policies for >>> cascading withdrawal and even provide a mechanism for setting the >>> common properties withdrawal cascade policy via options (and even >>> allow those options to be bound to common properties themselves, if >>> we were feeling particularly uncharitable toward CP implementors :) ) >>> but I don't think we want to do that for the sake of simplicity. So I >>> think we want to pick a single withdrawal cascade policy. >>> There is a question to answer explicitly before doing so: When a >>> common property is withdrawn or invalid, is the record referencing it >>> 1. invalid (as is implied by the document currently, and by most of >>> the messages in these threads) or 2. valid but simply missing data >>> (as has been proposed at least once, I forget by whom, but not >>> particularly deeply discussed yet). Note that if inheritance and >>> overrides are available in cascades as above, this second case is >>> _not_ a valid choice. >>> In the first case, I would propose that 1. an Exporting Process >>> SHOULD withdraw all common properties "lower" in the cascade before >>> withdrawing the common properties they reference; 2. a Collecting >>> Process MUST invalidate all common properties defined in terms of a >>> withdrawn common property; and 3. a Collecting Process MUST ignore >>> common properties withdrawals sent by an Exporting Process that would >>> withdraw common properties previously invalidated by a cascade >>> withdrawal as in 2. This proposal is not particularly simple, but I >>> think it is as simple as it can be while holding to the principle of >>> being liberal in what you accept and conservative in what you send, >>> and to the IPFIX design requirement to minimize complexity at the EP. >>> In the second case, cascade withdrawal becomes simpler: simply ignore >>> the cascade. The Exporting Process MUST explicitly withdraw any >>> common property that is no longer valid, regardless of whether it's >>> defined in terms of others. Partially withdrawn cascades would then >>> merely be partially valid. >>> (For what it's worth, I personally lean toward the first case here.) >>> Thoughts? >>> Regards, >>> Brian >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ipfix >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Dec 08 05:43:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsdBz-0000zi-79; Fri, 08 Dec 2006 05:42:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsdBx-0000zM-Bg for ipfix@ietf.org; Fri, 08 Dec 2006 05:42:57 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsdBv-0002Rr-SD for ipfix@ietf.org; Fri, 08 Dec 2006 05:42:57 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Dec 2006 11:42:55 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB8Agtgx028783; Fri, 8 Dec 2006 11:42:55 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB8AgsAJ020983; Fri, 8 Dec 2006 11:42:54 +0100 (MET) Received: from [10.61.65.30] (ams3-vpn-dhcp286.cisco.com [10.61.65.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA05995; Fri, 8 Dec 2006 10:42:52 GMT Message-ID: <4579418D.4030701@cisco.com> Date: Fri, 08 Dec 2006 10:42:21 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Boschi, Elisa" References: <3167F18F59B81B4888A4D4C0A1717DD6670F9B@mhdexc02.adhel.hitachi-eu.com> In-Reply-To: <3167F18F59B81B4888A4D4C0A1717DD6670F9B@mhdexc02.adhel.hitachi-eu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3961; t=1165574575; x=1166438575; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20Specific=20Properties |Sender:=20; bh=B8cOj03VETXjS5f8gwRjB4wFt2o8GLMi9bwIyXrDeeU=; b=IQpv0HznhgAqoNr0sNiVPMFXqRj+vqZ/A5YaiIkBhStXL/a5oGKFafCjecIpTzpDm9rpypSA 9t9OivWqOTmQunWSOMG8MukhtiJuScJ47e2S+Y2JMIBy1C6hCL2LalwD; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: ipfix@ietf.org Subject: [IPFIX] Re: Specific Properties X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Boschi, Elisa wrote: > > Andrew, > > I've changed the subject to help us keeping track of the different > threads... > > >> >>> Is there any need to define a new term for "Specific > >> >>> Properties"? These are just part of a normal Data Record. > >> >>> For example: > >> >>> "... The rows are then referenced by the Specific Properties > >> >>> by using the appropriate value for the Common Properties > >> >>> identifier." > >> >>> > >> >>> could simply be: > >> >>> "... The rows are then referenced by Data Records by > >> >>> using the appropriate value for the Common Properties > >> >>> identifier." > >> >> > >> >> > >> >> In your example, the "Data Records" doesn't mean the full data > >> >> records before applying the redundancy reduction mechanism but > only >> a part of it. > >> >> So it might be confusing... That's the trick we found. > >> > > >> > >> The Specific Properties are "what is left" of the Data Record when > the Common Properties have been defined. In your example above using > Data Records is wrong... > > > > Wrong? It wouldn't be the first time, but perhaps you would like to > > explain your reasoning for saying so. > > > > "...The rows are then referenced by the Specific Properties by using the > appropriate value for the Common Properties identifier." > and > "... The rows are then referenced by Data Records by using the > appropriate value for the Common Properties identifier." > > do not mean the same thing and can be confusing. > > Specific Properties are just a subset of the Data Record's fields, a > subset which is complementary to the Common Properties OK, this is where I have a problem. As I keep explaining, a Data Record has a very specific definition. It is defined by an IPFIX Template and is sent by and Exporting Process to a Collecting Process. The Reducing Redundancy feature is applied to a Flow (or packet data) BEFORE it is exported. Therefore you don't have a Data Record at this point. Get your terminology straight! > Of course then both Common Properties and Specific Properties will > eventually be exported in Data Records, but it is not too clear which > Data Records you are referring to in the text above... > > (ok so maybe instead of "wrong" it is just "confusing") > > > > > A Flow is handed from the Metering Process to the Exporting Process. > > The Exporting Process performs some magic, possibly including some > > reducing redundancy type stuff and produces and IPFIX export stream. > > > >> From IPFIX-PROTO: > > Data Record A Data Record is a record that contains values of the > parameters corresponding to a Template Record... > > > > The Data Records are something that the Exporting Process produces, > > it is not right to talk about Data Records before something is > > exported. > > > > > >> Using the term Specific Properties seems clearer... (and it seemed > intuitive after the term Common Properties had been used) > > > > By all means say that the Data Record that is sent contains properties > > specific to the Flow. I'm not complaining about calling them specific > > properties, but I don't think there is any need to have a new definition > > of "Specific Properties". > > > I think it makes the whole draft clearer and easier to understand. > Specific Properties are complementary to Common Properties, everything > has a name... > we will not have to use things like "fileds of the Data Record which are > not Part of the Common Properties"... Why does it need a name, or more specifically a Name? The terminology section of the draft already runs to 6 pages! That's about 25% of the whole document, including boilerplate and detailed examples. Call them specific properties by all means, but you don't need a formal definition of the name. Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Dec 08 05:43:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsdBz-0000zi-79; Fri, 08 Dec 2006 05:42:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsdBx-0000zM-Bg for ipfix@ietf.org; Fri, 08 Dec 2006 05:42:57 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsdBv-0002Rr-SD for ipfix@ietf.org; Fri, 08 Dec 2006 05:42:57 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Dec 2006 11:42:55 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB8Agtgx028783; Fri, 8 Dec 2006 11:42:55 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB8AgsAJ020983; Fri, 8 Dec 2006 11:42:54 +0100 (MET) Received: from [10.61.65.30] (ams3-vpn-dhcp286.cisco.com [10.61.65.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA05995; Fri, 8 Dec 2006 10:42:52 GMT Message-ID: <4579418D.4030701@cisco.com> Date: Fri, 08 Dec 2006 10:42:21 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Boschi, Elisa" References: <3167F18F59B81B4888A4D4C0A1717DD6670F9B@mhdexc02.adhel.hitachi-eu.com> In-Reply-To: <3167F18F59B81B4888A4D4C0A1717DD6670F9B@mhdexc02.adhel.hitachi-eu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3961; t=1165574575; x=1166438575; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20Specific=20Properties |Sender:=20; bh=B8cOj03VETXjS5f8gwRjB4wFt2o8GLMi9bwIyXrDeeU=; b=IQpv0HznhgAqoNr0sNiVPMFXqRj+vqZ/A5YaiIkBhStXL/a5oGKFafCjecIpTzpDm9rpypSA 9t9OivWqOTmQunWSOMG8MukhtiJuScJ47e2S+Y2JMIBy1C6hCL2LalwD; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: ipfix@ietf.org Subject: [IPFIX] Re: Specific Properties X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Boschi, Elisa wrote: > > Andrew, > > I've changed the subject to help us keeping track of the different > threads... > > >> >>> Is there any need to define a new term for "Specific > >> >>> Properties"? These are just part of a normal Data Record. > >> >>> For example: > >> >>> "... The rows are then referenced by the Specific Properties > >> >>> by using the appropriate value for the Common Properties > >> >>> identifier." > >> >>> > >> >>> could simply be: > >> >>> "... The rows are then referenced by Data Records by > >> >>> using the appropriate value for the Common Properties > >> >>> identifier." > >> >> > >> >> > >> >> In your example, the "Data Records" doesn't mean the full data > >> >> records before applying the redundancy reduction mechanism but > only >> a part of it. > >> >> So it might be confusing... That's the trick we found. > >> > > >> > >> The Specific Properties are "what is left" of the Data Record when > the Common Properties have been defined. In your example above using > Data Records is wrong... > > > > Wrong? It wouldn't be the first time, but perhaps you would like to > > explain your reasoning for saying so. > > > > "...The rows are then referenced by the Specific Properties by using the > appropriate value for the Common Properties identifier." > and > "... The rows are then referenced by Data Records by using the > appropriate value for the Common Properties identifier." > > do not mean the same thing and can be confusing. > > Specific Properties are just a subset of the Data Record's fields, a > subset which is complementary to the Common Properties OK, this is where I have a problem. As I keep explaining, a Data Record has a very specific definition. It is defined by an IPFIX Template and is sent by and Exporting Process to a Collecting Process. The Reducing Redundancy feature is applied to a Flow (or packet data) BEFORE it is exported. Therefore you don't have a Data Record at this point. Get your terminology straight! > Of course then both Common Properties and Specific Properties will > eventually be exported in Data Records, but it is not too clear which > Data Records you are referring to in the text above... > > (ok so maybe instead of "wrong" it is just "confusing") > > > > > A Flow is handed from the Metering Process to the Exporting Process. > > The Exporting Process performs some magic, possibly including some > > reducing redundancy type stuff and produces and IPFIX export stream. > > > >> From IPFIX-PROTO: > > Data Record A Data Record is a record that contains values of the > parameters corresponding to a Template Record... > > > > The Data Records are something that the Exporting Process produces, > > it is not right to talk about Data Records before something is > > exported. > > > > > >> Using the term Specific Properties seems clearer... (and it seemed > intuitive after the term Common Properties had been used) > > > > By all means say that the Data Record that is sent contains properties > > specific to the Flow. I'm not complaining about calling them specific > > properties, but I don't think there is any need to have a new definition > > of "Specific Properties". > > > I think it makes the whole draft clearer and easier to understand. > Specific Properties are complementary to Common Properties, everything > has a name... > we will not have to use things like "fileds of the Data Record which are > not Part of the Common Properties"... Why does it need a name, or more specifically a Name? The terminology section of the draft already runs to 6 pages! That's about 25% of the whole document, including boilerplate and detailed examples. Call them specific properties by all means, but you don't need a formal definition of the name. Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Dec 08 05:57:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsdPg-0005nh-Gy; Fri, 08 Dec 2006 05:57:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsdPf-0005nW-M2 for ipfix@ietf.org; Fri, 08 Dec 2006 05:57:07 -0500 Received: from gatekeeper.hitachi-eu.com ([194.36.128.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsdPH-0004yY-Hq for ipfix@ietf.org; Fri, 08 Dec 2006 05:57:07 -0500 X-ASG-Debug-ID: 1165575402-04bc00460000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: primary.hitachi-eu.net[193.39.225.234] X-Barracuda-Start-Time: 1165575402 X-ASG-Whitelist: Client Received: from mhd-esafe-int.hitachi-eu.com (primary.hitachi-eu.net [193.39.225.234]) by gatekeeper.hitachi-eu.com (Spam Firewall) with SMTP id BCFF53C513 for ; Fri, 8 Dec 2006 10:56:42 +0000 (GMT) Received: from MHDEXC99.adhel.hitachi-eu.com ([IP=193.39.227.52]) by eSafe SMTP Relay 1165510268; Fri Dec 8 10:56:42 2006 Received: from mhdexc02.adhel.hitachi-eu.com ([193.39.227.51]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 10:56:42 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Re: Specific Properties Date: Fri, 8 Dec 2006 10:55:47 -0000 Message-ID: <3167F18F59B81B4888A4D4C0A1717DD6670F9C@mhdexc02.adhel.hitachi-eu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Specific Properties Thread-Index: Accat2ra6T4XpMxDRiy6QQCTMINACQ== From: "Boschi, Elisa" To: X-OriginalArrivalTime: 08 Dec 2006 10:56:42.0229 (UTC) FILETIME=[8B550250:01C71AB7] X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: ipfix@ietf.org Subject: [IPFIX] Re: Specific Properties X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1299350091==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1299350091== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71AB7.8B0F506C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71AB7.8B0F506C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andrew Johnson wrote: >> ... > >> "...The rows are then referenced by the Specific Properties by using t= he appropriate value for the Common Properties identifier." >> and >> "... The rows are then referenced by Data Records by using the approp= riate value for the Common Properties identifier." >> >> do not mean the same thing and can be confusing. >> >> Specific Properties are just a subset of the Data Record's fields, a s= ubset which is complementary to the Common Properties > > > OK, this is where I have a problem. As I keep explaining, a Data > Record has a very specific definition. It is defined by an IPFIX > Template and is sent by and Exporting Process to a Collecting Process. > > The Reducing Redundancy feature is applied to a Flow (or packet data) > BEFORE it is exported. Therefore you don't have a Data Record at > this point. but when you start exporting you have two different ones: one Data Record= for the Common Properties and one Data Record for the Specific Propertie= s. So using "Data Record" in: "... The rows are then referenced by Data Records by using the appropriat= e value for the Common Properties identifier." doesn't help people understanding that the rows are referenced by the Dat= a Records exporting the Specific Properties by.... >> >> I think it makes the whole draft clearer and easier to understand. Spe= cific Properties are complementary to Common Properties, everything has a= name... >> we will not have to use things like "fileds of the Data Record which a= re not Part of the Common Properties"... > > > Why does it need a name, or more specifically a Name? The terminology > section of the draft already runs to 6 pages! That's about 25% of the > whole document, including boilerplate and detailed examples. this is not a reason for removing a (one!) useful definition. Elisa *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* ------_=_NextPart_001_01C71AB7.8B0F506C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Specific Properties

Andrew Johnson wrote:

>> ...
>
>> "...The rows are then referenced by the Specific Properties= by using the appropriate value for the Common Properties identifier.&quo= t;
>> and
>>  "... The rows are then referenced by Data Records by = using the appropriate value for the Common Properties identifier." >>
>> do not mean the same thing and can be confusing.
>>
>> Specific Properties are just a subset of the Data Record's field= s, a subset which is complementary to the Common Properties
>
>
> OK, this is where I have a problem.  As I keep explaining, a Da= ta
> Record has a very specific definition.  It is defined by an IPF= IX
> Template and is sent by and Exporting Process to a Collecting Proces= s.
>
> The Reducing Redundancy feature is applied to a Flow (or packet data= )
> BEFORE it is exported.  Therefore you don't have a Data Record = at
> this point.


but when you start exporting you have two different ones: one Data Record= for the Common Properties and one Data Record for the Specific Propertie= s. So using "Data Record" in:

"... The rows are then referenced by Data Records by using the appro= priate value for the Common Properties identifier."

doesn't help people understanding that the rows are referenced by the Dat= a Records exporting the Specific Properties by....


>>
>> I think it makes the whole draft clearer and easier to understan= d. Specific Properties are complementary to Common Properties, everything= has a name...
>> we will not have to use things like "fileds of the Data Rec= ord which are not Part of the Common Properties"...
>
>
> Why does it need a name, or more specifically a Name?  The term= inology
> section of the draft already runs to 6 pages!  That's about 25%= of the
> whole document, including boilerplate and detailed examples.


this is not a reason for removing a (one!) useful definition.

Elisa

 

*************************************************************************=
*************************
=20
 E-mail Confidentiality Notice and Disclaimer.
=20
  This email and any files transmitted with it are confidential and are i=
ntended solely for=20
the use of the individual or entity to which they are addressed. Access t=
o this e-mail by=20
anyone else is unauthorised. If you are not the intended recipient, any d=
isclosure,=20
copying, distribution or any action taken or omitted to be taken in relia=
nce on it, is=20
prohibited.=20
  E-mail messages are not necessarily secure.  Hitachi does not accept re=
sponsibility=20
for any changes made to this message after it was sent.=20
  Please note that Hitachi checks outgoing e-mail messages for the presen=
ce of=20
computer viruses.

*************************************************************************=
*************************
------_=_NextPart_001_01C71AB7.8B0F506C-- --===============1299350091== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1299350091==-- From ipfix-bounces@ietf.org Fri Dec 08 05:57:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsdPg-0005nh-Gy; Fri, 08 Dec 2006 05:57:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsdPf-0005nW-M2 for ipfix@ietf.org; Fri, 08 Dec 2006 05:57:07 -0500 Received: from gatekeeper.hitachi-eu.com ([194.36.128.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsdPH-0004yY-Hq for ipfix@ietf.org; Fri, 08 Dec 2006 05:57:07 -0500 X-ASG-Debug-ID: 1165575402-04bc00460000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: primary.hitachi-eu.net[193.39.225.234] X-Barracuda-Start-Time: 1165575402 X-ASG-Whitelist: Client Received: from mhd-esafe-int.hitachi-eu.com (primary.hitachi-eu.net [193.39.225.234]) by gatekeeper.hitachi-eu.com (Spam Firewall) with SMTP id BCFF53C513 for ; Fri, 8 Dec 2006 10:56:42 +0000 (GMT) Received: from MHDEXC99.adhel.hitachi-eu.com ([IP=193.39.227.52]) by eSafe SMTP Relay 1165510268; Fri Dec 8 10:56:42 2006 Received: from mhdexc02.adhel.hitachi-eu.com ([193.39.227.51]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 10:56:42 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Re: Specific Properties Date: Fri, 8 Dec 2006 10:55:47 -0000 Message-ID: <3167F18F59B81B4888A4D4C0A1717DD6670F9C@mhdexc02.adhel.hitachi-eu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Specific Properties Thread-Index: Accat2ra6T4XpMxDRiy6QQCTMINACQ== From: "Boschi, Elisa" To: X-OriginalArrivalTime: 08 Dec 2006 10:56:42.0229 (UTC) FILETIME=[8B550250:01C71AB7] X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: ipfix@ietf.org Subject: [IPFIX] Re: Specific Properties X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1299350091==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1299350091== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71AB7.8B0F506C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71AB7.8B0F506C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andrew Johnson wrote: >> ... > >> "...The rows are then referenced by the Specific Properties by using t= he appropriate value for the Common Properties identifier." >> and >> "... The rows are then referenced by Data Records by using the approp= riate value for the Common Properties identifier." >> >> do not mean the same thing and can be confusing. >> >> Specific Properties are just a subset of the Data Record's fields, a s= ubset which is complementary to the Common Properties > > > OK, this is where I have a problem. As I keep explaining, a Data > Record has a very specific definition. It is defined by an IPFIX > Template and is sent by and Exporting Process to a Collecting Process. > > The Reducing Redundancy feature is applied to a Flow (or packet data) > BEFORE it is exported. Therefore you don't have a Data Record at > this point. but when you start exporting you have two different ones: one Data Record= for the Common Properties and one Data Record for the Specific Propertie= s. So using "Data Record" in: "... The rows are then referenced by Data Records by using the appropriat= e value for the Common Properties identifier." doesn't help people understanding that the rows are referenced by the Dat= a Records exporting the Specific Properties by.... >> >> I think it makes the whole draft clearer and easier to understand. Spe= cific Properties are complementary to Common Properties, everything has a= name... >> we will not have to use things like "fileds of the Data Record which a= re not Part of the Common Properties"... > > > Why does it need a name, or more specifically a Name? The terminology > section of the draft already runs to 6 pages! That's about 25% of the > whole document, including boilerplate and detailed examples. this is not a reason for removing a (one!) useful definition. Elisa *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* ------_=_NextPart_001_01C71AB7.8B0F506C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Specific Properties

Andrew Johnson wrote:

>> ...
>
>> "...The rows are then referenced by the Specific Properties= by using the appropriate value for the Common Properties identifier.&quo= t;
>> and
>>  "... The rows are then referenced by Data Records by = using the appropriate value for the Common Properties identifier." >>
>> do not mean the same thing and can be confusing.
>>
>> Specific Properties are just a subset of the Data Record's field= s, a subset which is complementary to the Common Properties
>
>
> OK, this is where I have a problem.  As I keep explaining, a Da= ta
> Record has a very specific definition.  It is defined by an IPF= IX
> Template and is sent by and Exporting Process to a Collecting Proces= s.
>
> The Reducing Redundancy feature is applied to a Flow (or packet data= )
> BEFORE it is exported.  Therefore you don't have a Data Record = at
> this point.


but when you start exporting you have two different ones: one Data Record= for the Common Properties and one Data Record for the Specific Propertie= s. So using "Data Record" in:

"... The rows are then referenced by Data Records by using the appro= priate value for the Common Properties identifier."

doesn't help people understanding that the rows are referenced by the Dat= a Records exporting the Specific Properties by....


>>
>> I think it makes the whole draft clearer and easier to understan= d. Specific Properties are complementary to Common Properties, everything= has a name...
>> we will not have to use things like "fileds of the Data Rec= ord which are not Part of the Common Properties"...
>
>
> Why does it need a name, or more specifically a Name?  The term= inology
> section of the draft already runs to 6 pages!  That's about 25%= of the
> whole document, including boilerplate and detailed examples.


this is not a reason for removing a (one!) useful definition.

Elisa

 

*************************************************************************=
*************************
=20
 E-mail Confidentiality Notice and Disclaimer.
=20
  This email and any files transmitted with it are confidential and are i=
ntended solely for=20
the use of the individual or entity to which they are addressed. Access t=
o this e-mail by=20
anyone else is unauthorised. If you are not the intended recipient, any d=
isclosure,=20
copying, distribution or any action taken or omitted to be taken in relia=
nce on it, is=20
prohibited.=20
  E-mail messages are not necessarily secure.  Hitachi does not accept re=
sponsibility=20
for any changes made to this message after it was sent.=20
  Please note that Hitachi checks outgoing e-mail messages for the presen=
ce of=20
computer viruses.

*************************************************************************=
*************************
------_=_NextPart_001_01C71AB7.8B0F506C-- --===============1299350091== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1299350091==-- From ipfix-bounces@ietf.org Fri Dec 08 07:10:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GseXd-0008EP-6w; Fri, 08 Dec 2006 07:09:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GseXc-0008DV-AQ for ipfix@ietf.org; Fri, 08 Dec 2006 07:09:24 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GseXa-0003Yz-W3 for ipfix@ietf.org; Fri, 08 Dec 2006 07:09:24 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Dec 2006 13:09:23 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB8C9Mia019431; Fri, 8 Dec 2006 13:09:22 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB8C9LAJ021325; Fri, 8 Dec 2006 13:09:21 +0100 (MET) Received: from [10.61.65.30] (ams3-vpn-dhcp286.cisco.com [10.61.65.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA15116; Fri, 8 Dec 2006 12:09:20 GMT Message-ID: <457955D2.4080302@cisco.com> Date: Fri, 08 Dec 2006 12:08:50 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Boschi, Elisa" References: <3167F18F59B81B4888A4D4C0A1717DD6670F9C@mhdexc02.adhel.hitachi-eu.com> In-Reply-To: <3167F18F59B81B4888A4D4C0A1717DD6670F9C@mhdexc02.adhel.hitachi-eu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2043; t=1165579762; x=1166443762; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20Specific=20Properties |Sender:=20; bh=qYMYiBqJSynDT7CHb8tp8yXc0JDfFAJLkBHwpwfNvoI=; b=Se2mDgnYUpag5KFs+30XocGKr3ltlh3cY7A3wh6emU57/B8TNKR33k/EOxxDJlw+uDK2ozGg oKnAKnBd/GoFkDz1mVUvln/+sVNzOe2nuohsxRHicsHHoEALqxUowOkF; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ipfix@ietf.org Subject: [IPFIX] Re: Specific Properties X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Boschi, Elisa wrote: [SNIP] > > OK, this is where I have a problem. As I keep explaining, a Data > > Record has a very specific definition. It is defined by an IPFIX > > Template and is sent by and Exporting Process to a Collecting Process. > > > > The Reducing Redundancy feature is applied to a Flow (or packet data) > > BEFORE it is exported. Therefore you don't have a Data Record at > > this point. > > > but when you start exporting you have two different ones: one Data > Record for the Common Properties and one Data Record for the Specific > Properties. So using "Data Record" in: > > "... The rows are then referenced by Data Records by using the > appropriate value for the Common Properties identifier." > > doesn't help people understanding that the rows are referenced by the > Data Records exporting the Specific Properties by.... On a side note, with Cascading Common Properties we can see that a Data Record with either Flow data or option data can contain a cpID. I know this isn't really what we're discussing here though. My point is that you keep referring to the Data Record as something that exists before export. I really don't mind how you describe the Data Records that are being used to export the specific properties of the Flow data, as long as it is clear and accurate. > >> I think it makes the whole draft clearer and easier to understand. > Specific Properties are complementary to Common Properties, everything > has a name... > >> we will not have to use things like "fileds of the Data Record which > are not Part of the Common Properties"... > > > > > > Why does it need a name, or more specifically a Name? The terminology > > section of the draft already runs to 6 pages! That's about 25% of the > > whole document, including boilerplate and detailed examples. > > this is not a reason for removing a (one!) useful definition. I just don't think it is a useful definition, but I don't feel that strongly. Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Dec 08 07:10:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GseXd-0008EP-6w; Fri, 08 Dec 2006 07:09:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GseXc-0008DV-AQ for ipfix@ietf.org; Fri, 08 Dec 2006 07:09:24 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GseXa-0003Yz-W3 for ipfix@ietf.org; Fri, 08 Dec 2006 07:09:24 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Dec 2006 13:09:23 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB8C9Mia019431; Fri, 8 Dec 2006 13:09:22 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB8C9LAJ021325; Fri, 8 Dec 2006 13:09:21 +0100 (MET) Received: from [10.61.65.30] (ams3-vpn-dhcp286.cisco.com [10.61.65.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA15116; Fri, 8 Dec 2006 12:09:20 GMT Message-ID: <457955D2.4080302@cisco.com> Date: Fri, 08 Dec 2006 12:08:50 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Boschi, Elisa" References: <3167F18F59B81B4888A4D4C0A1717DD6670F9C@mhdexc02.adhel.hitachi-eu.com> In-Reply-To: <3167F18F59B81B4888A4D4C0A1717DD6670F9C@mhdexc02.adhel.hitachi-eu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2043; t=1165579762; x=1166443762; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20Specific=20Properties |Sender:=20; bh=qYMYiBqJSynDT7CHb8tp8yXc0JDfFAJLkBHwpwfNvoI=; b=Se2mDgnYUpag5KFs+30XocGKr3ltlh3cY7A3wh6emU57/B8TNKR33k/EOxxDJlw+uDK2ozGg oKnAKnBd/GoFkDz1mVUvln/+sVNzOe2nuohsxRHicsHHoEALqxUowOkF; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ipfix@ietf.org Subject: [IPFIX] Re: Specific Properties X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Boschi, Elisa wrote: [SNIP] > > OK, this is where I have a problem. As I keep explaining, a Data > > Record has a very specific definition. It is defined by an IPFIX > > Template and is sent by and Exporting Process to a Collecting Process. > > > > The Reducing Redundancy feature is applied to a Flow (or packet data) > > BEFORE it is exported. Therefore you don't have a Data Record at > > this point. > > > but when you start exporting you have two different ones: one Data > Record for the Common Properties and one Data Record for the Specific > Properties. So using "Data Record" in: > > "... The rows are then referenced by Data Records by using the > appropriate value for the Common Properties identifier." > > doesn't help people understanding that the rows are referenced by the > Data Records exporting the Specific Properties by.... On a side note, with Cascading Common Properties we can see that a Data Record with either Flow data or option data can contain a cpID. I know this isn't really what we're discussing here though. My point is that you keep referring to the Data Record as something that exists before export. I really don't mind how you describe the Data Records that are being used to export the specific properties of the Flow data, as long as it is clear and accurate. > >> I think it makes the whole draft clearer and easier to understand. > Specific Properties are complementary to Common Properties, everything > has a name... > >> we will not have to use things like "fileds of the Data Record which > are not Part of the Common Properties"... > > > > > > Why does it need a name, or more specifically a Name? The terminology > > section of the draft already runs to 6 pages! That's about 25% of the > > whole document, including boilerplate and detailed examples. > > this is not a reason for removing a (one!) useful definition. I just don't think it is a useful definition, but I don't feel that strongly. Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Dec 08 11:50:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsiv1-0001hu-QM; Fri, 08 Dec 2006 11:49:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsiv0-0001hp-A1 for ipfix@ietf.org; Fri, 08 Dec 2006 11:49:50 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsiuy-0000UD-MC for ipfix@ietf.org; Fri, 08 Dec 2006 11:49:50 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB8GnlX11726; Fri, 8 Dec 2006 17:49:47 +0100 (CET) Received: from [10.61.82.61] (ams3-vpn-dhcp4670.cisco.com [10.61.82.61]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB8GnjW17146; Fri, 8 Dec 2006 17:49:45 +0100 (CET) Message-ID: <457997A9.6010007@cisco.com> Date: Fri, 08 Dec 2006 17:49:45 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> <45780A37.8010905@cisco.com> <45782D40.20002@cisco.com> In-Reply-To: <45782D40.20002@cisco.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 6cd8fc1d6dcaba68c469f2b19d025c8c Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1345538163==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1345538163== Content-Type: multipart/alternative; boundary="------------030905050204070400070808" This is a multi-part message in MIME format. --------------030905050204070400070808 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Andrew, > Benoit Claise wrote: >> Andrew, > [SNIP] >>> My concern wasn't really directed at the draft itself, but just the >>> name "common properties". From IPFIX-PROTO: >>> "A Flow is defined as a set of IP packets passing an Observation >>> Point in the network during a certain time interval. All packets >>> belonging to a particular Flow have a set of common properties." >>> >>> And then from IPFIX-INFO: >>> Description of commonPropertiesId: >>> An identifier of a set of common properties that is unique per >>> Observation Domain. Typically, this Information Element is used >>> to link to information reported in separate records. >>> >>> The terminology is almost identical. The commonPropertiesId refers >>> to "a set of common properties" that is quite different from ones >>> that determine a Flow. >> >> What about something such as? >> Description of commonPropertiesId: >> An identifier of a set of common properties between different >> Flows. >> The that is unique per Observation Domain. Typically, this >> Information Element is used >> to link to information reported in separate records. > > I suggested something quite similar to Elisa: > An identifier of a set of properties that is common across more > that one Flow. Typically, this Information Element is used to > link to information reported in separate records. The identifier > is unique per Transport Session and Observation Domain. Agreed. I actually saw Elisa's email after I proposed this :( One small correction though, after re-reading the Flow and Flow Record definitions. We should be using The commonPropertiesID is an identifier of a set of common properties that is locally unique per Observation Domain and Transport Session. Typically, this Information Element is used to link to information reported in separate _Data Records_. > > >>>>> Is there any need to define a new term for "Specific >>>>> Properties"? These are just part of a normal Data Record. >>>>> For example: >>>>> "... The rows are then referenced by the Specific Properties >>>>> by using the appropriate value for the Common Properties >>>>> identifier." >>>>> >>>>> could simply be: >>>>> "... The rows are then referenced by Data Records by >>>>> using the appropriate value for the Common Properties >>>>> identifier." >>>> >>>> In your example, the "Data Records" doesn't mean the full data >>>> records before applying the redundancy reduction mechanism but only >>>> a part of it. >>>> So it might be confusing... That's the trick we found. >>>> >>>> However, I could agree that the draft would work without a formal >>>> (upper case) definition.... So do you have the same idea for the >>>> Common Properties? >>> >>> Considering there is a commonPropertiesID, I am quite happy with you >>> referring to Common Properties. >> >> Ok. So let's see how the draft looks like if we remove the "Specific >> Properties" formal definition but if we keep the "Common Properties" >> one. > > Sounds good. I went through the process of trying "Specific Properties" into "specific properties" and I have to admit that some of the sentences and figures look strange and even sometimes misleading. For example, "Common and specific Properties" is strange. So I have to agree with Elisa with keeping the definition in order to clarify the document. Anyway you replied in your last email "I just don't think it is a useful definition, but I don't feel that strongly.". So I think we can close this one. > > >>> There seems to be a bit of a conceptual difference here though. You >>> seem to imagine that an Exporting Process has a set of IPFIX Data >>> Records which it then applies some processing to to get some new >>> special IPFIX Data Records and some Common Property options. The >>> original set of Data Records may never actually exist, depending on >>> how the scheme is implemented. >> >> Sure, this is an implementation detail, but conceptually, we want to >> reduce "something". How do you call this "something"? > > There are already several names for the something. Most common is Flows > or data. Sometimes even "Flow Record" but I think that term is too > easily confused with "Data Record". Data Record has a very specific > meaning and is not what is meant here. A Data Record is defined by > an IPFIX Template. The Flows that are sent from the Metering Process > to the Exporting Process have no set format. Acknowledged. In the draft, I choose Flow Record, as the definitions say "The Metering Process generates Flow Records" I checked every occurrence of Data Record and Flow Record in the draft and you're right there are some minor corrections to be done. OLD Regardless of the fields content, flow records with common properties export the same fields in every single flow record. NEW Regardless of the fields content, flow records with common properties export the same fields in every single data record. OLD The Common Properties Flow Records MUST be sent on a reliable SCTP stream. NEW The Common Properties Data Records MUST be sent on a reliable SCTP stream. OLD The Collecting Process can either store the Flow Records as they arrive, without reconstructing the initial Flow Record, or reconstruct the initial Flow Record. NEW The Collecting Process can either store the Data Records as they arrive, without reconstructing the initial Flow Record, or reconstruct the initial Flow Record. OLD In addition there might be less storage capacity required at the Collector side if the Collector decides to store the Flow Records as they arrive, without reconstructing the initial Flow Record. NEW In addition there might be less storage capacity required at the Collector side if the Collector decides to store the Data Records as they arrive, without reconstructing the initial Flow Record. OLD: The assignment of Flow Records to common attributes could be done via the commonPropertiesID and alternatively via the templateID Information Element. NEW: The assignment of common attributes could be done via the commonPropertiesID and alternatively via the templateID Information Element. OLD On the other hand, these methods require additional resources on both the Exporter and the Collector. The Exporter has to manage Common Properties information and to assign commonPropertiesId values to Flow Records. NEW On the other hand, these methods require additional resources on both the Exporter and the Collector. The Exporter has to manage Common Properties information and to assign commonPropertiesId values. If you see some more required changes, let us know. For figures 2 to 6, I think the "record" should be "Data Record". Figure 2: Common and Specific Properties exported in the same record Figure 3: Common and Specific Properties exported in different records Figure 4: Common and Specific Properties exported in the same record Figure 5: Multiple Common (above) and Specific Properties (below) exported in different records Figure 6: Common and Specific Properties represented in one record Alternatively, if we want to avoid the term record or Data Record in figures, let's use the trick of figure 7: Figure 7: Common and Specific (packet) Properties exported separately So let's use "exported together" versus "exported separately" [SNIP] >>>>> Are they meaningful in IPFIX? i.e. per the PROTO will an option >>>>> with scope but no data be deemed invalidated by the Collector. >>>>> Scope without data is the same as never having recieved the >>>>> mapping in the first place. I think that it would be up to the >>>>> implementation but it seems like a good idea so if we can't add >>>>> it to the PROTO can we put it in the implementation guidelines? >>>>> >>>>> How do you propose to withdraw common properties when they are >>>>> associated with a template rather than the Common Properties index? >>>> >>>> I don't ;) This is the reason why the use the Common Properties >>>> index is a cleaner design. >>> >>> I think withdrawal messages should work in general for options >>> data, so why not send an empty record with the template as scope? >> I guess that you wanted to say: >> I think withdrawal messages should work in general for options >> data, so why not send an empty record with the _common property_ >> as scope? >> Well, I prefer to have a clear design so that this draft is really >> independent, with its withdrawal mechanism. > > Then using the template ID to identify Common Properties can be > mentioned in passing, which I guess it is, in 8.3, however it is > also discussed in a little detail in section 4.1.1 (and figure 9), > and section 7. It seems that these details should be removed. I understand the issue that we put at the same level the common properties with commonPropertiesID and with templateID, while we don't speak about the template withdrawal in this draft. Here is a proposal: We remove the templateID from section 3 and 4, we put it into section "8.3 commonPropertiesID vs. TemplateID scope" And we mention in that paragraph that: - the template withdrawal, as specified in [IPFIX-PROTO], can be used to withdraw Template - the template ID could be used for common properties if the common properties remain constant for the live of the template. Otherwise we enter into some problems such as: what's happening when we want to change the common properties in the template. - that we don't need template withdrawal in this is case, as the template withdrawal is covered by [IPFIX-PROTO] already. - If the Template is withdrawn then the associated data is invalid too. > > >> Otherwise, you're telling in this I-RFC the standard track IPFIX >> protocol should consider an empty record as a withdrawal. This could >> be true a true assumption, but this is not clearly explained/specified! > > Not at all. Either withdrawing options in this way is valid in IPFIX, > in which case Reducing Redundancy can use it, or it a valid technique > for anybody. Now I'm not declaring that this is a technique for all > is within the scope of the draft. If red-red is going to use this > technique though we should decide in the WG that it is valid and say > so in the implementation guidelines or the "Managing Scope" draft. > > >>>>> 4. Specifications for bandwidth saving information export >>>>> >>>>> What is being specified here that isn't true for ALL options as >>>>> described in IPFIX-PROTO? >>>> >>>> What do you suggest? >>> >>> Well it seems that section three really explains almost the same >>> thing 3 times. The section 4 explains most of it again (with a >>> bit more info) another 3 times. >>> >>> I would prefer section 3 to simply explain the technique. Walk >>> through how the information from a Flow is split into two parts, >>> and then add the bit from section 4 how these two parts are >>> exported. >>> >>> Using more than one CPid in a record should be part of the >>> advanced techniques once the basics are made clear. Per packet >>> should just be a detailed example at the end. >>> >>>>> I think section 3 does a better job of explaining how all this >>>>> works. I'm really not sure what section 4 adds. >>>> >>>> The idea was to put the specs in section 4 while the section 3 was >>>> the high level solution. >>> >>> Rereading it, I see that now, but there seems to be a fair amount >>> of repetition. >> >> Let me ask the question differently. Do you see this repetition as >> problem? > > Yes. I think the draft would be cleared if how options work was left > to IPFIX-PROTO. red-red should reference that, then build describe > exactly how the basic Common Properties work for the simple case, from > concept to execution. You should be speaking about the beginning of section 4. As many clarifications to the scope concept had to be made on the mailing list, we thought that adding this extra paragraph of explanations would benefit the readers... > > The other variations on this can then build upon the proper foundation > of the simple case. This way the reader can understand how the system > works before you introduce the concept of including more than one > commonPropertiesId in a Template/Data Record. > > > [SNIP] >>>>> The text reads: >>>>> Common Properties IDs are unique per SCTP association and per >>>>> Observation Domain. If the Collecting Process receives a common >>>>> Properties ID which has already been received but which has not >>>>> previously been withdrawn (i.e. a commonPropertiesID from the same >>>>> Exporter Observation Domain with the same Template ID received on >>>>> the SCTP association), then the Collecting Process MUST shutdown >>>>> the association. >>>> This is similar to [IPFIX-PROTO] >>>> >>>> Template IDs are unique per SCTP association and per Observation >>>> Domain. If the Collecting Process receives a Template which has >>>> already been received but which has not previously been >>>> withdrawn (i.e. a Template Record from the same Exporter >>>> Observation Domain with the same Template ID received on the >>>> SCTP association), then the Collecting Process MUST shutdown the >>>> association. >>>> >>>>> >>>>> and: >>>>> If the Collecting Process receives a Common Properties Withdrawal >>>>> message for a Common Properties that it has not received before on >>>>> this SCTP assocation, it MUST reset the SCTP association, discard >>>>> the IPFIX Message, and SHOULD log the error as it does for >>>>> malformed IPFIX Messages. >>>>> I think this might go against IPFIX-PROTO. >>>> This is similar to [IPFIX-PROTO] >>> >>> These are similar to what IPFIX-PROTO says about templates, but that >>> doesn't mean the text can just be used to talk about Data Records sent >>> for Options Templates. >>> >>> Option data withdrawal messages are not mentioned in IPFIX-PROTO, >>> although I think they can work. However, in general options data with >>> the same scope as an earlier record will just overwrite the older >>> record. >> >> See my previous remark about an independent draft. > > What? > > AFAIK red-red is an information draft aimed at explaining how a technique > you can use with an IPFIX compliant Exporter/Collector. > IPFIX-PROTO says > nothing about withdrawing options data and if this draft says: > If the Collecting Process receives a common Properties ID which has > already been received but which has not previously been withdrawn ... > then the Collecting Process MUST shutdown the association. > Then it is expanding on what IPFIX-PROTO says and is no longer just a > way of using IPFIX but an extension to it. > If we accept that withdrawing > options is part of IPFIX today then this is about the only extension > being asked for. > > I can see why you want it, but the problem you are trying to solve here > is the same for ALL options, not just Common Property definitions. This draft, even if this will be an Informational RFC, is an extension on how to use IPFIX in this particular case of redundancy reduction. So, yes, this draft can be more specific. We're trying to solve the only case of the Common Property. > > > [SNIP] >> In this draft, we require a mechanism such as the following: >> "If the Common Properties are not refreshed before that lifetime >> has expired, the Collecting Process MUST discard the >> corresponding definition of the commonPropertiesID and any current >> and future associated Data Records. In which case, an alarm MUST be >> logged. " > > Why is it required for common properties and not other options? There are differences between the data records sent by option data record. Example1: NetFlow V9 exports the ifIndex, IfDescr matchings in Option Template Records Example2: We could think to export the refresh timeout in Option Template Records Example3: The Common Properties ID for redundancy reduction. Even if the 3 examples use Option Template Records, the fundamental difference is in the meaning of the I.E.s: - example 1 and 2 contain I.E.s that are self explaining: they mean something by themselves. We don't need those for the data records to be meaningfull - example 3: the Common Properties ID MUST be present in order to decode the initial Flow Record This implies that: 1. we can't treat all options template record the same way. 2. "If the Common Properties are not refreshed before that lifetime has expired, the Collecting Process MUST discard the corresponding definition of the commonPropertiesID and any current and future associated Data Records. In which case, an alarm MUST be logged. " > Why is it ok to use a mechanism that is not part of the protocol? Because this draft is an extension. If we didn't have to specify some more specifications compared to [IPFIX-PROTO], then an extra example in [IPFIX-AS] would be enough. > >> Because there is no withdraw message with UDP: >> " If UDP is selected as the transport protocol, the commonPropertiesID >> Template Withdraw Messages MUST not be used, as this method is >> inefficient due to the unreliable nature of UDP." >> So I'm wondering why we are discussing this? > > Because you're trying to extend the protocol because you don't think > it's good enough. While I agree that the protocol could do a better > job of handling options, I think this extension is out of scope of > the draft. > > > > > >> Q: Furthermore you shouldn't dictate the the record is discarded, >> just because you >> can't tell a piece of potentially trivial information about a flow >> doesn't mean it's meaningless. >> A: without the Common Properties, we can't decode the records. So we >> must discard them > > Surely that depends on what the Common Properties show. Perhaps the > particular properties that are common aren't important. Similarly, > if a normal full Data Record was received without something the > exporter thought was necessary, it could be discarded. Exactly, this is the reason why I made a distinction between the different examples in my previous comment. > > >> Q: The Common Properties in question could be anything. >> A: I think we should limit this draft to Common Properties > > It wasn't a question and your answer makes no sense. I'm saying > that the properties defined by a particular cpID could be something > that is not important to the Collector. Perhaps it's the > classOfService field and the collector doesn't use it. We agree, aren't we? See my previous remark (example 1 and 2) Regards, Benoit. --------------030905050204070400070808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-bru.cisco.com id kB8GnlX11726 Andrew,
Benoit Claise wrote:
Andrew,
[SNIP]
My concern wasn't really directed at the draft itself, but just the
name "common properties".=C2=A0 From IPFIX-PROTO:
=C2=A0"A Flow is defined as a set of IP packets passing an Observation=C2= =A0=C2=A0 Point in the network during a certain time interval.=C2=A0 All packets=C2= =A0=C2=A0 belonging to a particular Flow have a set of common properties."

And then from IPFIX-INFO:
=C2=A0 Description of commonPropertiesId:
=C2=A0=C2=A0=C2=A0=C2=A0 An identifier of a set of common properties that= is unique per
=C2=A0=C2=A0=C2=A0=C2=A0 Observation Domain.=C2=A0 Typically, this Inform= ation Element is used
=C2=A0=C2=A0=C2=A0=C2=A0 to link to information reported in separate reco= rds.

The terminology is almost identical.=C2=A0 The commonPropertiesId refers
to "a set of common properties" that is quite different from ones
that determine a Flow.

What about something such as?
Description of commonPropertiesId:
=C2=A0=C2=A0=C2=A0=C2=A0 An identifier of a set of common properties betw= een different Flows.
=C2=A0=C2=A0=C2=A0=C2=A0 The that is unique per Observation Domain. =C2=A0= =C2=A0=C2=A0=C2=A0 Typically, this Information Element is used
=C2=A0=C2=A0=C2=A0=C2=A0 to link to information reported in separate reco= rds.

I suggested something quite similar to Elisa:
=C2=A0An identifier of a set of properties that is common across more
=C2=A0that one Flow.=C2=A0 Typically, this Information Element is used to
=C2=A0link to information reported in separate records.=C2=A0 The identif= ier
=C2=A0is unique per Transport Session and Observation Domain.
Agreed. I actually saw Elisa's email after I proposed this :(
One small correction though, after re-reading the Flow and Flow Record definitions.
We should be using 
The commonPropertiesID is an identifier of a set of comm=
on properties
that is locally unique per Observation Domain and Transport Session.
Typically, this Information Element is used to link to information
reported in separate Data Records.


Is there any need to define a new term for "Specific
Properties"? These are just part of a normal Data Record.
For example:
"... The rows are then referenced by the Specific Properties
by using the appropriate value for the Common Properties
identifier."

could simply be:
"... The rows are then referenced by Data Records by
using the appropriate value for the Common Properties
identifier."

In your example, the "Data Records" doesn't mean the full data records before applying the redundancy reduction mechanism but only a part of it.
So it might be confusing... That's the trick we found.

However, I could agree that the draft would work without a formal (upper case) definition.... So do you have the same idea for the Common Properties?

Considering there is a commonPropertiesID, I am quite happy with you
referring to Common Properties.

Ok. So let's see how the draft looks like if we remove the "Specific Properties" formal definition but if we keep the "Common Properties" one.

Sounds good.
I went through the process of trying "Specific Properties" into "specific properties" and I have to admit that some of the sentences and figures look strange and even sometimes misleading. For example, "Common and specific Properties" is strange. So I have to agree with Elisa with keeping the definition in order to clarify the document. Anyway you replied in your last email "I just don't think it is a useful definition, but I don't feel that strongly.". So I think we can close this one.


There seems to be a bit of a conceptual difference here though.=C2=A0 You
seem to imagine that an Exporting Process has a set of IPFIX Data
Records which it then applies some processing to to get some new
special IPFIX Data Records and some Common Property options.=C2=A0 The
original set of Data Records may never actually exist, depending on
how the scheme is implemented.

Sure, this is an implementation detail, but conceptually, we want to reduce "something". How do you call this "something"?

There are already several names for the something.=C2=A0 Most common is Flows
or data.=C2=A0 Sometimes even "Flow Record" but I think that term is too
easily confused with "Data Record".=C2=A0 Data Record has a very specific
meaning and is not what is meant here.=C2=A0 A Data Record is defined by
an IPFIX Template.=C2=A0 The Flows that are sent from the Metering Proces= s
to the Exporting Process have no set format.
Acknowledged.
In the draft, I choose Flow Record, as the definitions say "The Metering Process generates Flow Records"
I checked every occurrence of Data Record and Flow Record in the draft and you're right there are some minor corrections to be done.
OLD
   Regardless of the fields content, flow records with common=20
   properties export the same fields in every single flow record.=20
NEW
   Regardless of the fields content, flow records with common=20
   properties export the same fields in every single data record.=20

OLD
   The Common Properties Flow Records MUST be sent on a reliable SCTP=20
   stream.=20
NEW
   The Common Properties Data Records MUST be sent on a reliable SCTP=20
   stream.=20

OLD
   The Collecting Process can either store the Flow Records as they=20
   arrive, without reconstructing the initial Flow Record, or
   reconstruct the initial Flow Record.
NEW
   The Collecting Process can either store the Data Records as they=20
   arrive, without reconstructing the initial Flow Record, or
   reconstruct the initial Flow Record.

OLD
   In addition there=20
   might be less storage capacity required at the Collector side if the=20
   Collector decides to store the Flow Records as they arrive, without=20
   reconstructing the initial Flow Record. =20
NEW
   In addition there=20
   might be less storage capacity required at the Collector side if the=20
   Collector decides to store the Data Records as they arrive, without=20
   reconstructing the initial Flow Record.

OLD:   =20
   The assignment of Flow Records to common attributes could be done=20
   via the commonPropertiesID and alternatively via the templateID=20
   Information Element. =C2=A0=20
NEW:   =20
   The assignment of common attributes could be done=20
   via the commonPropertiesID and alternatively via the templateID=20
   Information Element.=20

OLD
   On the other hand, these methods require additional resources on=20
   both the Exporter and the Collector.  The Exporter has to manage=20
   Common Properties information and to assign commonPropertiesId=20
   values to Flow Records.=20
NEW=20
   On the other hand, these methods require additional resources on=20
   both the Exporter and the Collector.  The Exporter has to manage=20
   Common Properties information and to assign commonPropertiesId=20
   values.=20
=20
If you see some more required changes, let us know.

For figures 2 to 6, I think the "record" should be "Data Record".
  =C2=A0Figure 2: Common and Specific Properties exported in the same rec=
ord=20
   Figure 3: Common and Specific Properties exported in different records=
   =20
   Figure 4: Common and Specific Properties exported in the same record=20
   Figure 5: Multiple Common (above) and Specific Properties (below)=20
   exported in different records=20
   Figure 6: Common and Specific Properties represented in one record
Alternatively, if we want to avoid the term record or Data Record in figu=
res, let's use the trick of figure 7:=20
   Figure 7: Common and Specific (packet) Properties exported=20
   separately=20
So let's use "exported together" versus "exported separately"
[SNIP]
Are they meaningful in IPFIX? i.e. per the PROTO will an option
with scope but no data be deemed invalidated by the Collector.
Scope without data is the same as never having recieved the
mapping in the first place. I think that it would be up to the
implementation but it seems like a good idea so if we can't add
it to the PROTO can we put it in the implementation guidelines?

How do you propose to withdraw common properties when they are
associated with a template rather than the Common Properties index?

I don't ;) This is the reason why the use the Common Properties index is a cleaner design.

I think withdrawal messages should work in general for options
data, so why not send an empty record with the template as scope?
I guess that you wanted to say:
=C2=A0=C2=A0=C2=A0 I think withdrawal messages should work in general for= options
=C2=A0=C2=A0=C2=A0 data, so why not send an empty record with the _common= property_ as scope?
Well, I prefer to have a clear design so that this draft is really independent, with its withdrawal mechanism.

Then using the template ID to identify Common Properties can be
mentioned in passing, which I guess it is, in 8.3, however it is
also discussed in a little detail in section 4.1.1 (and figure 9),
and section 7.=C2=A0 It seems that these details should be removed.
I understand the issue that we put at the same level the common properties with commonPropertiesID and with templateID, while we don't speak about the template withdrawal in this draft.
Here is a proposal:
We remove the templateID from section 3 and 4, we put it into section "8.3 commonPropertiesID vs. TemplateID scope"
And we mention in that paragraph that:
- the template withdrawal, as specified in [IPFIX-PROTO], can be used to withdraw Template
- the template ID could be used for common properties if the common properties remain constant for the live of the template.
=C2=A0 Otherwise we enter into some problems such as: what's happening wh= en we want to change the common properties in the template.
- that we don't need template withdrawal in this is case, as the template withdrawal is covered by [IPFIX-PROTO] already.
- If the Template is withdrawn then the associated data is invalid too.


Otherwise, you're telling in this I-RFC the standard track IPFIX protocol should consider an empty record as a withdrawal. This could be true a true assumption, but this is not clearly explained/specified!

Not at all.=C2=A0 Either withdrawing options in this way is valid in IPFI= X,
in which case Reducing Redundancy can use it, or it a valid technique
for anybody.=C2=A0 Now I'm not declaring that this is a technique for all
is within the scope of the draft.=C2=A0 If red-red is going to use this
technique though we should decide in the WG that it is valid and say
so in the implementation guidelines or the "Managing Scope" draft.


4. Specifications for bandwidth saving information export

What is being specified here that isn't true for ALL options as
described in IPFIX-PROTO?

What do you suggest?

Well it seems that section three really explains almost the same
thing 3 times.=C2=A0 The section 4 explains most of it again (with a
bit more info) another 3 times.

I would prefer section 3 to simply explain the technique.=C2=A0 Walk
through how the information from a Flow is split into two parts,
and then add the bit from section 4 how these two parts are
exported.

Using more than one CPid in a record should be part of the
advanced techniques once the basics are made clear.=C2=A0 Per packet
should just be a detailed example at the end.

I think section 3 does a better job of explaining how all this
works. I'm really not sure what section 4 adds.

The idea was to put the specs in section 4 while the section 3 was the high level solution.

Rereading it, I see that now, but there seems to be a fair amount
of repetition.

Let me ask the question differently. Do you see this repetition as problem?

Yes.=C2=A0 I think the draft would be cleared if how options work was lef= t
to IPFIX-PROTO.=C2=A0 red-red should reference that, then build describe
exactly how the basic Common Properties work for the simple case, from
concept to execution.
You should be speaking about the beginning of section 4.
As many clarifications to the scope concept had to be made on the mailing list, we thought that adding this extra paragraph of explanations would benefit the readers...

The other variations on this can then build upon the proper foundation
of the simple case.=C2=A0 This way the reader can understand how the syst= em
works before you introduce the concept of including more than one
commonPropertiesId in a Template/Data Record.


[SNIP]
The text reads:
Common Properties IDs are unique per SCTP association and per Observation Domain. If the Collecting Process receives a common Properties ID which has already been received but which has not previously been withdrawn (i.e. a commonPropertiesID from the same Exporter Observation Domain with the same Template ID received on the SCTP association), then the Collecting Process MUST shutdown the association.
This is similar to [IPFIX-PROTO]

=C2=A0Template IDs are unique per SCTP association and per Observation=C2= =A0 =C2=A0Domain.=C2=A0 If the Collecting Process receives a Template which h= as=C2=A0 =C2=A0already been received but which has not previously been withdrawn=C2= =A0=C2=A0=C2=A0 (i.e. a Template Record from the same Exporter Observation Domain=C2=A0=C2= =A0=C2=A0=C2=A0 with the same Template ID received on the SCTP association), then=C2=A0=C2= =A0=C2=A0 the Collecting Process MUST shutdown the association.


and:
If the Collecting Process receives a Common Properties Withdrawal message for a Common Properties that it has not received before on this SCTP assocation, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error as it does for malformed IPFIX Messages.
I think this might go against IPFIX-PROTO.
This is similar to [IPFIX-PROTO]

These are similar to what IPFIX-PROTO says about templates, but that
doesn't mean the text can just be used to talk about Data Records sent
for Options Templates.

Option data withdrawal messages are not mentioned in IPFIX-PROTO,
although I think they can work.=C2=A0 However, in general options data wi= th
the same scope as an earlier record will just overwrite the older
record.

See my previous remark about an independent draft.

What?

AFAIK red-red is an information draft aimed at explaining how a technique
you can use with an IPFIX compliant Exporter/Collector.
IPFIX-PROT= O says
nothing about withdrawing options data and if this draft says:
=C2=A0If the Collecting Process receives a common Properties ID which has
=C2=A0already been received but which has not previously been withdrawn .= ..
=C2=A0then the Collecting Process MUST shutdown the association.
Then it is expanding on what IPFIX-PROTO says and is no longer just a
way of using IPFIX but an extension to it.
If we acce= pt that withdrawing
options is part of IPFIX today then this is about the only extension
being asked for.

I can see why you want it, but the problem you are trying to solve here
is the same for ALL options, not just Common Property definitions.

This draft, even if this will be an Informational RFC, is an extension on how to use IPFIX in this particular case of redundancy reduction.
So, yes, this draft can be more specific. We're trying to solve the only case of the Common Property.


[SNIP]
In this draft, we require a mechanism such as the following:
"If the Common Properties are not refreshed before that lifetime has=C2=A0= =C2=A0 expired, the Collecting Process MUST discard the corresponding=C2=A0=C2=A0 definition of the commonPropertiesID and any current and future=C2=A0=C2=A0 associated Data Records. In which case, an alarm MUST be logged. "

Why is it required for common properties and not other options?
There are differences between the data records sent by option data record.
Example1: NetFlow V9 exports the ifIndex, IfDescr matchings in Option Template Records
Example2: We could think to export the refresh timeout in Option Template Records
Example3: The Common Properties ID for redundancy reduction.
Even if the 3 examples use Option Template Records, the fundamental difference is in the meaning of the I.E.s:
=C2=A0=C2=A0=C2=A0 - example 1 and 2 contain I.E.s that are self explaini= ng: they mean something by themselves. We don't need those for the data records to be meaningfull
=C2=A0=C2=A0=C2=A0 - example 3: the Common Properties ID MUST be present = in order to decode the initial Flow Record
This implies that:
=C2=A0=C2=A0=C2=A0 1. we can't treat all options template record the same= way.
=C2=A0=C2=A0=C2=A0 2. "If the Common Properties are not refreshed before = that lifetime has expired, the Collecting Process MUST discard the corresponding definition of the commonPropertiesID and any current and future associated Data Records. In which case, an alarm MUST be logged. "

Why is it = ok to use a mechanism that is not part of the protocol?
Because this draft is an extension.
If we didn't have to specify some more specifications compared to [IPFIX-PROTO], then an extra example in [IPFIX-AS] would be enough.

Because there is no withdraw message with UDP:
" If UDP is selected as the transport protocol, the commonPropertiesID
=C2=A0 Template Withdraw Messages MUST not be used, as this method is
=C2=A0 inefficient due to the unreliable nature of UDP."
So I'm wondering why we are discussing this?

Because you're trying to extend the protocol because you don't think
it's good enough.=C2=A0 While I agree that the protocol could do a better
job of handling options, I think this extension is out of scope of
the draft.





Q: Furthermore you shouldn't dictate the the record is discarded, just because you
can't tell a piece of potentially trivial information about a flow
doesn't mean it's meaningless.
A: without the Common Properties, we can't decode the records. So we must discard them

Surely that depends on what the Common Properties show.=C2=A0 Perhaps the
particular properties that are common aren't important.=C2=A0 Similarly,
if a normal full Data Record was received without something the
exporter thought was necessary, it could be discarded.
Exactly, this is the reason why I made a distinction between the different examples in my previous comment.


Q: The Common Properties in question could be anything.
A: I think we should limit this draft to Common Properties

It wasn't a question and your answer makes no sense.=C2=A0 I'm saying
that the properties defined by a particular cpID could be something
that is not important to the Collector.=C2=A0 Perhaps it's the
classOfService field and the collector doesn't use it.
We agree, aren't we? See my previous remark (example 1 and 2)

Regards, Benoit.
--------------030905050204070400070808-- --===============1345538163== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1345538163==-- From ipfix-bounces@ietf.org Fri Dec 08 11:50:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsiv1-0001hu-QM; Fri, 08 Dec 2006 11:49:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsiv0-0001hp-A1 for ipfix@ietf.org; Fri, 08 Dec 2006 11:49:50 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsiuy-0000UD-MC for ipfix@ietf.org; Fri, 08 Dec 2006 11:49:50 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB8GnlX11726; Fri, 8 Dec 2006 17:49:47 +0100 (CET) Received: from [10.61.82.61] (ams3-vpn-dhcp4670.cisco.com [10.61.82.61]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kB8GnjW17146; Fri, 8 Dec 2006 17:49:45 +0100 (CET) Message-ID: <457997A9.6010007@cisco.com> Date: Fri, 08 Dec 2006 17:49:45 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> <45780A37.8010905@cisco.com> <45782D40.20002@cisco.com> In-Reply-To: <45782D40.20002@cisco.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 6cd8fc1d6dcaba68c469f2b19d025c8c Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1345538163==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1345538163== Content-Type: multipart/alternative; boundary="------------030905050204070400070808" This is a multi-part message in MIME format. --------------030905050204070400070808 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Andrew, > Benoit Claise wrote: >> Andrew, > [SNIP] >>> My concern wasn't really directed at the draft itself, but just the >>> name "common properties". From IPFIX-PROTO: >>> "A Flow is defined as a set of IP packets passing an Observation >>> Point in the network during a certain time interval. All packets >>> belonging to a particular Flow have a set of common properties." >>> >>> And then from IPFIX-INFO: >>> Description of commonPropertiesId: >>> An identifier of a set of common properties that is unique per >>> Observation Domain. Typically, this Information Element is used >>> to link to information reported in separate records. >>> >>> The terminology is almost identical. The commonPropertiesId refers >>> to "a set of common properties" that is quite different from ones >>> that determine a Flow. >> >> What about something such as? >> Description of commonPropertiesId: >> An identifier of a set of common properties between different >> Flows. >> The that is unique per Observation Domain. Typically, this >> Information Element is used >> to link to information reported in separate records. > > I suggested something quite similar to Elisa: > An identifier of a set of properties that is common across more > that one Flow. Typically, this Information Element is used to > link to information reported in separate records. The identifier > is unique per Transport Session and Observation Domain. Agreed. I actually saw Elisa's email after I proposed this :( One small correction though, after re-reading the Flow and Flow Record definitions. We should be using The commonPropertiesID is an identifier of a set of common properties that is locally unique per Observation Domain and Transport Session. Typically, this Information Element is used to link to information reported in separate _Data Records_. > > >>>>> Is there any need to define a new term for "Specific >>>>> Properties"? These are just part of a normal Data Record. >>>>> For example: >>>>> "... The rows are then referenced by the Specific Properties >>>>> by using the appropriate value for the Common Properties >>>>> identifier." >>>>> >>>>> could simply be: >>>>> "... The rows are then referenced by Data Records by >>>>> using the appropriate value for the Common Properties >>>>> identifier." >>>> >>>> In your example, the "Data Records" doesn't mean the full data >>>> records before applying the redundancy reduction mechanism but only >>>> a part of it. >>>> So it might be confusing... That's the trick we found. >>>> >>>> However, I could agree that the draft would work without a formal >>>> (upper case) definition.... So do you have the same idea for the >>>> Common Properties? >>> >>> Considering there is a commonPropertiesID, I am quite happy with you >>> referring to Common Properties. >> >> Ok. So let's see how the draft looks like if we remove the "Specific >> Properties" formal definition but if we keep the "Common Properties" >> one. > > Sounds good. I went through the process of trying "Specific Properties" into "specific properties" and I have to admit that some of the sentences and figures look strange and even sometimes misleading. For example, "Common and specific Properties" is strange. So I have to agree with Elisa with keeping the definition in order to clarify the document. Anyway you replied in your last email "I just don't think it is a useful definition, but I don't feel that strongly.". So I think we can close this one. > > >>> There seems to be a bit of a conceptual difference here though. You >>> seem to imagine that an Exporting Process has a set of IPFIX Data >>> Records which it then applies some processing to to get some new >>> special IPFIX Data Records and some Common Property options. The >>> original set of Data Records may never actually exist, depending on >>> how the scheme is implemented. >> >> Sure, this is an implementation detail, but conceptually, we want to >> reduce "something". How do you call this "something"? > > There are already several names for the something. Most common is Flows > or data. Sometimes even "Flow Record" but I think that term is too > easily confused with "Data Record". Data Record has a very specific > meaning and is not what is meant here. A Data Record is defined by > an IPFIX Template. The Flows that are sent from the Metering Process > to the Exporting Process have no set format. Acknowledged. In the draft, I choose Flow Record, as the definitions say "The Metering Process generates Flow Records" I checked every occurrence of Data Record and Flow Record in the draft and you're right there are some minor corrections to be done. OLD Regardless of the fields content, flow records with common properties export the same fields in every single flow record. NEW Regardless of the fields content, flow records with common properties export the same fields in every single data record. OLD The Common Properties Flow Records MUST be sent on a reliable SCTP stream. NEW The Common Properties Data Records MUST be sent on a reliable SCTP stream. OLD The Collecting Process can either store the Flow Records as they arrive, without reconstructing the initial Flow Record, or reconstruct the initial Flow Record. NEW The Collecting Process can either store the Data Records as they arrive, without reconstructing the initial Flow Record, or reconstruct the initial Flow Record. OLD In addition there might be less storage capacity required at the Collector side if the Collector decides to store the Flow Records as they arrive, without reconstructing the initial Flow Record. NEW In addition there might be less storage capacity required at the Collector side if the Collector decides to store the Data Records as they arrive, without reconstructing the initial Flow Record. OLD: The assignment of Flow Records to common attributes could be done via the commonPropertiesID and alternatively via the templateID Information Element. NEW: The assignment of common attributes could be done via the commonPropertiesID and alternatively via the templateID Information Element. OLD On the other hand, these methods require additional resources on both the Exporter and the Collector. The Exporter has to manage Common Properties information and to assign commonPropertiesId values to Flow Records. NEW On the other hand, these methods require additional resources on both the Exporter and the Collector. The Exporter has to manage Common Properties information and to assign commonPropertiesId values. If you see some more required changes, let us know. For figures 2 to 6, I think the "record" should be "Data Record". Figure 2: Common and Specific Properties exported in the same record Figure 3: Common and Specific Properties exported in different records Figure 4: Common and Specific Properties exported in the same record Figure 5: Multiple Common (above) and Specific Properties (below) exported in different records Figure 6: Common and Specific Properties represented in one record Alternatively, if we want to avoid the term record or Data Record in figures, let's use the trick of figure 7: Figure 7: Common and Specific (packet) Properties exported separately So let's use "exported together" versus "exported separately" [SNIP] >>>>> Are they meaningful in IPFIX? i.e. per the PROTO will an option >>>>> with scope but no data be deemed invalidated by the Collector. >>>>> Scope without data is the same as never having recieved the >>>>> mapping in the first place. I think that it would be up to the >>>>> implementation but it seems like a good idea so if we can't add >>>>> it to the PROTO can we put it in the implementation guidelines? >>>>> >>>>> How do you propose to withdraw common properties when they are >>>>> associated with a template rather than the Common Properties index? >>>> >>>> I don't ;) This is the reason why the use the Common Properties >>>> index is a cleaner design. >>> >>> I think withdrawal messages should work in general for options >>> data, so why not send an empty record with the template as scope? >> I guess that you wanted to say: >> I think withdrawal messages should work in general for options >> data, so why not send an empty record with the _common property_ >> as scope? >> Well, I prefer to have a clear design so that this draft is really >> independent, with its withdrawal mechanism. > > Then using the template ID to identify Common Properties can be > mentioned in passing, which I guess it is, in 8.3, however it is > also discussed in a little detail in section 4.1.1 (and figure 9), > and section 7. It seems that these details should be removed. I understand the issue that we put at the same level the common properties with commonPropertiesID and with templateID, while we don't speak about the template withdrawal in this draft. Here is a proposal: We remove the templateID from section 3 and 4, we put it into section "8.3 commonPropertiesID vs. TemplateID scope" And we mention in that paragraph that: - the template withdrawal, as specified in [IPFIX-PROTO], can be used to withdraw Template - the template ID could be used for common properties if the common properties remain constant for the live of the template. Otherwise we enter into some problems such as: what's happening when we want to change the common properties in the template. - that we don't need template withdrawal in this is case, as the template withdrawal is covered by [IPFIX-PROTO] already. - If the Template is withdrawn then the associated data is invalid too. > > >> Otherwise, you're telling in this I-RFC the standard track IPFIX >> protocol should consider an empty record as a withdrawal. This could >> be true a true assumption, but this is not clearly explained/specified! > > Not at all. Either withdrawing options in this way is valid in IPFIX, > in which case Reducing Redundancy can use it, or it a valid technique > for anybody. Now I'm not declaring that this is a technique for all > is within the scope of the draft. If red-red is going to use this > technique though we should decide in the WG that it is valid and say > so in the implementation guidelines or the "Managing Scope" draft. > > >>>>> 4. Specifications for bandwidth saving information export >>>>> >>>>> What is being specified here that isn't true for ALL options as >>>>> described in IPFIX-PROTO? >>>> >>>> What do you suggest? >>> >>> Well it seems that section three really explains almost the same >>> thing 3 times. The section 4 explains most of it again (with a >>> bit more info) another 3 times. >>> >>> I would prefer section 3 to simply explain the technique. Walk >>> through how the information from a Flow is split into two parts, >>> and then add the bit from section 4 how these two parts are >>> exported. >>> >>> Using more than one CPid in a record should be part of the >>> advanced techniques once the basics are made clear. Per packet >>> should just be a detailed example at the end. >>> >>>>> I think section 3 does a better job of explaining how all this >>>>> works. I'm really not sure what section 4 adds. >>>> >>>> The idea was to put the specs in section 4 while the section 3 was >>>> the high level solution. >>> >>> Rereading it, I see that now, but there seems to be a fair amount >>> of repetition. >> >> Let me ask the question differently. Do you see this repetition as >> problem? > > Yes. I think the draft would be cleared if how options work was left > to IPFIX-PROTO. red-red should reference that, then build describe > exactly how the basic Common Properties work for the simple case, from > concept to execution. You should be speaking about the beginning of section 4. As many clarifications to the scope concept had to be made on the mailing list, we thought that adding this extra paragraph of explanations would benefit the readers... > > The other variations on this can then build upon the proper foundation > of the simple case. This way the reader can understand how the system > works before you introduce the concept of including more than one > commonPropertiesId in a Template/Data Record. > > > [SNIP] >>>>> The text reads: >>>>> Common Properties IDs are unique per SCTP association and per >>>>> Observation Domain. If the Collecting Process receives a common >>>>> Properties ID which has already been received but which has not >>>>> previously been withdrawn (i.e. a commonPropertiesID from the same >>>>> Exporter Observation Domain with the same Template ID received on >>>>> the SCTP association), then the Collecting Process MUST shutdown >>>>> the association. >>>> This is similar to [IPFIX-PROTO] >>>> >>>> Template IDs are unique per SCTP association and per Observation >>>> Domain. If the Collecting Process receives a Template which has >>>> already been received but which has not previously been >>>> withdrawn (i.e. a Template Record from the same Exporter >>>> Observation Domain with the same Template ID received on the >>>> SCTP association), then the Collecting Process MUST shutdown the >>>> association. >>>> >>>>> >>>>> and: >>>>> If the Collecting Process receives a Common Properties Withdrawal >>>>> message for a Common Properties that it has not received before on >>>>> this SCTP assocation, it MUST reset the SCTP association, discard >>>>> the IPFIX Message, and SHOULD log the error as it does for >>>>> malformed IPFIX Messages. >>>>> I think this might go against IPFIX-PROTO. >>>> This is similar to [IPFIX-PROTO] >>> >>> These are similar to what IPFIX-PROTO says about templates, but that >>> doesn't mean the text can just be used to talk about Data Records sent >>> for Options Templates. >>> >>> Option data withdrawal messages are not mentioned in IPFIX-PROTO, >>> although I think they can work. However, in general options data with >>> the same scope as an earlier record will just overwrite the older >>> record. >> >> See my previous remark about an independent draft. > > What? > > AFAIK red-red is an information draft aimed at explaining how a technique > you can use with an IPFIX compliant Exporter/Collector. > IPFIX-PROTO says > nothing about withdrawing options data and if this draft says: > If the Collecting Process receives a common Properties ID which has > already been received but which has not previously been withdrawn ... > then the Collecting Process MUST shutdown the association. > Then it is expanding on what IPFIX-PROTO says and is no longer just a > way of using IPFIX but an extension to it. > If we accept that withdrawing > options is part of IPFIX today then this is about the only extension > being asked for. > > I can see why you want it, but the problem you are trying to solve here > is the same for ALL options, not just Common Property definitions. This draft, even if this will be an Informational RFC, is an extension on how to use IPFIX in this particular case of redundancy reduction. So, yes, this draft can be more specific. We're trying to solve the only case of the Common Property. > > > [SNIP] >> In this draft, we require a mechanism such as the following: >> "If the Common Properties are not refreshed before that lifetime >> has expired, the Collecting Process MUST discard the >> corresponding definition of the commonPropertiesID and any current >> and future associated Data Records. In which case, an alarm MUST be >> logged. " > > Why is it required for common properties and not other options? There are differences between the data records sent by option data record. Example1: NetFlow V9 exports the ifIndex, IfDescr matchings in Option Template Records Example2: We could think to export the refresh timeout in Option Template Records Example3: The Common Properties ID for redundancy reduction. Even if the 3 examples use Option Template Records, the fundamental difference is in the meaning of the I.E.s: - example 1 and 2 contain I.E.s that are self explaining: they mean something by themselves. We don't need those for the data records to be meaningfull - example 3: the Common Properties ID MUST be present in order to decode the initial Flow Record This implies that: 1. we can't treat all options template record the same way. 2. "If the Common Properties are not refreshed before that lifetime has expired, the Collecting Process MUST discard the corresponding definition of the commonPropertiesID and any current and future associated Data Records. In which case, an alarm MUST be logged. " > Why is it ok to use a mechanism that is not part of the protocol? Because this draft is an extension. If we didn't have to specify some more specifications compared to [IPFIX-PROTO], then an extra example in [IPFIX-AS] would be enough. > >> Because there is no withdraw message with UDP: >> " If UDP is selected as the transport protocol, the commonPropertiesID >> Template Withdraw Messages MUST not be used, as this method is >> inefficient due to the unreliable nature of UDP." >> So I'm wondering why we are discussing this? > > Because you're trying to extend the protocol because you don't think > it's good enough. While I agree that the protocol could do a better > job of handling options, I think this extension is out of scope of > the draft. > > > > > >> Q: Furthermore you shouldn't dictate the the record is discarded, >> just because you >> can't tell a piece of potentially trivial information about a flow >> doesn't mean it's meaningless. >> A: without the Common Properties, we can't decode the records. So we >> must discard them > > Surely that depends on what the Common Properties show. Perhaps the > particular properties that are common aren't important. Similarly, > if a normal full Data Record was received without something the > exporter thought was necessary, it could be discarded. Exactly, this is the reason why I made a distinction between the different examples in my previous comment. > > >> Q: The Common Properties in question could be anything. >> A: I think we should limit this draft to Common Properties > > It wasn't a question and your answer makes no sense. I'm saying > that the properties defined by a particular cpID could be something > that is not important to the Collector. Perhaps it's the > classOfService field and the collector doesn't use it. We agree, aren't we? See my previous remark (example 1 and 2) Regards, Benoit. --------------030905050204070400070808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-bru.cisco.com id kB8GnlX11726 Andrew,
Benoit Claise wrote:
Andrew,
[SNIP]
My concern wasn't really directed at the draft itself, but just the
name "common properties".=C2=A0 From IPFIX-PROTO:
=C2=A0"A Flow is defined as a set of IP packets passing an Observation=C2= =A0=C2=A0 Point in the network during a certain time interval.=C2=A0 All packets=C2= =A0=C2=A0 belonging to a particular Flow have a set of common properties."

And then from IPFIX-INFO:
=C2=A0 Description of commonPropertiesId:
=C2=A0=C2=A0=C2=A0=C2=A0 An identifier of a set of common properties that= is unique per
=C2=A0=C2=A0=C2=A0=C2=A0 Observation Domain.=C2=A0 Typically, this Inform= ation Element is used
=C2=A0=C2=A0=C2=A0=C2=A0 to link to information reported in separate reco= rds.

The terminology is almost identical.=C2=A0 The commonPropertiesId refers
to "a set of common properties" that is quite different from ones
that determine a Flow.

What about something such as?
Description of commonPropertiesId:
=C2=A0=C2=A0=C2=A0=C2=A0 An identifier of a set of common properties betw= een different Flows.
=C2=A0=C2=A0=C2=A0=C2=A0 The that is unique per Observation Domain. =C2=A0= =C2=A0=C2=A0=C2=A0 Typically, this Information Element is used
=C2=A0=C2=A0=C2=A0=C2=A0 to link to information reported in separate reco= rds.

I suggested something quite similar to Elisa:
=C2=A0An identifier of a set of properties that is common across more
=C2=A0that one Flow.=C2=A0 Typically, this Information Element is used to
=C2=A0link to information reported in separate records.=C2=A0 The identif= ier
=C2=A0is unique per Transport Session and Observation Domain.
Agreed. I actually saw Elisa's email after I proposed this :(
One small correction though, after re-reading the Flow and Flow Record definitions.
We should be using 
The commonPropertiesID is an identifier of a set of comm=
on properties
that is locally unique per Observation Domain and Transport Session.
Typically, this Information Element is used to link to information
reported in separate Data Records.


Is there any need to define a new term for "Specific
Properties"? These are just part of a normal Data Record.
For example:
"... The rows are then referenced by the Specific Properties
by using the appropriate value for the Common Properties
identifier."

could simply be:
"... The rows are then referenced by Data Records by
using the appropriate value for the Common Properties
identifier."

In your example, the "Data Records" doesn't mean the full data records before applying the redundancy reduction mechanism but only a part of it.
So it might be confusing... That's the trick we found.

However, I could agree that the draft would work without a formal (upper case) definition.... So do you have the same idea for the Common Properties?

Considering there is a commonPropertiesID, I am quite happy with you
referring to Common Properties.

Ok. So let's see how the draft looks like if we remove the "Specific Properties" formal definition but if we keep the "Common Properties" one.

Sounds good.
I went through the process of trying "Specific Properties" into "specific properties" and I have to admit that some of the sentences and figures look strange and even sometimes misleading. For example, "Common and specific Properties" is strange. So I have to agree with Elisa with keeping the definition in order to clarify the document. Anyway you replied in your last email "I just don't think it is a useful definition, but I don't feel that strongly.". So I think we can close this one.


There seems to be a bit of a conceptual difference here though.=C2=A0 You
seem to imagine that an Exporting Process has a set of IPFIX Data
Records which it then applies some processing to to get some new
special IPFIX Data Records and some Common Property options.=C2=A0 The
original set of Data Records may never actually exist, depending on
how the scheme is implemented.

Sure, this is an implementation detail, but conceptually, we want to reduce "something". How do you call this "something"?

There are already several names for the something.=C2=A0 Most common is Flows
or data.=C2=A0 Sometimes even "Flow Record" but I think that term is too
easily confused with "Data Record".=C2=A0 Data Record has a very specific
meaning and is not what is meant here.=C2=A0 A Data Record is defined by
an IPFIX Template.=C2=A0 The Flows that are sent from the Metering Proces= s
to the Exporting Process have no set format.
Acknowledged.
In the draft, I choose Flow Record, as the definitions say "The Metering Process generates Flow Records"
I checked every occurrence of Data Record and Flow Record in the draft and you're right there are some minor corrections to be done.
OLD
   Regardless of the fields content, flow records with common=20
   properties export the same fields in every single flow record.=20
NEW
   Regardless of the fields content, flow records with common=20
   properties export the same fields in every single data record.=20

OLD
   The Common Properties Flow Records MUST be sent on a reliable SCTP=20
   stream.=20
NEW
   The Common Properties Data Records MUST be sent on a reliable SCTP=20
   stream.=20

OLD
   The Collecting Process can either store the Flow Records as they=20
   arrive, without reconstructing the initial Flow Record, or
   reconstruct the initial Flow Record.
NEW
   The Collecting Process can either store the Data Records as they=20
   arrive, without reconstructing the initial Flow Record, or
   reconstruct the initial Flow Record.

OLD
   In addition there=20
   might be less storage capacity required at the Collector side if the=20
   Collector decides to store the Flow Records as they arrive, without=20
   reconstructing the initial Flow Record. =20
NEW
   In addition there=20
   might be less storage capacity required at the Collector side if the=20
   Collector decides to store the Data Records as they arrive, without=20
   reconstructing the initial Flow Record.

OLD:   =20
   The assignment of Flow Records to common attributes could be done=20
   via the commonPropertiesID and alternatively via the templateID=20
   Information Element. =C2=A0=20
NEW:   =20
   The assignment of common attributes could be done=20
   via the commonPropertiesID and alternatively via the templateID=20
   Information Element.=20

OLD
   On the other hand, these methods require additional resources on=20
   both the Exporter and the Collector.  The Exporter has to manage=20
   Common Properties information and to assign commonPropertiesId=20
   values to Flow Records.=20
NEW=20
   On the other hand, these methods require additional resources on=20
   both the Exporter and the Collector.  The Exporter has to manage=20
   Common Properties information and to assign commonPropertiesId=20
   values.=20
=20
If you see some more required changes, let us know.

For figures 2 to 6, I think the "record" should be "Data Record".
  =C2=A0Figure 2: Common and Specific Properties exported in the same rec=
ord=20
   Figure 3: Common and Specific Properties exported in different records=
   =20
   Figure 4: Common and Specific Properties exported in the same record=20
   Figure 5: Multiple Common (above) and Specific Properties (below)=20
   exported in different records=20
   Figure 6: Common and Specific Properties represented in one record
Alternatively, if we want to avoid the term record or Data Record in figu=
res, let's use the trick of figure 7:=20
   Figure 7: Common and Specific (packet) Properties exported=20
   separately=20
So let's use "exported together" versus "exported separately"
[SNIP]
Are they meaningful in IPFIX? i.e. per the PROTO will an option
with scope but no data be deemed invalidated by the Collector.
Scope without data is the same as never having recieved the
mapping in the first place. I think that it would be up to the
implementation but it seems like a good idea so if we can't add
it to the PROTO can we put it in the implementation guidelines?

How do you propose to withdraw common properties when they are
associated with a template rather than the Common Properties index?

I don't ;) This is the reason why the use the Common Properties index is a cleaner design.

I think withdrawal messages should work in general for options
data, so why not send an empty record with the template as scope?
I guess that you wanted to say:
=C2=A0=C2=A0=C2=A0 I think withdrawal messages should work in general for= options
=C2=A0=C2=A0=C2=A0 data, so why not send an empty record with the _common= property_ as scope?
Well, I prefer to have a clear design so that this draft is really independent, with its withdrawal mechanism.

Then using the template ID to identify Common Properties can be
mentioned in passing, which I guess it is, in 8.3, however it is
also discussed in a little detail in section 4.1.1 (and figure 9),
and section 7.=C2=A0 It seems that these details should be removed.
I understand the issue that we put at the same level the common properties with commonPropertiesID and with templateID, while we don't speak about the template withdrawal in this draft.
Here is a proposal:
We remove the templateID from section 3 and 4, we put it into section "8.3 commonPropertiesID vs. TemplateID scope"
And we mention in that paragraph that:
- the template withdrawal, as specified in [IPFIX-PROTO], can be used to withdraw Template
- the template ID could be used for common properties if the common properties remain constant for the live of the template.
=C2=A0 Otherwise we enter into some problems such as: what's happening wh= en we want to change the common properties in the template.
- that we don't need template withdrawal in this is case, as the template withdrawal is covered by [IPFIX-PROTO] already.
- If the Template is withdrawn then the associated data is invalid too.


Otherwise, you're telling in this I-RFC the standard track IPFIX protocol should consider an empty record as a withdrawal. This could be true a true assumption, but this is not clearly explained/specified!

Not at all.=C2=A0 Either withdrawing options in this way is valid in IPFI= X,
in which case Reducing Redundancy can use it, or it a valid technique
for anybody.=C2=A0 Now I'm not declaring that this is a technique for all
is within the scope of the draft.=C2=A0 If red-red is going to use this
technique though we should decide in the WG that it is valid and say
so in the implementation guidelines or the "Managing Scope" draft.


4. Specifications for bandwidth saving information export

What is being specified here that isn't true for ALL options as
described in IPFIX-PROTO?

What do you suggest?

Well it seems that section three really explains almost the same
thing 3 times.=C2=A0 The section 4 explains most of it again (with a
bit more info) another 3 times.

I would prefer section 3 to simply explain the technique.=C2=A0 Walk
through how the information from a Flow is split into two parts,
and then add the bit from section 4 how these two parts are
exported.

Using more than one CPid in a record should be part of the
advanced techniques once the basics are made clear.=C2=A0 Per packet
should just be a detailed example at the end.

I think section 3 does a better job of explaining how all this
works. I'm really not sure what section 4 adds.

The idea was to put the specs in section 4 while the section 3 was the high level solution.

Rereading it, I see that now, but there seems to be a fair amount
of repetition.

Let me ask the question differently. Do you see this repetition as problem?

Yes.=C2=A0 I think the draft would be cleared if how options work was lef= t
to IPFIX-PROTO.=C2=A0 red-red should reference that, then build describe
exactly how the basic Common Properties work for the simple case, from
concept to execution.
You should be speaking about the beginning of section 4.
As many clarifications to the scope concept had to be made on the mailing list, we thought that adding this extra paragraph of explanations would benefit the readers...

The other variations on this can then build upon the proper foundation
of the simple case.=C2=A0 This way the reader can understand how the syst= em
works before you introduce the concept of including more than one
commonPropertiesId in a Template/Data Record.


[SNIP]
The text reads:
Common Properties IDs are unique per SCTP association and per Observation Domain. If the Collecting Process receives a common Properties ID which has already been received but which has not previously been withdrawn (i.e. a commonPropertiesID from the same Exporter Observation Domain with the same Template ID received on the SCTP association), then the Collecting Process MUST shutdown the association.
This is similar to [IPFIX-PROTO]

=C2=A0Template IDs are unique per SCTP association and per Observation=C2= =A0 =C2=A0Domain.=C2=A0 If the Collecting Process receives a Template which h= as=C2=A0 =C2=A0already been received but which has not previously been withdrawn=C2= =A0=C2=A0=C2=A0 (i.e. a Template Record from the same Exporter Observation Domain=C2=A0=C2= =A0=C2=A0=C2=A0 with the same Template ID received on the SCTP association), then=C2=A0=C2= =A0=C2=A0 the Collecting Process MUST shutdown the association.


and:
If the Collecting Process receives a Common Properties Withdrawal message for a Common Properties that it has not received before on this SCTP assocation, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error as it does for malformed IPFIX Messages.
I think this might go against IPFIX-PROTO.
This is similar to [IPFIX-PROTO]

These are similar to what IPFIX-PROTO says about templates, but that
doesn't mean the text can just be used to talk about Data Records sent
for Options Templates.

Option data withdrawal messages are not mentioned in IPFIX-PROTO,
although I think they can work.=C2=A0 However, in general options data wi= th
the same scope as an earlier record will just overwrite the older
record.

See my previous remark about an independent draft.

What?

AFAIK red-red is an information draft aimed at explaining how a technique
you can use with an IPFIX compliant Exporter/Collector.
IPFIX-PROT= O says
nothing about withdrawing options data and if this draft says:
=C2=A0If the Collecting Process receives a common Properties ID which has
=C2=A0already been received but which has not previously been withdrawn .= ..
=C2=A0then the Collecting Process MUST shutdown the association.
Then it is expanding on what IPFIX-PROTO says and is no longer just a
way of using IPFIX but an extension to it.
If we acce= pt that withdrawing
options is part of IPFIX today then this is about the only extension
being asked for.

I can see why you want it, but the problem you are trying to solve here
is the same for ALL options, not just Common Property definitions.

This draft, even if this will be an Informational RFC, is an extension on how to use IPFIX in this particular case of redundancy reduction.
So, yes, this draft can be more specific. We're trying to solve the only case of the Common Property.


[SNIP]
In this draft, we require a mechanism such as the following:
"If the Common Properties are not refreshed before that lifetime has=C2=A0= =C2=A0 expired, the Collecting Process MUST discard the corresponding=C2=A0=C2=A0 definition of the commonPropertiesID and any current and future=C2=A0=C2=A0 associated Data Records. In which case, an alarm MUST be logged. "

Why is it required for common properties and not other options?
There are differences between the data records sent by option data record.
Example1: NetFlow V9 exports the ifIndex, IfDescr matchings in Option Template Records
Example2: We could think to export the refresh timeout in Option Template Records
Example3: The Common Properties ID for redundancy reduction.
Even if the 3 examples use Option Template Records, the fundamental difference is in the meaning of the I.E.s:
=C2=A0=C2=A0=C2=A0 - example 1 and 2 contain I.E.s that are self explaini= ng: they mean something by themselves. We don't need those for the data records to be meaningfull
=C2=A0=C2=A0=C2=A0 - example 3: the Common Properties ID MUST be present = in order to decode the initial Flow Record
This implies that:
=C2=A0=C2=A0=C2=A0 1. we can't treat all options template record the same= way.
=C2=A0=C2=A0=C2=A0 2. "If the Common Properties are not refreshed before = that lifetime has expired, the Collecting Process MUST discard the corresponding definition of the commonPropertiesID and any current and future associated Data Records. In which case, an alarm MUST be logged. "

Why is it = ok to use a mechanism that is not part of the protocol?
Because this draft is an extension.
If we didn't have to specify some more specifications compared to [IPFIX-PROTO], then an extra example in [IPFIX-AS] would be enough.

Because there is no withdraw message with UDP:
" If UDP is selected as the transport protocol, the commonPropertiesID
=C2=A0 Template Withdraw Messages MUST not be used, as this method is
=C2=A0 inefficient due to the unreliable nature of UDP."
So I'm wondering why we are discussing this?

Because you're trying to extend the protocol because you don't think
it's good enough.=C2=A0 While I agree that the protocol could do a better
job of handling options, I think this extension is out of scope of
the draft.





Q: Furthermore you shouldn't dictate the the record is discarded, just because you
can't tell a piece of potentially trivial information about a flow
doesn't mean it's meaningless.
A: without the Common Properties, we can't decode the records. So we must discard them

Surely that depends on what the Common Properties show.=C2=A0 Perhaps the
particular properties that are common aren't important.=C2=A0 Similarly,
if a normal full Data Record was received without something the
exporter thought was necessary, it could be discarded.
Exactly, this is the reason why I made a distinction between the different examples in my previous comment.


Q: The Common Properties in question could be anything.
A: I think we should limit this draft to Common Properties

It wasn't a question and your answer makes no sense.=C2=A0 I'm saying
that the properties defined by a particular cpID could be something
that is not important to the Collector.=C2=A0 Perhaps it's the
classOfService field and the collector doesn't use it.
We agree, aren't we? See my previous remark (example 1 and 2)

Regards, Benoit.
--------------030905050204070400070808-- --===============1345538163== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1345538163==-- From ipfix-bounces@ietf.org Fri Dec 08 12:08:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsjD1-0001If-4f; Fri, 08 Dec 2006 12:08:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsjD0-0001IZ-FP for ipfix@ietf.org; Fri, 08 Dec 2006 12:08:26 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsjCx-0003nu-CT for ipfix@ietf.org; Fri, 08 Dec 2006 12:08:26 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Dec 2006 18:08:22 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB8H8J0a002480; Fri, 8 Dec 2006 18:08:19 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB8H8FAJ000934; Fri, 8 Dec 2006 18:08:15 +0100 (MET) Received: from [10.61.65.30] (ams3-vpn-dhcp286.cisco.com [10.61.65.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA14634; Fri, 8 Dec 2006 17:08:14 GMT Message-ID: <45799BDF.8020402@cisco.com> Date: Fri, 08 Dec 2006 17:07:43 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Benoit Claise Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> <45780A37.8010905@cisco.com> <45782D40.20002@cisco.com> <457997A9.6010007@cisco.com> In-Reply-To: <457997A9.6010007@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=20951; t=1165597700; x=1166461700; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20WG=20last=20call=20on=09draft-ietf-ipfix-re ducing-redundancy-01.txt=0A=20until=20December=201st |Sender:=20; bh=SauCgGBKcCKtwj+thX+jxTuSO+lqnxC/lBDYKbKTWng=; b=GZTT9Z1+x2o+JP+XjamX6RkHDINMwZMadtXGyyIR+KXo53qlEbJs82sqS3bWrHeTpn/vXE34 TyPfWJgQOm5tnZ1Das1uhxZL/3lVrarCwk6fgXVpcFCkgd3wZFxIOkt9; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f5c1164b9029aa0dd842007e530e24ad Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Benoit Claise wrote: > Andrew, >> Benoit Claise wrote: >>> Andrew, >> [SNIP] >>>> My concern wasn't really directed at the draft itself, but just the >>>> name "common properties". From IPFIX-PROTO: >>>> "A Flow is defined as a set of IP packets passing an Observation >>>> Point in the network during a certain time interval. All packets >>>> belonging to a particular Flow have a set of common properties." >>>> >>>> And then from IPFIX-INFO: >>>> Description of commonPropertiesId: >>>> An identifier of a set of common properties that is unique per >>>> Observation Domain. Typically, this Information Element is used >>>> to link to information reported in separate records. >>>> >>>> The terminology is almost identical. The commonPropertiesId refers >>>> to "a set of common properties" that is quite different from ones >>>> that determine a Flow. >>> >>> What about something such as? >>> Description of commonPropertiesId: >>> An identifier of a set of common properties between different >>> Flows. >>> The that is unique per Observation Domain. Typically, this >>> Information Element is used >>> to link to information reported in separate records. >> >> I suggested something quite similar to Elisa: >> An identifier of a set of properties that is common across more >> that one Flow. Typically, this Information Element is used to >> link to information reported in separate records. The identifier >> is unique per Transport Session and Observation Domain. > > Agreed. I actually saw Elisa's email after I proposed this :( > One small correction though, after re-reading the Flow and Flow Record > definitions. > We should be using > > The commonPropertiesID is an identifier of a set of common properties > that is locally unique per Observation Domain and Transport Session. > Typically, this Information Element is used to link to information > reported in separate Data Records . This looks fine. >>>>>> Is there any need to define a new term for "Specific >>>>>> Properties"? These are just part of a normal Data Record. >>>>>> For example: >>>>>> "... The rows are then referenced by the Specific Properties >>>>>> by using the appropriate value for the Common Properties >>>>>> identifier." >>>>>> >>>>>> could simply be: >>>>>> "... The rows are then referenced by Data Records by >>>>>> using the appropriate value for the Common Properties >>>>>> identifier." >>>>> >>>>> In your example, the "Data Records" doesn't mean the full data >>>>> records before applying the redundancy reduction mechanism but only >>>>> a part of it. >>>>> So it might be confusing... That's the trick we found. >>>>> >>>>> However, I could agree that the draft would work without a formal >>>>> (upper case) definition.... So do you have the same idea for the >>>>> Common Properties? >>>> >>>> Considering there is a commonPropertiesID, I am quite happy with you >>>> referring to Common Properties. >>> >>> Ok. So let's see how the draft looks like if we remove the "Specific >>> Properties" formal definition but if we keep the "Common Properties" >>> one. >> >> Sounds good. > I went through the process of trying "Specific Properties" into > "specific properties" and I have to admit that some of the sentences and > figures look strange and even sometimes misleading. For example, "Common > and specific Properties" is strange. So I have to agree with Elisa with > keeping the definition in order to clarify the document. Anyway you > replied in your last email "I just don't think it is a useful > definition, but I don't feel that strongly.". So I think we can close > this one. Yes, I think the draft _could_ be written without out but if it's a lot of work then it's probably not worth the effort. >>>> There seems to be a bit of a conceptual difference here though. You >>>> seem to imagine that an Exporting Process has a set of IPFIX Data >>>> Records which it then applies some processing to to get some new >>>> special IPFIX Data Records and some Common Property options. The >>>> original set of Data Records may never actually exist, depending on >>>> how the scheme is implemented. >>> >>> Sure, this is an implementation detail, but conceptually, we want to >>> reduce "something". How do you call this "something"? >> >> There are already several names for the something. Most common is Flows >> or data. Sometimes even "Flow Record" but I think that term is too >> easily confused with "Data Record". Data Record has a very specific >> meaning and is not what is meant here. A Data Record is defined by >> an IPFIX Template. The Flows that are sent from the Metering Process >> to the Exporting Process have no set format. > > Acknowledged. > In the draft, I choose Flow Record, as the definitions say "The Metering > Process generates Flow Records" > I checked every occurrence of Data Record and Flow Record in the draft > and you're right there are some minor corrections to be done. > > OLD > Regardless of the fields content, flow records with common > properties export the same fields in every single flow record. > NEW > Regardless of the fields content, flow records with common > properties export the same fields in every single data record. > > OLD > The Common Properties Flow Records MUST be sent on a reliable SCTP > stream. > NEW > The Common Properties Data Records MUST be sent on a reliable SCTP > stream. > > OLD > The Collecting Process can either store the Flow Records as they > arrive, without reconstructing the initial Flow Record, or > reconstruct the initial Flow Record. > NEW > The Collecting Process can either store the Data Records as they > arrive, without reconstructing the initial Flow Record, or > reconstruct the initial Flow Record. > > OLD > In addition there > might be less storage capacity required at the Collector side if the > Collector decides to store the Flow Records as they arrive, without > reconstructing the initial Flow Record. > NEW > In addition there > might be less storage capacity required at the Collector side if the > Collector decides to store the Data Records as they arrive, without > reconstructing the initial Flow Record. > > OLD: > The assignment of Flow Records to common attributes could be done > via the commonPropertiesID and alternatively via the templateID > Information Element. > NEW: > The assignment of common attributes could be done > via the commonPropertiesID and alternatively via the templateID > Information Element. > > OLD > On the other hand, these methods require additional resources on > both the Exporter and the Collector. The Exporter has to manage > Common Properties information and to assign commonPropertiesId > values to Flow Records. > NEW > On the other hand, these methods require additional resources on > both the Exporter and the Collector. The Exporter has to manage > Common Properties information and to assign commonPropertiesId > values. > > If you see some more required changes, let us know. These changes all look fine. > For figures 2 to 6, I think the "record" should be "Data Record". > Figure 2: Common and Specific Properties exported in the same record > Figure 3: Common and Specific Properties exported in different records > Figure 4: Common and Specific Properties exported in the same record > Figure 5: Multiple Common (above) and Specific Properties (below) > exported in different records > Figure 6: Common and Specific Properties represented in one record > Alternatively, if we want to avoid the term record or Data Record in figures, let's use the trick of figure 7: > Figure 7: Common and Specific (packet) Properties exported > separately > So let's use "exported together" versus "exported separately" OK. > [SNIP] >>>>>> Are they meaningful in IPFIX? i.e. per the PROTO will an option >>>>>> with scope but no data be deemed invalidated by the Collector. >>>>>> Scope without data is the same as never having recieved the >>>>>> mapping in the first place. I think that it would be up to the >>>>>> implementation but it seems like a good idea so if we can't add >>>>>> it to the PROTO can we put it in the implementation guidelines? >>>>>> >>>>>> How do you propose to withdraw common properties when they are >>>>>> associated with a template rather than the Common Properties index? >>>>> >>>>> I don't ;) This is the reason why the use the Common Properties >>>>> index is a cleaner design. >>>> >>>> I think withdrawal messages should work in general for options >>>> data, so why not send an empty record with the template as scope? >>> I guess that you wanted to say: >>> I think withdrawal messages should work in general for options >>> data, so why not send an empty record with the _common property_ >>> as scope? >>> Well, I prefer to have a clear design so that this draft is really >>> independent, with its withdrawal mechanism. >> >> Then using the template ID to identify Common Properties can be >> mentioned in passing, which I guess it is, in 8.3, however it is >> also discussed in a little detail in section 4.1.1 (and figure 9), >> and section 7. It seems that these details should be removed. > > I understand the issue that we put at the same level the common > properties with commonPropertiesID and with templateID, while we don't > speak about the template withdrawal in this draft. > Here is a proposal: > We remove the templateID from section 3 and 4, we put it into section > "8.3 commonPropertiesID vs. TemplateID scope" > And we mention in that paragraph that: > - the template withdrawal, as specified in [IPFIX-PROTO], can be used to > withdraw Template > - the template ID could be used for common properties if the common > properties remain constant for the live of the template. > Otherwise we enter into some problems such as: what's happening when > we want to change the common properties in the template. > - that we don't need template withdrawal in this is case, as the > template withdrawal is covered by [IPFIX-PROTO] already. > - If the Template is withdrawn then the associated data is invalid too. I think your suggestion is a good one, but I think using the Template ID may be a bad idea for Common Properties and perhaps it shouldn't be suggested at all in the draft. I will start a new thread to specifically discuss this issue. >>> Otherwise, you're telling in this I-RFC the standard track IPFIX >>> protocol should consider an empty record as a withdrawal. This could >>> be true a true assumption, but this is not clearly explained/specified! >> >> Not at all. Either withdrawing options in this way is valid in IPFIX, >> in which case Reducing Redundancy can use it, or it a valid technique >> for anybody. Now I'm not declaring that this is a technique for all >> is within the scope of the draft. If red-red is going to use this >> technique though we should decide in the WG that it is valid and say >> so in the implementation guidelines or the "Managing Scope" draft. >> >> >>>>>> 4. Specifications for bandwidth saving information export >>>>>> >>>>>> What is being specified here that isn't true for ALL options as >>>>>> described in IPFIX-PROTO? >>>>> >>>>> What do you suggest? >>>> >>>> Well it seems that section three really explains almost the same >>>> thing 3 times. The section 4 explains most of it again (with a >>>> bit more info) another 3 times. >>>> >>>> I would prefer section 3 to simply explain the technique. Walk >>>> through how the information from a Flow is split into two parts, >>>> and then add the bit from section 4 how these two parts are >>>> exported. >>>> >>>> Using more than one CPid in a record should be part of the >>>> advanced techniques once the basics are made clear. Per packet >>>> should just be a detailed example at the end. >>>> >>>>>> I think section 3 does a better job of explaining how all this >>>>>> works. I'm really not sure what section 4 adds. >>>>> >>>>> The idea was to put the specs in section 4 while the section 3 was >>>>> the high level solution. >>>> >>>> Rereading it, I see that now, but there seems to be a fair amount >>>> of repetition. >>> >>> Let me ask the question differently. Do you see this repetition as >>> problem? >> >> Yes. I think the draft would be cleared if how options work was left >> to IPFIX-PROTO. red-red should reference that, then build describe >> exactly how the basic Common Properties work for the simple case, from >> concept to execution. > > You should be speaking about the beginning of section 4. > As many clarifications to the scope concept had to be made on the > mailing list, we thought that adding this extra paragraph of > explanations would benefit the readers... I think you can still refer to section 3.4.2 of [IPFIX-PROTO], but by all means clarify what you need to. >> The other variations on this can then build upon the proper foundation >> of the simple case. This way the reader can understand how the system >> works before you introduce the concept of including more than one >> commonPropertiesId in a Template/Data Record. >> >> >> [SNIP] >>>>>> The text reads: >>>>>> Common Properties IDs are unique per SCTP association and per >>>>>> Observation Domain. If the Collecting Process receives a common >>>>>> Properties ID which has already been received but which has not >>>>>> previously been withdrawn (i.e. a commonPropertiesID from the same >>>>>> Exporter Observation Domain with the same Template ID received on >>>>>> the SCTP association), then the Collecting Process MUST shutdown >>>>>> the association. >>>>> This is similar to [IPFIX-PROTO] >>>>> >>>>> Template IDs are unique per SCTP association and per Observation >>>>> Domain. If the Collecting Process receives a Template which has >>>>> already been received but which has not previously been >>>>> withdrawn (i.e. a Template Record from the same Exporter >>>>> Observation Domain with the same Template ID received on the >>>>> SCTP association), then the Collecting Process MUST shutdown the >>>>> association. >>>>> >>>>>> >>>>>> and: >>>>>> If the Collecting Process receives a Common Properties Withdrawal >>>>>> message for a Common Properties that it has not received before on >>>>>> this SCTP assocation, it MUST reset the SCTP association, discard >>>>>> the IPFIX Message, and SHOULD log the error as it does for >>>>>> malformed IPFIX Messages. >>>>>> I think this might go against IPFIX-PROTO. >>>>> This is similar to [IPFIX-PROTO] >>>> >>>> These are similar to what IPFIX-PROTO says about templates, but that >>>> doesn't mean the text can just be used to talk about Data Records sent >>>> for Options Templates. >>>> >>>> Option data withdrawal messages are not mentioned in IPFIX-PROTO, >>>> although I think they can work. However, in general options data with >>>> the same scope as an earlier record will just overwrite the older >>>> record. >>> >>> See my previous remark about an independent draft. >> >> What? >> >> AFAIK red-red is an information draft aimed at explaining how a technique >> you can use with an IPFIX compliant Exporter/Collector. >> IPFIX-PROTO says >> nothing about withdrawing options data and if this draft says: >> If the Collecting Process receives a common Properties ID which has >> already been received but which has not previously been withdrawn ... >> then the Collecting Process MUST shutdown the association. >> Then it is expanding on what IPFIX-PROTO says and is no longer just a >> way of using IPFIX but an extension to it. >> If we accept that withdrawing >> options is part of IPFIX today then this is about the only extension >> being asked for. >> >> I can see why you want it, but the problem you are trying to solve here >> is the same for ALL options, not just Common Property definitions. > > This draft, even if this will be an Informational RFC, is an extension > on how to use IPFIX in this particular case of redundancy reduction. > So, yes, this draft can be more specific. We're trying to solve the only > case of the Common Property. Yes, I think I'll have to agree that some extensions will be needed, even if some of the techniques aren't really prohibited in IPFIX-PROTO, and fall into a grey area. Please detail the extensions in an Appendix as most of the methods used in the draft are from IPFIX-PROTO and there are only a few areas that you expand upon. It would be good for the implementer of an IPFIX compliant device to clearly see what the differences are. >> [SNIP] >>> In this draft, we require a mechanism such as the following: >>> "If the Common Properties are not refreshed before that lifetime >>> has expired, the Collecting Process MUST discard the >>> corresponding definition of the commonPropertiesID and any current >>> and future associated Data Records. In which case, an alarm MUST be >>> logged. " >> >> Why is it required for common properties and not other options? > There are differences between the data records sent by option data record. > Example1: NetFlow V9 exports the ifIndex, IfDescr matchings in Option > Template Records > Example2: We could think to export the refresh timeout in Option > Template Records > Example3: The Common Properties ID for redundancy reduction. > Even if the 3 examples use Option Template Records, the fundamental > difference is in the meaning of the I.E.s: > - example 1 and 2 contain I.E.s that are self explaining: they mean > something by themselves. We don't need those for the data records to be > meaningfull > - example 3: the Common Properties ID MUST be present in order to > decode the initial Flow Record > This implies that: > 1. we can't treat all options template record the same way. > 2. "If the Common Properties are not refreshed before that lifetime > has expired, the Collecting Process MUST discard the corresponding > definition of the commonPropertiesID and any current and future > associated Data Records. In which case, an alarm MUST be logged. " > >> Why is it ok to use a mechanism that is not part of the protocol? > Because this draft is an extension. > If we didn't have to specify some more specifications compared to > [IPFIX-PROTO], then an extra example in [IPFIX-AS] would be enough. >> >>> Because there is no withdraw message with UDP: >>> " If UDP is selected as the transport protocol, the commonPropertiesID >>> Template Withdraw Messages MUST not be used, as this method is >>> inefficient due to the unreliable nature of UDP." >>> So I'm wondering why we are discussing this? >> >> Because you're trying to extend the protocol because you don't think >> it's good enough. While I agree that the protocol could do a better >> job of handling options, I think this extension is out of scope of >> the draft. >> >> >> >> >> >>> Q: Furthermore you shouldn't dictate the the record is discarded, >>> just because you >>> can't tell a piece of potentially trivial information about a flow >>> doesn't mean it's meaningless. >>> A: without the Common Properties, we can't decode the records. So we >>> must discard them >> >> Surely that depends on what the Common Properties show. Perhaps the >> particular properties that are common aren't important. Similarly, >> if a normal full Data Record was received without something the >> exporter thought was necessary, it could be discarded. > Exactly, this is the reason why I made a distinction between the > different examples in my previous comment. >> >> >>> Q: The Common Properties in question could be anything. >>> A: I think we should limit this draft to Common Properties >> >> It wasn't a question and your answer makes no sense. I'm saying >> that the properties defined by a particular cpID could be something >> that is not important to the Collector. Perhaps it's the >> classOfService field and the collector doesn't use it. > We agree, aren't we? See my previous remark (example 1 and 2) We agree. With an identifier such as cpID, if it's not defined then you have no idea what you are missing. With data associated with an IE that is valid by itself (ifIndex for example) then you don't need the definition, and in fact wouldn't know you were missing it. regards Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Dec 08 12:08:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsjD1-0001If-4f; Fri, 08 Dec 2006 12:08:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsjD0-0001IZ-FP for ipfix@ietf.org; Fri, 08 Dec 2006 12:08:26 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsjCx-0003nu-CT for ipfix@ietf.org; Fri, 08 Dec 2006 12:08:26 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Dec 2006 18:08:22 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB8H8J0a002480; Fri, 8 Dec 2006 18:08:19 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB8H8FAJ000934; Fri, 8 Dec 2006 18:08:15 +0100 (MET) Received: from [10.61.65.30] (ams3-vpn-dhcp286.cisco.com [10.61.65.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA14634; Fri, 8 Dec 2006 17:08:14 GMT Message-ID: <45799BDF.8020402@cisco.com> Date: Fri, 08 Dec 2006 17:07:43 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Benoit Claise Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> <45780A37.8010905@cisco.com> <45782D40.20002@cisco.com> <457997A9.6010007@cisco.com> In-Reply-To: <457997A9.6010007@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=20951; t=1165597700; x=1166461700; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20WG=20last=20call=20on=09draft-ietf-ipfix-re ducing-redundancy-01.txt=0A=20until=20December=201st |Sender:=20; bh=SauCgGBKcCKtwj+thX+jxTuSO+lqnxC/lBDYKbKTWng=; b=GZTT9Z1+x2o+JP+XjamX6RkHDINMwZMadtXGyyIR+KXo53qlEbJs82sqS3bWrHeTpn/vXE34 TyPfWJgQOm5tnZ1Das1uhxZL/3lVrarCwk6fgXVpcFCkgd3wZFxIOkt9; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f5c1164b9029aa0dd842007e530e24ad Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Benoit Claise wrote: > Andrew, >> Benoit Claise wrote: >>> Andrew, >> [SNIP] >>>> My concern wasn't really directed at the draft itself, but just the >>>> name "common properties". From IPFIX-PROTO: >>>> "A Flow is defined as a set of IP packets passing an Observation >>>> Point in the network during a certain time interval. All packets >>>> belonging to a particular Flow have a set of common properties." >>>> >>>> And then from IPFIX-INFO: >>>> Description of commonPropertiesId: >>>> An identifier of a set of common properties that is unique per >>>> Observation Domain. Typically, this Information Element is used >>>> to link to information reported in separate records. >>>> >>>> The terminology is almost identical. The commonPropertiesId refers >>>> to "a set of common properties" that is quite different from ones >>>> that determine a Flow. >>> >>> What about something such as? >>> Description of commonPropertiesId: >>> An identifier of a set of common properties between different >>> Flows. >>> The that is unique per Observation Domain. Typically, this >>> Information Element is used >>> to link to information reported in separate records. >> >> I suggested something quite similar to Elisa: >> An identifier of a set of properties that is common across more >> that one Flow. Typically, this Information Element is used to >> link to information reported in separate records. The identifier >> is unique per Transport Session and Observation Domain. > > Agreed. I actually saw Elisa's email after I proposed this :( > One small correction though, after re-reading the Flow and Flow Record > definitions. > We should be using > > The commonPropertiesID is an identifier of a set of common properties > that is locally unique per Observation Domain and Transport Session. > Typically, this Information Element is used to link to information > reported in separate Data Records . This looks fine. >>>>>> Is there any need to define a new term for "Specific >>>>>> Properties"? These are just part of a normal Data Record. >>>>>> For example: >>>>>> "... The rows are then referenced by the Specific Properties >>>>>> by using the appropriate value for the Common Properties >>>>>> identifier." >>>>>> >>>>>> could simply be: >>>>>> "... The rows are then referenced by Data Records by >>>>>> using the appropriate value for the Common Properties >>>>>> identifier." >>>>> >>>>> In your example, the "Data Records" doesn't mean the full data >>>>> records before applying the redundancy reduction mechanism but only >>>>> a part of it. >>>>> So it might be confusing... That's the trick we found. >>>>> >>>>> However, I could agree that the draft would work without a formal >>>>> (upper case) definition.... So do you have the same idea for the >>>>> Common Properties? >>>> >>>> Considering there is a commonPropertiesID, I am quite happy with you >>>> referring to Common Properties. >>> >>> Ok. So let's see how the draft looks like if we remove the "Specific >>> Properties" formal definition but if we keep the "Common Properties" >>> one. >> >> Sounds good. > I went through the process of trying "Specific Properties" into > "specific properties" and I have to admit that some of the sentences and > figures look strange and even sometimes misleading. For example, "Common > and specific Properties" is strange. So I have to agree with Elisa with > keeping the definition in order to clarify the document. Anyway you > replied in your last email "I just don't think it is a useful > definition, but I don't feel that strongly.". So I think we can close > this one. Yes, I think the draft _could_ be written without out but if it's a lot of work then it's probably not worth the effort. >>>> There seems to be a bit of a conceptual difference here though. You >>>> seem to imagine that an Exporting Process has a set of IPFIX Data >>>> Records which it then applies some processing to to get some new >>>> special IPFIX Data Records and some Common Property options. The >>>> original set of Data Records may never actually exist, depending on >>>> how the scheme is implemented. >>> >>> Sure, this is an implementation detail, but conceptually, we want to >>> reduce "something". How do you call this "something"? >> >> There are already several names for the something. Most common is Flows >> or data. Sometimes even "Flow Record" but I think that term is too >> easily confused with "Data Record". Data Record has a very specific >> meaning and is not what is meant here. A Data Record is defined by >> an IPFIX Template. The Flows that are sent from the Metering Process >> to the Exporting Process have no set format. > > Acknowledged. > In the draft, I choose Flow Record, as the definitions say "The Metering > Process generates Flow Records" > I checked every occurrence of Data Record and Flow Record in the draft > and you're right there are some minor corrections to be done. > > OLD > Regardless of the fields content, flow records with common > properties export the same fields in every single flow record. > NEW > Regardless of the fields content, flow records with common > properties export the same fields in every single data record. > > OLD > The Common Properties Flow Records MUST be sent on a reliable SCTP > stream. > NEW > The Common Properties Data Records MUST be sent on a reliable SCTP > stream. > > OLD > The Collecting Process can either store the Flow Records as they > arrive, without reconstructing the initial Flow Record, or > reconstruct the initial Flow Record. > NEW > The Collecting Process can either store the Data Records as they > arrive, without reconstructing the initial Flow Record, or > reconstruct the initial Flow Record. > > OLD > In addition there > might be less storage capacity required at the Collector side if the > Collector decides to store the Flow Records as they arrive, without > reconstructing the initial Flow Record. > NEW > In addition there > might be less storage capacity required at the Collector side if the > Collector decides to store the Data Records as they arrive, without > reconstructing the initial Flow Record. > > OLD: > The assignment of Flow Records to common attributes could be done > via the commonPropertiesID and alternatively via the templateID > Information Element. > NEW: > The assignment of common attributes could be done > via the commonPropertiesID and alternatively via the templateID > Information Element. > > OLD > On the other hand, these methods require additional resources on > both the Exporter and the Collector. The Exporter has to manage > Common Properties information and to assign commonPropertiesId > values to Flow Records. > NEW > On the other hand, these methods require additional resources on > both the Exporter and the Collector. The Exporter has to manage > Common Properties information and to assign commonPropertiesId > values. > > If you see some more required changes, let us know. These changes all look fine. > For figures 2 to 6, I think the "record" should be "Data Record". > Figure 2: Common and Specific Properties exported in the same record > Figure 3: Common and Specific Properties exported in different records > Figure 4: Common and Specific Properties exported in the same record > Figure 5: Multiple Common (above) and Specific Properties (below) > exported in different records > Figure 6: Common and Specific Properties represented in one record > Alternatively, if we want to avoid the term record or Data Record in figures, let's use the trick of figure 7: > Figure 7: Common and Specific (packet) Properties exported > separately > So let's use "exported together" versus "exported separately" OK. > [SNIP] >>>>>> Are they meaningful in IPFIX? i.e. per the PROTO will an option >>>>>> with scope but no data be deemed invalidated by the Collector. >>>>>> Scope without data is the same as never having recieved the >>>>>> mapping in the first place. I think that it would be up to the >>>>>> implementation but it seems like a good idea so if we can't add >>>>>> it to the PROTO can we put it in the implementation guidelines? >>>>>> >>>>>> How do you propose to withdraw common properties when they are >>>>>> associated with a template rather than the Common Properties index? >>>>> >>>>> I don't ;) This is the reason why the use the Common Properties >>>>> index is a cleaner design. >>>> >>>> I think withdrawal messages should work in general for options >>>> data, so why not send an empty record with the template as scope? >>> I guess that you wanted to say: >>> I think withdrawal messages should work in general for options >>> data, so why not send an empty record with the _common property_ >>> as scope? >>> Well, I prefer to have a clear design so that this draft is really >>> independent, with its withdrawal mechanism. >> >> Then using the template ID to identify Common Properties can be >> mentioned in passing, which I guess it is, in 8.3, however it is >> also discussed in a little detail in section 4.1.1 (and figure 9), >> and section 7. It seems that these details should be removed. > > I understand the issue that we put at the same level the common > properties with commonPropertiesID and with templateID, while we don't > speak about the template withdrawal in this draft. > Here is a proposal: > We remove the templateID from section 3 and 4, we put it into section > "8.3 commonPropertiesID vs. TemplateID scope" > And we mention in that paragraph that: > - the template withdrawal, as specified in [IPFIX-PROTO], can be used to > withdraw Template > - the template ID could be used for common properties if the common > properties remain constant for the live of the template. > Otherwise we enter into some problems such as: what's happening when > we want to change the common properties in the template. > - that we don't need template withdrawal in this is case, as the > template withdrawal is covered by [IPFIX-PROTO] already. > - If the Template is withdrawn then the associated data is invalid too. I think your suggestion is a good one, but I think using the Template ID may be a bad idea for Common Properties and perhaps it shouldn't be suggested at all in the draft. I will start a new thread to specifically discuss this issue. >>> Otherwise, you're telling in this I-RFC the standard track IPFIX >>> protocol should consider an empty record as a withdrawal. This could >>> be true a true assumption, but this is not clearly explained/specified! >> >> Not at all. Either withdrawing options in this way is valid in IPFIX, >> in which case Reducing Redundancy can use it, or it a valid technique >> for anybody. Now I'm not declaring that this is a technique for all >> is within the scope of the draft. If red-red is going to use this >> technique though we should decide in the WG that it is valid and say >> so in the implementation guidelines or the "Managing Scope" draft. >> >> >>>>>> 4. Specifications for bandwidth saving information export >>>>>> >>>>>> What is being specified here that isn't true for ALL options as >>>>>> described in IPFIX-PROTO? >>>>> >>>>> What do you suggest? >>>> >>>> Well it seems that section three really explains almost the same >>>> thing 3 times. The section 4 explains most of it again (with a >>>> bit more info) another 3 times. >>>> >>>> I would prefer section 3 to simply explain the technique. Walk >>>> through how the information from a Flow is split into two parts, >>>> and then add the bit from section 4 how these two parts are >>>> exported. >>>> >>>> Using more than one CPid in a record should be part of the >>>> advanced techniques once the basics are made clear. Per packet >>>> should just be a detailed example at the end. >>>> >>>>>> I think section 3 does a better job of explaining how all this >>>>>> works. I'm really not sure what section 4 adds. >>>>> >>>>> The idea was to put the specs in section 4 while the section 3 was >>>>> the high level solution. >>>> >>>> Rereading it, I see that now, but there seems to be a fair amount >>>> of repetition. >>> >>> Let me ask the question differently. Do you see this repetition as >>> problem? >> >> Yes. I think the draft would be cleared if how options work was left >> to IPFIX-PROTO. red-red should reference that, then build describe >> exactly how the basic Common Properties work for the simple case, from >> concept to execution. > > You should be speaking about the beginning of section 4. > As many clarifications to the scope concept had to be made on the > mailing list, we thought that adding this extra paragraph of > explanations would benefit the readers... I think you can still refer to section 3.4.2 of [IPFIX-PROTO], but by all means clarify what you need to. >> The other variations on this can then build upon the proper foundation >> of the simple case. This way the reader can understand how the system >> works before you introduce the concept of including more than one >> commonPropertiesId in a Template/Data Record. >> >> >> [SNIP] >>>>>> The text reads: >>>>>> Common Properties IDs are unique per SCTP association and per >>>>>> Observation Domain. If the Collecting Process receives a common >>>>>> Properties ID which has already been received but which has not >>>>>> previously been withdrawn (i.e. a commonPropertiesID from the same >>>>>> Exporter Observation Domain with the same Template ID received on >>>>>> the SCTP association), then the Collecting Process MUST shutdown >>>>>> the association. >>>>> This is similar to [IPFIX-PROTO] >>>>> >>>>> Template IDs are unique per SCTP association and per Observation >>>>> Domain. If the Collecting Process receives a Template which has >>>>> already been received but which has not previously been >>>>> withdrawn (i.e. a Template Record from the same Exporter >>>>> Observation Domain with the same Template ID received on the >>>>> SCTP association), then the Collecting Process MUST shutdown the >>>>> association. >>>>> >>>>>> >>>>>> and: >>>>>> If the Collecting Process receives a Common Properties Withdrawal >>>>>> message for a Common Properties that it has not received before on >>>>>> this SCTP assocation, it MUST reset the SCTP association, discard >>>>>> the IPFIX Message, and SHOULD log the error as it does for >>>>>> malformed IPFIX Messages. >>>>>> I think this might go against IPFIX-PROTO. >>>>> This is similar to [IPFIX-PROTO] >>>> >>>> These are similar to what IPFIX-PROTO says about templates, but that >>>> doesn't mean the text can just be used to talk about Data Records sent >>>> for Options Templates. >>>> >>>> Option data withdrawal messages are not mentioned in IPFIX-PROTO, >>>> although I think they can work. However, in general options data with >>>> the same scope as an earlier record will just overwrite the older >>>> record. >>> >>> See my previous remark about an independent draft. >> >> What? >> >> AFAIK red-red is an information draft aimed at explaining how a technique >> you can use with an IPFIX compliant Exporter/Collector. >> IPFIX-PROTO says >> nothing about withdrawing options data and if this draft says: >> If the Collecting Process receives a common Properties ID which has >> already been received but which has not previously been withdrawn ... >> then the Collecting Process MUST shutdown the association. >> Then it is expanding on what IPFIX-PROTO says and is no longer just a >> way of using IPFIX but an extension to it. >> If we accept that withdrawing >> options is part of IPFIX today then this is about the only extension >> being asked for. >> >> I can see why you want it, but the problem you are trying to solve here >> is the same for ALL options, not just Common Property definitions. > > This draft, even if this will be an Informational RFC, is an extension > on how to use IPFIX in this particular case of redundancy reduction. > So, yes, this draft can be more specific. We're trying to solve the only > case of the Common Property. Yes, I think I'll have to agree that some extensions will be needed, even if some of the techniques aren't really prohibited in IPFIX-PROTO, and fall into a grey area. Please detail the extensions in an Appendix as most of the methods used in the draft are from IPFIX-PROTO and there are only a few areas that you expand upon. It would be good for the implementer of an IPFIX compliant device to clearly see what the differences are. >> [SNIP] >>> In this draft, we require a mechanism such as the following: >>> "If the Common Properties are not refreshed before that lifetime >>> has expired, the Collecting Process MUST discard the >>> corresponding definition of the commonPropertiesID and any current >>> and future associated Data Records. In which case, an alarm MUST be >>> logged. " >> >> Why is it required for common properties and not other options? > There are differences between the data records sent by option data record. > Example1: NetFlow V9 exports the ifIndex, IfDescr matchings in Option > Template Records > Example2: We could think to export the refresh timeout in Option > Template Records > Example3: The Common Properties ID for redundancy reduction. > Even if the 3 examples use Option Template Records, the fundamental > difference is in the meaning of the I.E.s: > - example 1 and 2 contain I.E.s that are self explaining: they mean > something by themselves. We don't need those for the data records to be > meaningfull > - example 3: the Common Properties ID MUST be present in order to > decode the initial Flow Record > This implies that: > 1. we can't treat all options template record the same way. > 2. "If the Common Properties are not refreshed before that lifetime > has expired, the Collecting Process MUST discard the corresponding > definition of the commonPropertiesID and any current and future > associated Data Records. In which case, an alarm MUST be logged. " > >> Why is it ok to use a mechanism that is not part of the protocol? > Because this draft is an extension. > If we didn't have to specify some more specifications compared to > [IPFIX-PROTO], then an extra example in [IPFIX-AS] would be enough. >> >>> Because there is no withdraw message with UDP: >>> " If UDP is selected as the transport protocol, the commonPropertiesID >>> Template Withdraw Messages MUST not be used, as this method is >>> inefficient due to the unreliable nature of UDP." >>> So I'm wondering why we are discussing this? >> >> Because you're trying to extend the protocol because you don't think >> it's good enough. While I agree that the protocol could do a better >> job of handling options, I think this extension is out of scope of >> the draft. >> >> >> >> >> >>> Q: Furthermore you shouldn't dictate the the record is discarded, >>> just because you >>> can't tell a piece of potentially trivial information about a flow >>> doesn't mean it's meaningless. >>> A: without the Common Properties, we can't decode the records. So we >>> must discard them >> >> Surely that depends on what the Common Properties show. Perhaps the >> particular properties that are common aren't important. Similarly, >> if a normal full Data Record was received without something the >> exporter thought was necessary, it could be discarded. > Exactly, this is the reason why I made a distinction between the > different examples in my previous comment. >> >> >>> Q: The Common Properties in question could be anything. >>> A: I think we should limit this draft to Common Properties >> >> It wasn't a question and your answer makes no sense. I'm saying >> that the properties defined by a particular cpID could be something >> that is not important to the Collector. Perhaps it's the >> classOfService field and the collector doesn't use it. > We agree, aren't we? See my previous remark (example 1 and 2) We agree. With an identifier such as cpID, if it's not defined then you have no idea what you are missing. With data associated with an IE that is valid by itself (ifIndex for example) then you don't need the definition, and in fact wouldn't know you were missing it. regards Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Dec 08 17:26:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gso9Z-0005Kn-6V; Fri, 08 Dec 2006 17:25:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gso9X-0005Kb-4F for ipfix@ietf.org; Fri, 08 Dec 2006 17:25:11 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gso9U-000140-P5 for ipfix@ietf.org; Fri, 08 Dec 2006 17:25:11 -0500 Received: from [192.168.1.128] (unknown [91.89.53.224]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A7D9313CF86; Fri, 8 Dec 2006 23:29:39 +0100 (CET) Date: Fri, 08 Dec 2006 23:24:24 +0100 From: Juergen Quittek To: "Boschi, Elisa" , andrjohn@cisco.com Subject: Re: [IPFIX] Reference to PSAMP in draft-ietf-ipfix-reducing-redundancy-01.txt Message-ID: <44D184EFE757C858B7B1629B@753F3B888A9969457862729D> In-Reply-To: <3167F18F59B81B4888A4D4C0A1717DD6670F96@mhdexc02.adhel.hitachi-eu.com> References: <3167F18F59B81B4888A4D4C0A1717DD6670F96@mhdexc02.adhel.hitachi-eu.com> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi all, --On 05.12.06 17:32 +0000 Boschi, Elisa wrote: > > Andrew, all, > >> >> If there are references to PSAMP drafts, doesn't that >> block this from becoming an RFC until the PSAMP ones >> are RFCs? Do we have to mention PSAMP so much anyway, >> as it's just a specialised use case of IPFIX? > > > Only the PSAMP protocol blocks this document. I think that > the reference to PSAMP is important and should be kept, > since it is one of the most important applications for > the reducing redundancy technique (the draft was initially > targeted to PSAMP...). > > Any other opinions on this matter? I agree. I don't see a way to remove the PSAMP references without applying significant changes. An such changes would not improve the document. Thanks, Juergen > Regards, > Elisa > > > > ************************************************************************************************** > > 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 e-mail 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. > E-mail messages are not necessarily secure. Hitachi does not accept responsibility > for any changes made to this message after it was sent. > Please note that Hitachi checks outgoing e-mail messages for the presence of > computer viruses. > > ************************************************************************************************** > > > -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 4342-115 NEC Europe Ltd., Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Dec 08 17:26:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gso9Z-0005Kn-6V; Fri, 08 Dec 2006 17:25:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gso9X-0005Kb-4F for ipfix@ietf.org; Fri, 08 Dec 2006 17:25:11 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gso9U-000140-P5 for ipfix@ietf.org; Fri, 08 Dec 2006 17:25:11 -0500 Received: from [192.168.1.128] (unknown [91.89.53.224]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A7D9313CF86; Fri, 8 Dec 2006 23:29:39 +0100 (CET) Date: Fri, 08 Dec 2006 23:24:24 +0100 From: Juergen Quittek To: "Boschi, Elisa" , andrjohn@cisco.com Subject: Re: [IPFIX] Reference to PSAMP in draft-ietf-ipfix-reducing-redundancy-01.txt Message-ID: <44D184EFE757C858B7B1629B@753F3B888A9969457862729D> In-Reply-To: <3167F18F59B81B4888A4D4C0A1717DD6670F96@mhdexc02.adhel.hitachi-eu.com> References: <3167F18F59B81B4888A4D4C0A1717DD6670F96@mhdexc02.adhel.hitachi-eu.com> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi all, --On 05.12.06 17:32 +0000 Boschi, Elisa wrote: > > Andrew, all, > >> >> If there are references to PSAMP drafts, doesn't that >> block this from becoming an RFC until the PSAMP ones >> are RFCs? Do we have to mention PSAMP so much anyway, >> as it's just a specialised use case of IPFIX? > > > Only the PSAMP protocol blocks this document. I think that > the reference to PSAMP is important and should be kept, > since it is one of the most important applications for > the reducing redundancy technique (the draft was initially > targeted to PSAMP...). > > Any other opinions on this matter? I agree. I don't see a way to remove the PSAMP references without applying significant changes. An such changes would not improve the document. Thanks, Juergen > Regards, > Elisa > > > > ************************************************************************************************** > > 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 e-mail 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. > E-mail messages are not necessarily secure. Hitachi does not accept responsibility > for any changes made to this message after it was sent. > Please note that Hitachi checks outgoing e-mail messages for the presence of > computer viruses. > > ************************************************************************************************** > > > -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 4342-115 NEC Europe Ltd., Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sat Dec 09 05:25:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GszNH-0007We-HO; Sat, 09 Dec 2006 05:24:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GszNF-0007WW-KE for ipfix@ietf.org; Sat, 09 Dec 2006 05:24:05 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GszNC-0008P8-Vf for ipfix@ietf.org; Sat, 09 Dec 2006 05:24:05 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Dec 2006 11:24:01 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB9AO1CN026032 for ; Sat, 9 Dec 2006 11:24:01 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB9AO0AJ026595 for ; Sat, 9 Dec 2006 11:24:01 +0100 (MET) Received: from [10.61.65.30] (ams3-vpn-dhcp286.cisco.com [10.61.65.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA16542 for ; Sat, 9 Dec 2006 10:23:28 GMT Message-ID: <457A8E7D.1040707@cisco.com> Date: Sat, 09 Dec 2006 10:22:53 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: ipfix@ietf.org References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> <45780A37.8010905@cisco.com> <45782D40.20002@cisco.com> <457997A9.6010007@cisco.com> In-Reply-To: <457997A9.6010007@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2095; t=1165659841; x=1166523841; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Template=20ID=20as=20scope=20for=20Common=20Properties |Sender:=20; bh=iU7HiMldf3FvsM2iljK6aXt6UNmKSs/vcl08IO6vtoM=; b=vP3YnVkjSD7F5G86mau+ejs2HqFy8gWNbvV+oGBwcQs9S/j8T8ToEvmwIH+wdZFeWfiZFdPi 9PVAEvQcszcL34Ni9y/EBUZK99RWPDdtmAn8Tg+yiHqrXyK858QxaTFi; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [IPFIX] Template ID as scope for Common Properties X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi all There are a few issues with using the Template ID as scope for Common Properties. I am tempted to say that we shouldn't use the Template ID for scope for anything, except perhaps the template refresh time, or other data that is associated with the template, but not the records defined by that template. Issue 1: The Common Properties usually contain information that is vital to the understanding of the flow. So much so, that the draft implies that any Data Record that is received containing an undefined commonPropertiesID should be discarded. Now when the template ID is used then the Collecting Process has no way to know that this Template has further associated Common Properties. As such, it will continue to decode the Data Records, possibly writing them to disk, without knowing that it is missing vital information. Issue 2: Some collectors will simply write all the Data Records, options and flows, to disk and allow reconciliation later. For current options that use things like the ifIndex, this is fine. Using the TemplateID will now require them to store the ObservationDomainID and TemplateID with every received record. These identifiers are really for use in the Transport Session and are not supposed to be stored externally after decode. Issue 3: When sending information associated with the Template, such as the refresh time for the template, then you would expect to send an option Data Record containing the TemplateID as scope and the refresh time as the data. So there are two issues here: a) Is information sent with a TemplateID as scope associated with the template or with the Data Records associated with the template? b) If these features were used simultaneously then because they would be sending options Data Records with the same scope then they would overwrite each others data. (The way around this is to combine the data, sending a Data Record with the Template ID as scope and the Common Properties AND the refresh time as data). Thoughts? Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sat Dec 09 05:25:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GszNH-0007We-HO; Sat, 09 Dec 2006 05:24:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GszNF-0007WW-KE for ipfix@ietf.org; Sat, 09 Dec 2006 05:24:05 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GszNC-0008P8-Vf for ipfix@ietf.org; Sat, 09 Dec 2006 05:24:05 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Dec 2006 11:24:01 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB9AO1CN026032 for ; Sat, 9 Dec 2006 11:24:01 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB9AO0AJ026595 for ; Sat, 9 Dec 2006 11:24:01 +0100 (MET) Received: from [10.61.65.30] (ams3-vpn-dhcp286.cisco.com [10.61.65.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA16542 for ; Sat, 9 Dec 2006 10:23:28 GMT Message-ID: <457A8E7D.1040707@cisco.com> Date: Sat, 09 Dec 2006 10:22:53 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: ipfix@ietf.org References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> <45780A37.8010905@cisco.com> <45782D40.20002@cisco.com> <457997A9.6010007@cisco.com> In-Reply-To: <457997A9.6010007@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2095; t=1165659841; x=1166523841; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Template=20ID=20as=20scope=20for=20Common=20Properties |Sender:=20; bh=iU7HiMldf3FvsM2iljK6aXt6UNmKSs/vcl08IO6vtoM=; b=vP3YnVkjSD7F5G86mau+ejs2HqFy8gWNbvV+oGBwcQs9S/j8T8ToEvmwIH+wdZFeWfiZFdPi 9PVAEvQcszcL34Ni9y/EBUZK99RWPDdtmAn8Tg+yiHqrXyK858QxaTFi; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [IPFIX] Template ID as scope for Common Properties X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi all There are a few issues with using the Template ID as scope for Common Properties. I am tempted to say that we shouldn't use the Template ID for scope for anything, except perhaps the template refresh time, or other data that is associated with the template, but not the records defined by that template. Issue 1: The Common Properties usually contain information that is vital to the understanding of the flow. So much so, that the draft implies that any Data Record that is received containing an undefined commonPropertiesID should be discarded. Now when the template ID is used then the Collecting Process has no way to know that this Template has further associated Common Properties. As such, it will continue to decode the Data Records, possibly writing them to disk, without knowing that it is missing vital information. Issue 2: Some collectors will simply write all the Data Records, options and flows, to disk and allow reconciliation later. For current options that use things like the ifIndex, this is fine. Using the TemplateID will now require them to store the ObservationDomainID and TemplateID with every received record. These identifiers are really for use in the Transport Session and are not supposed to be stored externally after decode. Issue 3: When sending information associated with the Template, such as the refresh time for the template, then you would expect to send an option Data Record containing the TemplateID as scope and the refresh time as the data. So there are two issues here: a) Is information sent with a TemplateID as scope associated with the template or with the Data Records associated with the template? b) If these features were used simultaneously then because they would be sending options Data Records with the same scope then they would overwrite each others data. (The way around this is to combine the data, sending a Data Record with the Template ID as scope and the Common Properties AND the refresh time as data). Thoughts? Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sat Dec 09 13:10:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt6d1-0006lJ-Cl; Sat, 09 Dec 2006 13:08:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt6d0-0006lC-Lj for ipfix@ietf.org; Sat, 09 Dec 2006 13:08:50 -0500 Received: from smtp01.bis.na.blackberry.com ([216.9.248.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt6cz-0002XB-D9 for ipfix@ietf.org; Sat, 09 Dec 2006 13:08:50 -0500 Message-ID: <1561355564-1165687692-cardhu_blackberry.rim.net-1740801836-@bwe056-cell00.bisx.prod.on.blackberry> References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com><4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com><45780A37.8010905@cisco.com> <45782D40.20002@cisco.com><457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> In-Reply-To: <457A8E7D.1040707@cisco.com> Sensitivity: Normal Importance: Normal To: "Andrew Johnson" , ipfix@ietf.org Subject: Re: [IPFIX] Template ID as scope for Common Properties From: carter@qosient.com Date: Sat, 9 Dec 2006 18:08:05 +0000 MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: carter@qosient.com List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1429928610==" Errors-To: ipfix-bounces@ietf.org --===============1429928610== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" SGV5IEFuZHJldywNClNvbWUgb2YgeW91ciBzdGF0ZW1lbnRzIGFyZSBzdGFydGluZyB0byBnZXQg YXQgd2h5IGFyZ3VzIGlzIGRvaW5nIHdoYXQgaXRzIGRvaW5nLCB3aXRoIHJlZ2FyZCB0byBzY29w aW5nIGFuZCBzb3VyY2UgaWRlbnRpZmljYXRpb24uICBIb3dldmVyLCBJJ20gYWZyYWlkIHRoYXQg eW91IGd1eXMgaGF2ZSBnb25lIGRvd24gdGhlIGN1cnJlbnQgcGF0aCB0b28gZmFyPw0KDQpDYXJ0 ZXINCg0KQ2FydGVyIEJ1bGxhcmQNClFvU2llbnQgTExDDQoxNTAgRS4gNTd0aCBTdHJlZXQgU3Vp dGUgMTJEDQpOZXcgWW9yaywgTmV3IFlvcmsgMTAwMjINCisxIDIxMiA1ODgtOTEzMyBQaG9uZQ0K KzEgMjEyIDU4OC05MTM0IEZheCAgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBBbmRyZXcgSm9obnNvbiA8YW5kcmpvaG5AY2lzY28uY29tPg0KRGF0ZTogU2F0LCAwOSBEZWMg MjAwNiAxMDoyMjo1MyANClRvOmlwZml4QGlldGYub3JnDQpTdWJqZWN0OiBbSVBGSVhdIFRlbXBs YXRlIElEIGFzIHNjb3BlIGZvciBDb21tb24gUHJvcGVydGllcw0KDQpIaSBhbGwNCg0KVGhlcmUg YXJlIGEgZmV3IGlzc3VlcyB3aXRoIHVzaW5nIHRoZSBUZW1wbGF0ZSBJRCBhcyBzY29wZSBmb3Ig Q29tbW9uDQpQcm9wZXJ0aWVzLiAgSSBhbSB0ZW1wdGVkIHRvIHNheSB0aGF0IHdlIHNob3VsZG4n dCB1c2UgdGhlIFRlbXBsYXRlIElEIGZvcg0Kc2NvcGUgZm9yIGFueXRoaW5nLCBleGNlcHQgcGVy aGFwcyB0aGUgdGVtcGxhdGUgcmVmcmVzaCB0aW1lLCBvciBvdGhlcg0KZGF0YSB0aGF0IGlzIGFz c29jaWF0ZWQgd2l0aCB0aGUgdGVtcGxhdGUsIGJ1dCBub3QgdGhlIHJlY29yZHMgZGVmaW5lZCBi eQ0KdGhhdCB0ZW1wbGF0ZS4NCg0KDQpJc3N1ZSAxOg0KVGhlIENvbW1vbiBQcm9wZXJ0aWVzIHVz dWFsbHkgY29udGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlzIHZpdGFsIHRvIHRoZQ0KdW5kZXJzdGFu ZGluZyBvZiB0aGUgZmxvdy4gIFNvIG11Y2ggc28sIHRoYXQgdGhlIGRyYWZ0IGltcGxpZXMgdGhh dCBhbnkNCkRhdGEgUmVjb3JkIHRoYXQgaXMgcmVjZWl2ZWQgY29udGFpbmluZyBhbiB1bmRlZmlu ZWQgY29tbW9uUHJvcGVydGllc0lEDQpzaG91bGQgYmUgZGlzY2FyZGVkLg0KDQpOb3cgd2hlbiB0 aGUgdGVtcGxhdGUgSUQgaXMgdXNlZCB0aGVuIHRoZSBDb2xsZWN0aW5nIFByb2Nlc3MgaGFzIG5v IHdheQ0KdG8ga25vdyB0aGF0IHRoaXMgVGVtcGxhdGUgaGFzIGZ1cnRoZXIgYXNzb2NpYXRlZCBD b21tb24gUHJvcGVydGllcy4gIEFzDQpzdWNoLCBpdCB3aWxsIGNvbnRpbnVlIHRvIGRlY29kZSB0 aGUgRGF0YSBSZWNvcmRzLCBwb3NzaWJseSB3cml0aW5nIHRoZW0NCnRvIGRpc2ssIHdpdGhvdXQg a25vd2luZyB0aGF0IGl0IGlzIG1pc3Npbmcgdml0YWwgaW5mb3JtYXRpb24uDQoNCg0KSXNzdWUg MjoNClNvbWUgY29sbGVjdG9ycyB3aWxsIHNpbXBseSB3cml0ZSBhbGwgdGhlIERhdGEgUmVjb3Jk cywgb3B0aW9ucyBhbmQgZmxvd3MsDQp0byBkaXNrIGFuZCBhbGxvdyByZWNvbmNpbGlhdGlvbiBs YXRlci4gIEZvciBjdXJyZW50IG9wdGlvbnMgdGhhdCB1c2UNCnRoaW5ncyBsaWtlIHRoZSBpZklu ZGV4LCB0aGlzIGlzIGZpbmUuICBVc2luZyB0aGUgVGVtcGxhdGVJRCB3aWxsIG5vdw0KcmVxdWly ZSB0aGVtIHRvIHN0b3JlIHRoZSBPYnNlcnZhdGlvbkRvbWFpbklEIGFuZCBUZW1wbGF0ZUlEIHdp dGggZXZlcnkNCnJlY2VpdmVkIHJlY29yZC4gIFRoZXNlIGlkZW50aWZpZXJzIGFyZSByZWFsbHkg Zm9yIHVzZSBpbiB0aGUgVHJhbnNwb3J0DQpTZXNzaW9uIGFuZCBhcmUgbm90IHN1cHBvc2VkIHRv IGJlIHN0b3JlZCBleHRlcm5hbGx5IGFmdGVyIGRlY29kZS4NCg0KDQpJc3N1ZSAzOg0KV2hlbiBz ZW5kaW5nIGluZm9ybWF0aW9uIGFzc29jaWF0ZWQgd2l0aCB0aGUgVGVtcGxhdGUsIHN1Y2ggYXMg dGhlDQpyZWZyZXNoIHRpbWUgZm9yIHRoZSB0ZW1wbGF0ZSwgdGhlbiB5b3Ugd291bGQgZXhwZWN0 IHRvIHNlbmQgYW4gb3B0aW9uDQpEYXRhIFJlY29yZCBjb250YWluaW5nIHRoZSBUZW1wbGF0ZUlE IGFzIHNjb3BlIGFuZCB0aGUgcmVmcmVzaCB0aW1lIGFzDQp0aGUgZGF0YS4gIFNvIHRoZXJlIGFy ZSB0d28gaXNzdWVzIGhlcmU6DQogIGEpIElzIGluZm9ybWF0aW9uIHNlbnQgd2l0aCBhIFRlbXBs YXRlSUQgYXMgc2NvcGUgYXNzb2NpYXRlZCB3aXRoIHRoZQ0KICAgICB0ZW1wbGF0ZSBvciB3aXRo IHRoZSBEYXRhIFJlY29yZHMgYXNzb2NpYXRlZCB3aXRoIHRoZSB0ZW1wbGF0ZT8NCg0KICBiKSBJ ZiB0aGVzZSBmZWF0dXJlcyB3ZXJlIHVzZWQgc2ltdWx0YW5lb3VzbHkgdGhlbiBiZWNhdXNlIHRo ZXkgd291bGQNCiAgICAgYmUgc2VuZGluZyBvcHRpb25zIERhdGEgUmVjb3JkcyB3aXRoIHRoZSBz YW1lIHNjb3BlIHRoZW4gdGhleSB3b3VsZA0KICAgICBvdmVyd3JpdGUgZWFjaCBvdGhlcnMgZGF0 YS4gIChUaGUgd2F5IGFyb3VuZCB0aGlzIGlzIHRvIGNvbWJpbmUgdGhlDQogICAgIGRhdGEsIHNl bmRpbmcgYSBEYXRhIFJlY29yZCB3aXRoIHRoZSBUZW1wbGF0ZSBJRCBhcyBzY29wZSBhbmQgdGhl DQogICAgIENvbW1vbiBQcm9wZXJ0aWVzIEFORCB0aGUgcmVmcmVzaCB0aW1lIGFzIGRhdGEpLg0K DQoNClRob3VnaHRzPw0KDQoNCkFuZHJldw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KSVBGSVggbWFpbGluZyBsaXN0DQpJUEZJWEBpZXRmLm9yZw0K aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBmaXgNCg0K --===============1429928610== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1429928610==-- From ipfix-bounces@ietf.org Sat Dec 09 13:10:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt6d1-0006lJ-Cl; Sat, 09 Dec 2006 13:08:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt6d0-0006lC-Lj for ipfix@ietf.org; Sat, 09 Dec 2006 13:08:50 -0500 Received: from smtp01.bis.na.blackberry.com ([216.9.248.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt6cz-0002XB-D9 for ipfix@ietf.org; Sat, 09 Dec 2006 13:08:50 -0500 Message-ID: <1561355564-1165687692-cardhu_blackberry.rim.net-1740801836-@bwe056-cell00.bisx.prod.on.blackberry> References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com><4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com><45780A37.8010905@cisco.com> <45782D40.20002@cisco.com><457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> In-Reply-To: <457A8E7D.1040707@cisco.com> Sensitivity: Normal Importance: Normal To: "Andrew Johnson" , ipfix@ietf.org Subject: Re: [IPFIX] Template ID as scope for Common Properties From: carter@qosient.com Date: Sat, 9 Dec 2006 18:08:05 +0000 MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: carter@qosient.com List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1429928610==" Errors-To: ipfix-bounces@ietf.org --===============1429928610== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" SGV5IEFuZHJldywNClNvbWUgb2YgeW91ciBzdGF0ZW1lbnRzIGFyZSBzdGFydGluZyB0byBnZXQg YXQgd2h5IGFyZ3VzIGlzIGRvaW5nIHdoYXQgaXRzIGRvaW5nLCB3aXRoIHJlZ2FyZCB0byBzY29w aW5nIGFuZCBzb3VyY2UgaWRlbnRpZmljYXRpb24uICBIb3dldmVyLCBJJ20gYWZyYWlkIHRoYXQg eW91IGd1eXMgaGF2ZSBnb25lIGRvd24gdGhlIGN1cnJlbnQgcGF0aCB0b28gZmFyPw0KDQpDYXJ0 ZXINCg0KQ2FydGVyIEJ1bGxhcmQNClFvU2llbnQgTExDDQoxNTAgRS4gNTd0aCBTdHJlZXQgU3Vp dGUgMTJEDQpOZXcgWW9yaywgTmV3IFlvcmsgMTAwMjINCisxIDIxMiA1ODgtOTEzMyBQaG9uZQ0K KzEgMjEyIDU4OC05MTM0IEZheCAgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBBbmRyZXcgSm9obnNvbiA8YW5kcmpvaG5AY2lzY28uY29tPg0KRGF0ZTogU2F0LCAwOSBEZWMg MjAwNiAxMDoyMjo1MyANClRvOmlwZml4QGlldGYub3JnDQpTdWJqZWN0OiBbSVBGSVhdIFRlbXBs YXRlIElEIGFzIHNjb3BlIGZvciBDb21tb24gUHJvcGVydGllcw0KDQpIaSBhbGwNCg0KVGhlcmUg YXJlIGEgZmV3IGlzc3VlcyB3aXRoIHVzaW5nIHRoZSBUZW1wbGF0ZSBJRCBhcyBzY29wZSBmb3Ig Q29tbW9uDQpQcm9wZXJ0aWVzLiAgSSBhbSB0ZW1wdGVkIHRvIHNheSB0aGF0IHdlIHNob3VsZG4n dCB1c2UgdGhlIFRlbXBsYXRlIElEIGZvcg0Kc2NvcGUgZm9yIGFueXRoaW5nLCBleGNlcHQgcGVy aGFwcyB0aGUgdGVtcGxhdGUgcmVmcmVzaCB0aW1lLCBvciBvdGhlcg0KZGF0YSB0aGF0IGlzIGFz c29jaWF0ZWQgd2l0aCB0aGUgdGVtcGxhdGUsIGJ1dCBub3QgdGhlIHJlY29yZHMgZGVmaW5lZCBi eQ0KdGhhdCB0ZW1wbGF0ZS4NCg0KDQpJc3N1ZSAxOg0KVGhlIENvbW1vbiBQcm9wZXJ0aWVzIHVz dWFsbHkgY29udGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlzIHZpdGFsIHRvIHRoZQ0KdW5kZXJzdGFu ZGluZyBvZiB0aGUgZmxvdy4gIFNvIG11Y2ggc28sIHRoYXQgdGhlIGRyYWZ0IGltcGxpZXMgdGhh dCBhbnkNCkRhdGEgUmVjb3JkIHRoYXQgaXMgcmVjZWl2ZWQgY29udGFpbmluZyBhbiB1bmRlZmlu ZWQgY29tbW9uUHJvcGVydGllc0lEDQpzaG91bGQgYmUgZGlzY2FyZGVkLg0KDQpOb3cgd2hlbiB0 aGUgdGVtcGxhdGUgSUQgaXMgdXNlZCB0aGVuIHRoZSBDb2xsZWN0aW5nIFByb2Nlc3MgaGFzIG5v IHdheQ0KdG8ga25vdyB0aGF0IHRoaXMgVGVtcGxhdGUgaGFzIGZ1cnRoZXIgYXNzb2NpYXRlZCBD b21tb24gUHJvcGVydGllcy4gIEFzDQpzdWNoLCBpdCB3aWxsIGNvbnRpbnVlIHRvIGRlY29kZSB0 aGUgRGF0YSBSZWNvcmRzLCBwb3NzaWJseSB3cml0aW5nIHRoZW0NCnRvIGRpc2ssIHdpdGhvdXQg a25vd2luZyB0aGF0IGl0IGlzIG1pc3Npbmcgdml0YWwgaW5mb3JtYXRpb24uDQoNCg0KSXNzdWUg MjoNClNvbWUgY29sbGVjdG9ycyB3aWxsIHNpbXBseSB3cml0ZSBhbGwgdGhlIERhdGEgUmVjb3Jk cywgb3B0aW9ucyBhbmQgZmxvd3MsDQp0byBkaXNrIGFuZCBhbGxvdyByZWNvbmNpbGlhdGlvbiBs YXRlci4gIEZvciBjdXJyZW50IG9wdGlvbnMgdGhhdCB1c2UNCnRoaW5ncyBsaWtlIHRoZSBpZklu ZGV4LCB0aGlzIGlzIGZpbmUuICBVc2luZyB0aGUgVGVtcGxhdGVJRCB3aWxsIG5vdw0KcmVxdWly ZSB0aGVtIHRvIHN0b3JlIHRoZSBPYnNlcnZhdGlvbkRvbWFpbklEIGFuZCBUZW1wbGF0ZUlEIHdp dGggZXZlcnkNCnJlY2VpdmVkIHJlY29yZC4gIFRoZXNlIGlkZW50aWZpZXJzIGFyZSByZWFsbHkg Zm9yIHVzZSBpbiB0aGUgVHJhbnNwb3J0DQpTZXNzaW9uIGFuZCBhcmUgbm90IHN1cHBvc2VkIHRv IGJlIHN0b3JlZCBleHRlcm5hbGx5IGFmdGVyIGRlY29kZS4NCg0KDQpJc3N1ZSAzOg0KV2hlbiBz ZW5kaW5nIGluZm9ybWF0aW9uIGFzc29jaWF0ZWQgd2l0aCB0aGUgVGVtcGxhdGUsIHN1Y2ggYXMg dGhlDQpyZWZyZXNoIHRpbWUgZm9yIHRoZSB0ZW1wbGF0ZSwgdGhlbiB5b3Ugd291bGQgZXhwZWN0 IHRvIHNlbmQgYW4gb3B0aW9uDQpEYXRhIFJlY29yZCBjb250YWluaW5nIHRoZSBUZW1wbGF0ZUlE IGFzIHNjb3BlIGFuZCB0aGUgcmVmcmVzaCB0aW1lIGFzDQp0aGUgZGF0YS4gIFNvIHRoZXJlIGFy ZSB0d28gaXNzdWVzIGhlcmU6DQogIGEpIElzIGluZm9ybWF0aW9uIHNlbnQgd2l0aCBhIFRlbXBs YXRlSUQgYXMgc2NvcGUgYXNzb2NpYXRlZCB3aXRoIHRoZQ0KICAgICB0ZW1wbGF0ZSBvciB3aXRo IHRoZSBEYXRhIFJlY29yZHMgYXNzb2NpYXRlZCB3aXRoIHRoZSB0ZW1wbGF0ZT8NCg0KICBiKSBJ ZiB0aGVzZSBmZWF0dXJlcyB3ZXJlIHVzZWQgc2ltdWx0YW5lb3VzbHkgdGhlbiBiZWNhdXNlIHRo ZXkgd291bGQNCiAgICAgYmUgc2VuZGluZyBvcHRpb25zIERhdGEgUmVjb3JkcyB3aXRoIHRoZSBz YW1lIHNjb3BlIHRoZW4gdGhleSB3b3VsZA0KICAgICBvdmVyd3JpdGUgZWFjaCBvdGhlcnMgZGF0 YS4gIChUaGUgd2F5IGFyb3VuZCB0aGlzIGlzIHRvIGNvbWJpbmUgdGhlDQogICAgIGRhdGEsIHNl bmRpbmcgYSBEYXRhIFJlY29yZCB3aXRoIHRoZSBUZW1wbGF0ZSBJRCBhcyBzY29wZSBhbmQgdGhl DQogICAgIENvbW1vbiBQcm9wZXJ0aWVzIEFORCB0aGUgcmVmcmVzaCB0aW1lIGFzIGRhdGEpLg0K DQoNClRob3VnaHRzPw0KDQoNCkFuZHJldw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KSVBGSVggbWFpbGluZyBsaXN0DQpJUEZJWEBpZXRmLm9yZw0K aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBmaXgNCg0K --===============1429928610== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1429928610==-- From ipfix-bounces@ietf.org Sun Dec 10 05:19:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtLk1-00007K-9C; Sun, 10 Dec 2006 05:17:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtLjz-00007D-R0 for ipfix@ietf.org; Sun, 10 Dec 2006 05:17:03 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtLjq-0002Ll-EF for ipfix@ietf.org; Sun, 10 Dec 2006 05:17:03 -0500 Received: from [192.168.1.128] (unknown [91.89.53.224]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 2177F13CF82; Sun, 10 Dec 2006 11:21:18 +0100 (CET) Date: Sun, 10 Dec 2006 11:16:40 +0100 From: Juergen Quittek To: Andrew Johnson , ipfix@ietf.org Subject: Re: [IPFIX] Template ID as scope for Common Properties Message-ID: In-Reply-To: <457A8E7D.1040707@cisco.com> References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> <45780A37.8010905@cisco.com> <45782D40.20002@cisco.com> <457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Andrew, --On 09.12.06 10:22 +0000 Andrew Johnson wrote: > Hi all > > There are a few issues with using the Template ID as scope for Common > Properties. I am tempted to say that we shouldn't use the Template ID for > scope for anything, except perhaps the template refresh time, or other > data that is associated with the template, but not the records defined by > that template. > > > Issue 1: > The Common Properties usually contain information that is vital to the > understanding of the flow. So much so, that the draft implies that any > Data Record that is received containing an undefined commonPropertiesID > should be discarded. > > Now when the template ID is used then the Collecting Process has no way > to know that this Template has further associated Common Properties. As Sorry, I don't get the point here. Could you elaborate it? > such, it will continue to decode the Data Records, possibly writing them > to disk, without knowing that it is missing vital information. > > > Issue 2: > Some collectors will simply write all the Data Records, options and flows, > to disk and allow reconciliation later. For current options that use > things like the ifIndex, this is fine. Using the TemplateID will now > require them to store the ObservationDomainID and TemplateID with every > received record. These identifiers are really for use in the Transport > Session and are not supposed to be stored externally after decode. Maybe this issue could be solved by a structured IPFIX file format? Thanks, Juergen > Issue 3: > When sending information associated with the Template, such as the > refresh time for the template, then you would expect to send an option > Data Record containing the TemplateID as scope and the refresh time as > the data. So there are two issues here: > a) Is information sent with a TemplateID as scope associated with the > template or with the Data Records associated with the template? > > b) If these features were used simultaneously then because they would > be sending options Data Records with the same scope then they would > overwrite each others data. (The way around this is to combine the > data, sending a Data Record with the Template ID as scope and the > Common Properties AND the refresh time as data). > > > Thoughts? > > > Andrew > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 4342-115 NEC Europe Ltd., Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Dec 10 05:19:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtLk1-00007K-9C; Sun, 10 Dec 2006 05:17:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtLjz-00007D-R0 for ipfix@ietf.org; Sun, 10 Dec 2006 05:17:03 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtLjq-0002Ll-EF for ipfix@ietf.org; Sun, 10 Dec 2006 05:17:03 -0500 Received: from [192.168.1.128] (unknown [91.89.53.224]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 2177F13CF82; Sun, 10 Dec 2006 11:21:18 +0100 (CET) Date: Sun, 10 Dec 2006 11:16:40 +0100 From: Juergen Quittek To: Andrew Johnson , ipfix@ietf.org Subject: Re: [IPFIX] Template ID as scope for Common Properties Message-ID: In-Reply-To: <457A8E7D.1040707@cisco.com> References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> <45780A37.8010905@cisco.com> <45782D40.20002@cisco.com> <457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Andrew, --On 09.12.06 10:22 +0000 Andrew Johnson wrote: > Hi all > > There are a few issues with using the Template ID as scope for Common > Properties. I am tempted to say that we shouldn't use the Template ID for > scope for anything, except perhaps the template refresh time, or other > data that is associated with the template, but not the records defined by > that template. > > > Issue 1: > The Common Properties usually contain information that is vital to the > understanding of the flow. So much so, that the draft implies that any > Data Record that is received containing an undefined commonPropertiesID > should be discarded. > > Now when the template ID is used then the Collecting Process has no way > to know that this Template has further associated Common Properties. As Sorry, I don't get the point here. Could you elaborate it? > such, it will continue to decode the Data Records, possibly writing them > to disk, without knowing that it is missing vital information. > > > Issue 2: > Some collectors will simply write all the Data Records, options and flows, > to disk and allow reconciliation later. For current options that use > things like the ifIndex, this is fine. Using the TemplateID will now > require them to store the ObservationDomainID and TemplateID with every > received record. These identifiers are really for use in the Transport > Session and are not supposed to be stored externally after decode. Maybe this issue could be solved by a structured IPFIX file format? Thanks, Juergen > Issue 3: > When sending information associated with the Template, such as the > refresh time for the template, then you would expect to send an option > Data Record containing the TemplateID as scope and the refresh time as > the data. So there are two issues here: > a) Is information sent with a TemplateID as scope associated with the > template or with the Data Records associated with the template? > > b) If these features were used simultaneously then because they would > be sending options Data Records with the same scope then they would > overwrite each others data. (The way around this is to combine the > data, sending a Data Record with the Template ID as scope and the > Common Properties AND the refresh time as data). > > > Thoughts? > > > Andrew > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 4342-115 NEC Europe Ltd., Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Dec 10 07:12:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtNWu-0007Q2-Os; Sun, 10 Dec 2006 07:11:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtNWt-0007Pe-Ce for ipfix@ietf.org; Sun, 10 Dec 2006 07:11:39 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtNWq-00030a-Qw for ipfix@ietf.org; Sun, 10 Dec 2006 07:11:39 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Dec 2006 13:11:35 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBACBXIV025412; Sun, 10 Dec 2006 13:11:33 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBACBTAJ015986; Sun, 10 Dec 2006 13:11:29 +0100 (MET) Received: from [10.61.65.30] (ams3-vpn-dhcp286.cisco.com [10.61.65.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA22174; Sun, 10 Dec 2006 12:11:28 GMT Message-ID: <457BF952.6060405@cisco.com> Date: Sun, 10 Dec 2006 12:10:58 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [IPFIX] Template ID as scope for Common Properties References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> <45780A37.8010905@cisco.com> <45782D40.20002@cisco.com> <457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4259; t=1165752693; x=1166616693; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Template=20ID=20as=20scope=20for=20Common=2 0Properties |Sender:=20; bh=KXROIH0A8jpPiZ7Iop7HaGoEFBlvdp4ygYbl2viyTFk=; b=VIEXnJyZyjMWucptxMpzK8k3nSRGB5H3jMWcRPBsBHfQFESyvwVY6inog/t8ZIQy7Fr/6k78 0aNE5TaSod8UPudMj36YEADAHAAO2vuWiT9//0m1vcvunCwIzphj4lGG; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Juergen Quittek wrote: > Hi Andrew, > > --On 09.12.06 10:22 +0000 Andrew Johnson wrote: > >> Hi all >> >> There are a few issues with using the Template ID as scope for Common >> Properties. I am tempted to say that we shouldn't use the Template ID for >> scope for anything, except perhaps the template refresh time, or other >> data that is associated with the template, but not the records defined by >> that template. >> >> >> Issue 1: >> The Common Properties usually contain information that is vital to the >> understanding of the flow. So much so, that the draft implies that any >> Data Record that is received containing an undefined commonPropertiesID >> should be discarded. >> >> Now when the template ID is used then the Collecting Process has no way >> to know that this Template has further associated Common Properties. As > > Sorry, I don't get the point here. Could you elaborate it? Certainly. In the draft, although it is not explicitly said, if a Data Record is recieved that contains a cpID that has not been defined then it should be considered meaningless or at least incomplete and discarded. >From section 7.1: If the Common Properties are not refreshed before that lifetime has expired, the Collecting Process MUST discard the corresponding definition of the commonPropertiesID and any current and future associated Data Records. In which case, an alarm MUST be logged. The argument is that the Flow is complete without both the Specific Properties and the Common Properties. So if a Data Record is received that has a cpID that isn't defined then the Collecting Process knows that something is missing and will discard the Flow (perhaps after waiting a short time to see if the definition is simply late). Now, when the TemplateID is used to associate the Common Properties with Data Records that are defined by the Template, and that definition is lost before reaching the Collector, then it has no way of knowing that this vital information is lost and will continue to decode the Data Records without the Common Properties. >> such, it will continue to decode the Data Records, possibly writing them >> to disk, without knowing that it is missing vital information. >> >> >> Issue 2: >> Some collectors will simply write all the Data Records, options and flows, >> to disk and allow reconciliation later. For current options that use >> things like the ifIndex, this is fine. Using the TemplateID will now >> require them to store the ObservationDomainID and TemplateID with every >> received record. These identifiers are really for use in the Transport >> Session and are not supposed to be stored externally after decode. > > Maybe this issue could be solved by a structured IPFIX file format? We can't dictate the output of the Collecting Process just so that a Collector can use Reducing Redundancy. The Templates and Template IDs are part of the transport mechanism and I don't think they should form part of the data that is output by the Collecting Process. I think Issue 3a below is a big one. Template IDs should refer to Templates and not Data Records that are defined by those Templates. regards Andrew >> Issue 3: >> When sending information associated with the Template, such as the >> refresh time for the template, then you would expect to send an option >> Data Record containing the TemplateID as scope and the refresh time as >> the data. So there are two issues here: >> a) Is information sent with a TemplateID as scope associated with the >> template or with the Data Records associated with the template? >> >> b) If these features were used simultaneously then because they would >> be sending options Data Records with the same scope then they would >> overwrite each others data. (The way around this is to combine the >> data, sending a Data Record with the Template ID as scope and the >> Common Properties AND the refresh time as data). >> >> >> Thoughts? >> >> >> Andrew >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipfix > > > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Dec 10 07:12:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtNWu-0007Q2-Os; Sun, 10 Dec 2006 07:11:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtNWt-0007Pe-Ce for ipfix@ietf.org; Sun, 10 Dec 2006 07:11:39 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtNWq-00030a-Qw for ipfix@ietf.org; Sun, 10 Dec 2006 07:11:39 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Dec 2006 13:11:35 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBACBXIV025412; Sun, 10 Dec 2006 13:11:33 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBACBTAJ015986; Sun, 10 Dec 2006 13:11:29 +0100 (MET) Received: from [10.61.65.30] (ams3-vpn-dhcp286.cisco.com [10.61.65.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA22174; Sun, 10 Dec 2006 12:11:28 GMT Message-ID: <457BF952.6060405@cisco.com> Date: Sun, 10 Dec 2006 12:10:58 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [IPFIX] Template ID as scope for Common Properties References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> <45780A37.8010905@cisco.com> <45782D40.20002@cisco.com> <457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4259; t=1165752693; x=1166616693; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Template=20ID=20as=20scope=20for=20Common=2 0Properties |Sender:=20; bh=KXROIH0A8jpPiZ7Iop7HaGoEFBlvdp4ygYbl2viyTFk=; b=VIEXnJyZyjMWucptxMpzK8k3nSRGB5H3jMWcRPBsBHfQFESyvwVY6inog/t8ZIQy7Fr/6k78 0aNE5TaSod8UPudMj36YEADAHAAO2vuWiT9//0m1vcvunCwIzphj4lGG; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Juergen Quittek wrote: > Hi Andrew, > > --On 09.12.06 10:22 +0000 Andrew Johnson wrote: > >> Hi all >> >> There are a few issues with using the Template ID as scope for Common >> Properties. I am tempted to say that we shouldn't use the Template ID for >> scope for anything, except perhaps the template refresh time, or other >> data that is associated with the template, but not the records defined by >> that template. >> >> >> Issue 1: >> The Common Properties usually contain information that is vital to the >> understanding of the flow. So much so, that the draft implies that any >> Data Record that is received containing an undefined commonPropertiesID >> should be discarded. >> >> Now when the template ID is used then the Collecting Process has no way >> to know that this Template has further associated Common Properties. As > > Sorry, I don't get the point here. Could you elaborate it? Certainly. In the draft, although it is not explicitly said, if a Data Record is recieved that contains a cpID that has not been defined then it should be considered meaningless or at least incomplete and discarded. >From section 7.1: If the Common Properties are not refreshed before that lifetime has expired, the Collecting Process MUST discard the corresponding definition of the commonPropertiesID and any current and future associated Data Records. In which case, an alarm MUST be logged. The argument is that the Flow is complete without both the Specific Properties and the Common Properties. So if a Data Record is received that has a cpID that isn't defined then the Collecting Process knows that something is missing and will discard the Flow (perhaps after waiting a short time to see if the definition is simply late). Now, when the TemplateID is used to associate the Common Properties with Data Records that are defined by the Template, and that definition is lost before reaching the Collector, then it has no way of knowing that this vital information is lost and will continue to decode the Data Records without the Common Properties. >> such, it will continue to decode the Data Records, possibly writing them >> to disk, without knowing that it is missing vital information. >> >> >> Issue 2: >> Some collectors will simply write all the Data Records, options and flows, >> to disk and allow reconciliation later. For current options that use >> things like the ifIndex, this is fine. Using the TemplateID will now >> require them to store the ObservationDomainID and TemplateID with every >> received record. These identifiers are really for use in the Transport >> Session and are not supposed to be stored externally after decode. > > Maybe this issue could be solved by a structured IPFIX file format? We can't dictate the output of the Collecting Process just so that a Collector can use Reducing Redundancy. The Templates and Template IDs are part of the transport mechanism and I don't think they should form part of the data that is output by the Collecting Process. I think Issue 3a below is a big one. Template IDs should refer to Templates and not Data Records that are defined by those Templates. regards Andrew >> Issue 3: >> When sending information associated with the Template, such as the >> refresh time for the template, then you would expect to send an option >> Data Record containing the TemplateID as scope and the refresh time as >> the data. So there are two issues here: >> a) Is information sent with a TemplateID as scope associated with the >> template or with the Data Records associated with the template? >> >> b) If these features were used simultaneously then because they would >> be sending options Data Records with the same scope then they would >> overwrite each others data. (The way around this is to combine the >> data, sending a Data Record with the Template ID as scope and the >> Common Properties AND the refresh time as data). >> >> >> Thoughts? >> >> >> Andrew >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipfix > > > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Dec 10 07:14:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtNZq-0000Os-OR; Sun, 10 Dec 2006 07:14:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtNZp-0000Nv-Gs for ipfix@ietf.org; Sun, 10 Dec 2006 07:14:41 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtNZo-0003YO-82 for ipfix@ietf.org; Sun, 10 Dec 2006 07:14:41 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Dec 2006 13:14:41 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBACEdnq026540; Sun, 10 Dec 2006 13:14:39 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBACEcAJ017269; Sun, 10 Dec 2006 13:14:38 +0100 (MET) Received: from [10.61.65.30] (ams3-vpn-dhcp286.cisco.com [10.61.65.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA22253; Sun, 10 Dec 2006 12:14:36 GMT Message-ID: <457BFA0D.7070300@cisco.com> Date: Sun, 10 Dec 2006 12:14:05 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: carter@qosient.com Subject: Re: [IPFIX] Template ID as scope for Common Properties References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com><4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com><45780A37.8010905@cisco.com> <45782D40.20002@cisco.com><457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> <1561355564-1165687692-cardhu_blackberry.rim.net-1740801836-@bwe056-cell00.bisx.prod.on.blackberry> In-Reply-To: <1561355564-1165687692-cardhu_blackberry.rim.net-1740801836-@bwe056-cell00.bisx.prod.on.blackberry> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=306; t=1165752879; x=1166616879; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Template=20ID=20as=20scope=20for=20Common=2 0Properties |Sender:=20; bh=HEUYUyB30xWJRXDcvm3JFEU0Cz8+oF+wvJRL+MYuJzg=; b=pgUorUu4Px8fMIe89BDuK22hK8HAaqMBLPpgRNI1bpgA/IPzXN65yCR9bx6mCfgxD356zkDp VTeDZzjh06GK20suXKQ+hLhlv5mRiU5CEj2Gen7pO6OFIzAw3cwOucYY; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org carter@qosient.com wrote: > Hey Andrew, > Some of your statements are starting to get at why argus is doing what > its doing, with regard to scoping and source identification. However, > I'm afraid that you guys have gone down the current path too far? So what is Argus doing and why? Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Dec 10 07:14:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtNZq-0000Os-OR; Sun, 10 Dec 2006 07:14:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtNZp-0000Nv-Gs for ipfix@ietf.org; Sun, 10 Dec 2006 07:14:41 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtNZo-0003YO-82 for ipfix@ietf.org; Sun, 10 Dec 2006 07:14:41 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Dec 2006 13:14:41 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBACEdnq026540; Sun, 10 Dec 2006 13:14:39 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBACEcAJ017269; Sun, 10 Dec 2006 13:14:38 +0100 (MET) Received: from [10.61.65.30] (ams3-vpn-dhcp286.cisco.com [10.61.65.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA22253; Sun, 10 Dec 2006 12:14:36 GMT Message-ID: <457BFA0D.7070300@cisco.com> Date: Sun, 10 Dec 2006 12:14:05 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: carter@qosient.com Subject: Re: [IPFIX] Template ID as scope for Common Properties References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com><4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com><45780A37.8010905@cisco.com> <45782D40.20002@cisco.com><457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> <1561355564-1165687692-cardhu_blackberry.rim.net-1740801836-@bwe056-cell00.bisx.prod.on.blackberry> In-Reply-To: <1561355564-1165687692-cardhu_blackberry.rim.net-1740801836-@bwe056-cell00.bisx.prod.on.blackberry> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=306; t=1165752879; x=1166616879; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Template=20ID=20as=20scope=20for=20Common=2 0Properties |Sender:=20; bh=HEUYUyB30xWJRXDcvm3JFEU0Cz8+oF+wvJRL+MYuJzg=; b=pgUorUu4Px8fMIe89BDuK22hK8HAaqMBLPpgRNI1bpgA/IPzXN65yCR9bx6mCfgxD356zkDp VTeDZzjh06GK20suXKQ+hLhlv5mRiU5CEj2Gen7pO6OFIzAw3cwOucYY; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org carter@qosient.com wrote: > Hey Andrew, > Some of your statements are starting to get at why argus is doing what > its doing, with regard to scoping and source identification. However, > I'm afraid that you guys have gone down the current path too far? So what is Argus doing and why? Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From vfirus@autotudos.hu Sun Dec 10 16:18:56 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtW4W-0002ip-Fl for ipfix-archive@lists.ietf.org; Sun, 10 Dec 2006 16:18:56 -0500 Received: from [84.13.21.124] (helo=[84.13.21.124]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GtW4M-0006Bc-81 for ipfix-archive@lists.ietf.org; Sun, 10 Dec 2006 16:18:56 -0500 Received: from SoUyC (unknown [148.189.63.70]) by autotudos.hu with ESMTP id C8C619DF2762 for ; Sun, 20 Jan 2002 10:35:48 -0000 Message-ID: <001201c1a19e$2f007b70$00000000@inga8mnq0k49pg> From: "terrda terrqa" To: ipfix-archive@lists.ietf.org Subject: cases RIAA Date: Sun, 20 Jan 2002 10:35:30 -0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000E_01C1A19E.2F007B70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.7 (++) X-Scan-Signature: 58b614506802734014829a093beb6879 ------=_NextPart_000_000E_01C1A19E.2F007B70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C1A19E.2F007B70" ------=_NextPart_001_000F_01C1A19E.2F007B70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bnews nbews hnews nhews jnews njews. Camiuno camoino camiono camlino camilno camikno camyino. Headlines = funding mesa del sol! Written loader, changes unlike version requires. Ourses curses corses couses coures courss course dree. Newd newx newz bbusiness buusiness bussiness busiiness. Busihness = busieness busjiness busijness busibness, businbess, businhess, businjess = busimness. European union processing purposeful availment, benefits. Nws nes vusiness gusiness husiness nusiness bysiness bisiness. Viryus viruys virius viruis virhus viruhs virkus viruks virjus! There = ripping off permission payment. Establish quotthese crowed somebody elses work. Camibo camiho camijo = camimo camini caminp camine caminu camina! Couirses, couhrses coukrses cojurses coujrses, couerses coureses = coutrses. Oasadx edonkey licenses installing unwanted, ben edelman. Sit noticequot quotnows get before does happened. Googlf googlo googla googli googld, googlu, googls, qd! Concerned middle linequot kim weatherall lecturer. Offers, tracks = browsing display hijacker redirects, errors. Couirses couhrses coukrses cojurses coujrses couerses coureses coutrses! = Magazines image libraries view files must. Spot emphasizes using last = modified november recalls, release meetings? Content newest soar = unveils, redesigned planet, pda, arnold associates. Script the reaching atrisk audiences and, todays, other challenges. Text = gnu details registered trademark incprivacy aussie. Networked strictly = procedure notify. Floor ottawa ontario canada kb ethis supercedes agreements. ------=_NextPart_001_000F_01C1A19E.2F007B70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"Vonage"
Bnews nbews hnews nhews jnews = njews.
Camiuno camoino camiono camlino camilno = camikno=20 camyino. Headlines funding mesa del sol! Written loader, changes unlike = version requires.
Ourses curses corses couses coures = courss course dree.
Newd newx newz bbusiness buusiness = bussiness=20 busiiness. Busihness busieness busjiness busijness busibness, businbess, = businhess, businjess busimness.
European union processing purposeful = availment, benefits.
Nws nes vusiness gusiness husiness = nusiness=20 bysiness bisiness.
Viryus viruys virius viruis virhus = viruhs virkus=20 viruks virjus! There ripping off permission payment.
Establish quotthese crowed somebody = elses work.=20 Camibo camiho camijo camimo camini caminp camine caminu = camina!
Couirses, couhrses coukrses cojurses = coujrses,=20 couerses coureses coutrses. Oasadx edonkey licenses installing unwanted, = ben edelman.
Sit noticequot quotnows get before does = happened.
Googlf googlo googla googli googld, = googlu, googls, qd!
Concerned middle linequot kim = weatherall lecturer.=20 Offers, tracks browsing display hijacker redirects, errors.
Couirses couhrses coukrses cojurses = coujrses=20 couerses coureses coutrses! Magazines image libraries view files must. = Spot=20 emphasizes using last modified november recalls, release meetings? = Content=20 newest soar unveils, redesigned planet, pda, arnold = associates.
Script the reaching atrisk audiences = and, todays,=20 other challenges. Text gnu details registered trademark incprivacy = aussie.=20 Networked strictly procedure notify.
Floor ottawa ontario canada kb ethis = supercedes=20 agreements.
------=_NextPart_001_000F_01C1A19E.2F007B70-- ------=_NextPart_000_000E_01C1A19E.2F007B70 Content-Type: image/gif; name="usersquot.gif" Content-Transfer-Encoding: base64 Content-ID: <000d01c1a19e$2f007b70$00000000@inga8mnq0k49pg> R0lGODlhYAJ8AofrAAkMBn8ADQCMAICGAA4EiYoAeAmDfcy/v8vfup7G90YgA2YVAH4oCacuALoU AOwiDAA8AC1NDjc4BWU6B3k0CplEALdGAOk/BwBaBhdYDExRBlhYAIBfAKpWAsdsANpVAACGACVx AEiMAF2AAHR2C6SJAMeIC95yAAmUBySgADWqC1+YAIatA5WpC82mDeerAAa7CBa6DkS1AGezAI7G AqbNAMe1AOTKAADqBx7dAEHmAFjcAH7TA6biA83SDNrfCQ0AThkASEwAQlEAPHYOSKYONsMAOOYA SwAjMxokQjUfSl8YNoMgNZcoS8oVRu0oNgo+QBQ3RzU0SVpHOns6NZ48Oso8NNFESgBkNi1dRU5Y RGNXPHJTAKlgMcZoNOlYQwl8NR6MOjZ5MlWMQoCAM5mHPcd6MeF1NAKkORKsSkObNFqfMYWfO5yT MbqbONWSMQDJORvDSkmyOm64ToPBQJjKS7jJPeHBRwzgNxjkSDTgQW3sMovoO5zXOs3UTuPkOgAA iSUCfUoLfGQNh4QOiJUAdcgNdu4AiQ4pdx4jdEoqdlQjfo0RdpQddLoudOopgwAycyg3c0ZJe1c7 g3REeZ80fc41htY3gwBYhyNojTlRhVpueHVle6ZYcrlritdbdACCfih/hzl7h1hzind3fqR6jsN3 gNp/gwegfC6WeEiUfF2df3eehJOmicWicdSqeQi1eSK3fku/c2DAennEfpHMjbq9edG4fgDhfxXg gTzrhFjVe4PhdJXhhLXpeerjiAsAxiwAtEkNymIMwnEKtKkOyr4BvO4DtwUYtS4WwkgmslcSuYoc yKoey8wex+kdxwJFvhxDtD00s1oxzYg3w5tHzskxstw9uABSzCpnxUtny2ddsYhYvZVgwcVczd1X xA2BwiGNw0d0wlyMwI51vZONuMSHyON5vQydwyGZvEiru22rwIyjwJadzbunu92WvwDAvhHLvz3L uW7KuHvHzKK0vvj98qibl3d9eP0AAAP/CfbzAAYN8PcL8wr////6/yH5BACkp30ALAAAAABgAnwC Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKbGivpMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0KMyRSJMqXcq0qdOnUKNKnUp1o9GrWLNq3cq1q9evYMOK HeuzqtmzaNOqXcu2rdu3DsnKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnkw5 K9zLmDNr3sy5s2eQlUOLHk26tOnTqFOrXs2a6OfXsGPLnk27NsfWuHPr3s0bpe3fwIMLH06cau/j yJMrX868ufPn0KNLn069+tbi2LNr3869u/fv4MOL/x8vdeeA8yzPqx+gcj16k+pPxm85H7579+nx 22cvH/19/vnpt99//a1X0n/xGbifPQjWN2CBDDYYIYD1VShggCg1+F6BAB7o4H0cQogghiF6+J6D 1qU44Urzodjihi9uSGJ7MrJ4Iow1JnhjjRBOSCGPPerYIYc/DolihgqueKSJCzK54pMzprTkgyU+ aeGVUCbZ45ZYqujlkh/i2GGMPr504ZY2jrkjkux1SWORTb7ZH5RsiskmfUkKSSKZdAI54JBxvinm mk0KqCeaPhopJJxetoaRegZBWhCkkhJE6X0NuYdQpQdxKtClA0x63j+VemrpqJ+iSqqqoobaKaun rv+XqqsDmRqrpKAmBOqouMK6kKav0hqsqpqauiuqubZ6q7CzriqsreRFS5F5PB55qIhn5hdhmngC ei2Tbkppp5PiAkrunYQGWu62SvrZ7rZ8xuSfuXSWu+i83uLL7rfnziuoovQ2Cp211eqLrpbd1nvu ugcDbKW7D6s54pQatttmjhDrea9+OsI7aMALgpmxv/oSfPHJFjOccp0OC7zao74ay2vMM8vKULLK 6kpzqJ4e62urNtf6s7ObDt0r0bEqdDTOw/IctNDQNmtr1EQXW3OkV69a9c5QI51z0tKGLZXMzG5d ts9lYw3s18Gq7bXUWevsNLPQ1m00sms3K/esTKv/XfPQbwM9NeBI9zq324b37fV/bbMt9uNLkY04 17sqTSzXeyvbc9ZUGw62242D7iysnV+u+LKjp6236JJn7rnkpcoqc9er0/455LgjNfizpoOdeOaB B8+250n/XrSrQUfNadxf5y287VarzjfUtLJqd/WYH9/48nhj33fs3oue+/gRUUtvvE66ibB9SKq8 p4xdXnn+oAuXyG+gCE/Z7/137s+f/hhznwDJFa8wGaxM7JtT/xDlsuiM6E/mAhH+TLbA+v0rX4aC n8gkdjICQdBEBDJgy7j1oIrFyUXZUhcKQbZBIkksRA9UIcYw2MAa2vCGOMxhXcjHwx768IdADKIQ /4dIRLHp8IhITKJhisjEJjrxiVCMohSnSMUqWvGKWBSPErfIxS7aJYtgDKMYf/OTAJhRJWZMYwBK ksaTtDElajRJHNmoxjXK8YxuPGMd8ciSPfLRjyvZYx7tSMc1+rGNgGzJHAs5yDcy8pH2cKQjvUjJ yXAkjQbB5D8wqUk1JkSTmzTjQDopSoGA0pSiJGUpDwJKVaJyla+MpSw9GcoAIESVtrwlLWs5ylK2 cpW/zCUvx0hM8vikjoPMYyT1OEk4IvKNk4QmHxkpyWmipJp2xGYy75hNZv7RmtwMZyAXKU1CLpOQ 5YTkOSvJzuUgU5zXFKRLntlNc1LTmvSEpzPRif9Hbarznu/8Jzyb2ch+enOfAD2oPtvJUN0wc5vx XOQ8yQnOfCbTn2g0KD83utB1yrOjkCRoODW6zojec5klFWhDV0oYjXASlnUkSEwdMtNhyjSVsOSl Kz/px17m8pSnjGVNfdrTnerSli9Fak6H+dJQ2vSpxYxqd3pi0YIWUqTjNCdBq5pQrA5UoxJN6UgD qtJzhhWhKOVqSONIVrGy9K2nSWRGDfnRiWq1ogodK13tiVaAunWr3pQoVtWKVkECdqOBtadX4crY vGQkmEfVaVAj69NM4lSYQvXlUm+K2aTK8rOVTaowJzvLzVb2lZe17Gg9OVSoSvW12OGJP6dp0bP/ 9lWd6bwoWPtIW4UKtrf1vGpZy8nXr+YWt9gsbmOXOxp8BrekybVrYYErzujOtbrfpG5KozvY7Co3 mrPFK0dNytzyRqaZxM1uIxUJTrOKl6J3be8h9fnb+hb0kHtd723rK1KMgtS8AA6wgAdM4KPA9sAI TrCCF8zgBr+lwBCOsIQnTOEKf9HBGM6whjfM4Q57+MMgDrGIR0ziEnvHwihOsYpXzOIWu/jFMH6M iWdM4yDG+MY4DkyNd8zjHvv4x0DWSI6HTOQiG/nIvAmykpfM5CY7+clQjrKUp0zlKn8HyVjOsmWs zOUue/nLYCajlsdM5p+E+cxoTrOa1/yUMrv5/803YbOc54wQONv5znjOs54NTOc++/nPgA60oAdN 6EIb+tCITrSiF83o2uz50ZCOtKQnTemSfODSlQ5wRi7N6X9w+gME6XSnByLqT5ua1Kf2tKlTrepP h3rVB4H1QkaNalAXZNWuxvWtcT1qWu/60r+29aaB/RFeh8TXtaYIsmvt6lb/+tWsbnRPOG3pT5uE 2tS+NqazrZJsc7vaH0iJtzENbnCHW9vn/na3yY1ucbMbJeN+d7vhLW90n9vePlF3vtlt7aDo2x7/ hsm/uY1teROc3/XOtEk00utmO/vhDRf2s1E98WRbnNYYJ7ZANB5rhz8c2gjJuMQtDvKOi5zjF/9Z NsNRrvKKRLvVKHfIy5ENbJoT2+aNFsi0yb3qcgOc50C/N72Fvm6h67vg9z440V1i6pMcPeE/T3rC n750c0td6Qjvub2xHnSfM73eXB861Oc9dJs0nezuJjrSFd6VeP/c526P+koCjnaqy93rdF/329Hu 9bL3ne93TzvS3R7vdHf97lm3etWLnvZyK73aLRn42CMf7nfTXd1rZ/tWCL9thENe8f0+e+MBn3nM 95vylU+82Hse99E7HeoFf3vm5f74x49e6y+xe+0n7/fey2T2l+d15xev+ZSs3NYN/7isPx5yj2+c 48su9cuZPfJni9wgLdd186uf/Zrn2vvCln7/sq///FQvf9YxF3/5mY/+6rO/IepX/vdHHv/pJ3rn hs8/168eE9MbHezDF3hzN3a4RnqwF4ADuHQBF3fAh4C0p3qtd3q5B4CpV4B553uAN4Gi538C+IBq x3vFdxMRKIEkCIJ/9226d3gJuIJwR4EsuIAuyHiI54ANWIHtZntRR3yup21/14MsIXk6KIMz+IE2 +HpFmIEhqBMjiIJMuHiWZ3BQ+H/5Z248iIS2Z3cyKIFI+INTR4NeeIQ1iG/9F4U+eIFGKIRjyH99 N3stKIVJCBStl4NG6IZZGINnGHhY14ZcSG89CINXp4B2iIF6uISOV3o4KIZ3KIdkd3iTB4SC/6d3 r5eIbIiHqveGwxZ/MLdrwSZr50dy0OZroBhxLcd+0ndqwgdqochy6Rdz64d9Gsdq5Adzouhw0ceK xuaKHmd/5UeL56dyNidx2veLnziKh/aGQ4GFgWGGxugVOecRteh+cEGMzTiNsvGMnSGN1JiN2riN 3NiNVrSM4Bhh3jiODhaO5jhg5JiOCnaO7NiO7viOkaGO8jiP9FiPTQGP+JiP+riPeGGP/phF/BiQ SvSPBFmQBnmQBiGQCqlDCNmQRbSQEGlDDjmRFFmR0xiRGCkwFrmRuZORHvmRIKmQHDmSJFmSaxaS KJmSKrmSLNmSimGSMAkeLjmTuBGTNnmTOP8ZZDS5kzzZk0VGTARAABgRlAZBlDn5Yz0BAEqplIER lFnhlCgBlSUhlSpBlVNJAFdZFEFplT65XExZEl/pF1w5FFxJlWNpEmWJlU+pll1ZXmGJEksZlnEJ APawlGA5lyaBl3Wpl18pl3SZElvJlvYQmGgZmGppmFe5lYmpmFEpmFCJmFk5mJDplIbJlpW5mDDx mJApmYzZltGBEUp5EKEpEKO5lP9gmqFpmqcJAAaRmqXJmq85EKNZEIE5EEZJlEb5D7lpm0K5lbz5 m7QplL+Zm7fZm8Kpm8KJm8WJnMOZnMeZEMXpnMx5lEy0E2+Zl3+5l3e5ndrplynBlN65l9f/WZWH WZ6NWZiAiZVmaZmCuZiEKZWaKZnoKZ/wqZ7sKZ8yEZ9ZeZaemUTjqZ3c2Zd/CZ7ZKaBxCaAAeqAu oZ+caZ6ReZnrOZ8nEaH1uZ/3SZ/3WaENmpkOiqH9WR2gyZqtKaKrSZoiGpuz6ZqyCZsk+pqzCZ2G WZTG2Zw0CpzTSRC7qZzAqaMCsZzEOaM9+pw3CqNBWqPUCVspyqIraqJMWqJJWqKrqaRNCqVLiqPP yaNYmqVAWqTIKaRDyqPTqaVF+qNhmqVcKqNnCqY2eqTjk5QKKp7hKaBw6pcHGp4Iyp0Sip+E6Z7l +Z7teZnnOZ+bqZl7SpkXCqh7ip+NaaiC/1qo7fmhAPafNCGpPMGfTfmoeQqpSJQWLzoRndoRu/ka obqmbMplnxoRp3oRMSqqtVmqDaapsJoYrjqrnxGrtloYtJqrurqrVHSrvqpjvBqsbPGrxNoXwnqs aVGsyrqszMocyPqs0Bqt0jqt1Fqt1nqt2Jqt2rqtMdms3koWaJGqokmi3EqQPDGX2VkTlPqd6coS +ZAPKfGu8loS73oS9Uqv8gqv31ppIUoQ4roQ/1oQASsQ71oQBUuw+fAPB4uwDNuw5ZpzpxqbUeqa JzqXK6qaVHqq+ToQC0sQHVuwHfuw1BixFWuiLKqkqqmiTfqkBrGxDuuxCcuxCRuyIjuN6P96sS1a sk6asxmrswlxsEAbswabr/KqsEJbsycJFAZaoAPatAhKoNiJpytxr1Srr/lqD/eKr1hrtfO6rwu5 tFGboHTpnXHarvFKtFprEvWatVvbtmqrr16Lj29pp2K7nWTLtHh6nWxbtW/rtmmbtWwbt3uWETdb pStbsoU7sTw7pS+7sEQ7s0fruESLtGdmFOsquJhrnWabuc0qEgNLuTfJuaIrFKBbuqZ7ugrhJQIg AKP7hnqJFf+JrixxuTOxuiixuri7ErhruyWxu6xrD77Lu63LYnRbFLGLt0YRvMD7u8ubEsJru8/L usI7vI3VryO6pBZrsYprsikblwLLs9r/66LiS66dursEsboDgb4Fob7/wL7pKwDtC7+oi2CaqxJ3 y7TI251yeqdhq7/pCrUnYafXubsnEb3Oy7zT27vS67vUS7ybe7cB/L94W7b2y5ftCsD9e7m5axIG fLsIzLwKrBIJ3MDsZL3fi73km8LZu7gke73+KqU4i7EJYb7x+74Gwb447L7nK7/zS0z1y65RO7cS DMQB+sBme50YLLUwAb0LzMEgHMJQPMIF/MQkTGEQLJ53KsRBjLzHS8RbDJf5+59M3LxR/LsGPMId XMUo9rqyq8URbJdPi79g7MVFDMevy7/Kq8AbTMbLu8HBa8YErMaxKsWC/GJRpMM9jJSF/7zIjNzI fJbIkBzJkjzJlFzJ3erImGzJ5YrJmazJ28rJoBzKojzKouvJpnzK1EnKgozKrNzKJanKsBzLsjy7 m2sYtTzLRnbHtIwT6Eq7N+HLdQnGxwvMuLypF8GyCvG5AEuuH/G52euvAgvNrgxbSlvLsjunRbzL b7y0TaugFmzHRxzMeRnALXHLxbxFHdHCjMukEjuuCUGxhquyUPqinwqb0kyayTzNNea924vMVcrP CCGu8tyzBE2lyUy+9/zCzKzPM6bO8xy+MuzCMQzDBN3L6/zOpZnQrcnQO+bQ8iy+B/3CKCzS7LzQ Bp3Pp5nSsonSHO3DOlG8dSy2+bsSbv9slzWNwfurxOMczP8Llj690+dcYbq8zdw80xUszDZ9wd8s xE6L1PhboNhJzEGNQ2yhzBZh1QDb0iB2F1LNy+Y8E1891ZPW1WD9pmJ91mid1mrdHFrd1m7tjWu9 r28trHH9rXN913id13rNYXXtrXtNq30d2II92IRdYX992Iid2IotRYXd2I7Nr4t9lI99q5Et2ZMd q5Wdk5e92Zzd2Z792aC9ZZltk6HdlqMduqWd2qqNYqftyZVQCeFxotHczE1h0qiK1VVh26IJmvis jjvx2pVwEsCdE6/dE8A93DxR3Cih3Lz80xf8EmFtv9IN3TYxoL/c3Ej900Bt1mA93XD/id3WzRXh LRfRrSIYAdwEgd4V8doawd4C4d7rrd7vLd/H3NsrTdsUodssnd8VwcwI7d/2rdKo+hD67RCyDRUF Xtshdtzz7d7HDdv/8OAQHuEP3uAODuHwjRAZfuHyXeEaPuEDkeEBfd8qfeAAnrLznNIYq70rveLc 69/eC9Ivjs8nG8PfS7GyHbECbtInTuAkbs8uPrEqXs8/3tsHDs3tDND8XOMbDdAzLuTce7Eb3eJR SuIexuAUzt7wreUXTuEhDuLz7eVinhAbDttbbuZg/uEGIeK7bd8mHuAZa9AwbM9WHucqrtElbtt0 buRxjtCz/d+6vec8Hs0JXuQ03qI0/37CcI7ofF7iLpzRfo7kjC7NC/3fSH7piy7p913oC8blXD7m nx7mZ77mGE7fav7loI7mDcHmbL7bQL7pmU7lmJ7ode7ney7gsD7ito7rt17pAX7rs+3oI/rMPv7q vE7rVu7rxi7svu7mx07oeH7kyX7slj7ist7oH+bpqj7q3D7hHK7eWK4QZZ7lDN7qpH7uDPHqjC7t 1A7t147rz97rUw7jqEnp7V7nwo7sU57v9T7rEQ3tdL7rAI7v6p7rzb7jilux/Q7n+T7tgL7kRP7u 7I5Fvx3c9qDcxc3cGW/xFx/cGu/xHI/xyN0SzN3xJr/cHE/yKV8SJT+7PC3O4jze2v/98uTc0z1N zjs9tjiP8zfv0zev8+Pc8zlf87Rsx9/93M/t8jov89ad9DPv8zQf808P81AdzkG/80P/3Ve/9TSt 9VAP1AEm8iwP8iax8WVP9h2P9iNf8i0/9mfv9m7f9irR9my/8tvN809v80dP9Er881Rv9T0PnmEL 9F/Pv1LP9V7v3Hyf9Yrv3VA99E4P8zvv95Kv3VW/+IIP9o0/+YQf9VHv9Jm/+eVF9xb/4HB/8hI+ 9sf99qyP8qt/9mv/+q6P3Kl/8t8J9uGt1Ea/+DEf+ncJx73f+VEtzMEv9T/v+5a/+7fP+Tbt9XzZ 9ZaP93Aq+Q+M+6If/c4N/M0v9Mn/T/zd/NTDz65L/6bljWV1XxdyTxbln/hasf5d4f66Af8xIf9a dv50kf7qf93vnxf0jxv9DxD2BA4kaA9AQYQJFS5k2NDhQ4gRJU6kWNFiw0qVLm7k2LEjAJAHJYYU 6fEhSZMpVa5k2XIgSpclXc6kWdPmTZw5de7k2dPnT6BBhQ6t+M/oUaRJlS5l2tTpU6hRpU6lWtXq VaxZtW7l2tXrV7BhxY4lW9bsWbRp1a5l29btW7hx5c6lW7csALZ4xep9y9duWr9+jwq+SvjvWcOH FS9mfPTjRJEyZ0reWJKyzcgJL7PcTLBzZYEHL39GSDKkQc1EIY9cSFqna9Wxg3JN/9y09tjbVfnm xm2Ud2OtgZf+ViocuFnix5UvL/u4IEyDMCOfDg1SM3XR1qtT9ywde/Tp1sNbjl795Xfu109zD68+ M/v0L7enzm55fXnw9tGDl5//pGf+QpuvNOzYw0+7+s5DMEDynhvwOe+0Qy3B7SRUkDwE9RvvvQDz g002EGP7TDQAJwSwQYWyk08myVhEbcUGMSwxQwFdlHBE8wQ0Ucf+apSxxxWB9DHI7oAksT8VdTyS x9aKVPJFKJmMcrock4xyyBqF3PFKG2fEb8srHTwwMzGR/HLJMENUM0QcXQQTTYbQlLPMN6fkcU4o f8xSSy/N7KxLIqUEszQ7Wyxxz/8n3cQzzkNfhLNRO/MMNEw8Hx200UoLhVRMFClzs85P1xQVRE9R UtTD9gi8b1JDYTS1zwlNu9PVVQWF1dEHjSxUVk4tZJXL7l7100vTXAuVzPiANXNWRYVNNLUOdT0V UEF57bRCFEHddFRug2oVUVxxxFRTIanVVdLRenw0VEIj/ZbJOUl7F1w42XX33g/PfRLSd8lE90SA h2233ICf/XVcSemVMt5tu3WYItqS2g2viX37R7jdJB6MYqQ49k2wijHu2GKLjcu45JFNHo5kkj2+ WOPBXo7ZuJRj1ljkkW1G+eOdW5bZZ6ZoltllkGEG+meXXw45559v1pllkJrWK2n/oovmGemZN266 Z6W1Zu5rukz72OOQhh57YsPKpnrsrS+OeuqypdYa7qihtpkkls0erm6g45Y4bpP9zlnwrO9W+2++ D1ca75b9rk3oqdkuDnDHdaaYcbc5pjkxuvcmu/LAk2Y7crszXxxwuU1PDmzWlXq4pXxfe312UkET KvaacKd9d96dE7F34H/Snc+eho8peOQLar0rzJd3/nm0Vje6L8Kp5xt67JdKfnvuu/f+e/C7z358 8ss3/3z004cqfPbbd/99+ONnU03jG25Sftb+w99b/QduqP79bY95eXsaXKS3MqocEDlZUeDgCFic Bz7Fah1rXvYaOD3bBE0qF1Rf/wfDQrrFcDCCThHhBxnoFRBqsG0SxOAELThAqHBugx6kYVY+Yqob xUpDqWoNem4EHXjp8ELjwZKrguihCrkniUJEYoZ+KJ71+Cph4cJhqaKoIf8pCyLW+o6SfMjEWOXI P0wE4hgphEQIdVE6HYIOAAP4xnblMIwKyxajcsguG+kJVKPRI8MINi45Uok+cfxjwpBVR0f1kU5a dIi5lhQv+yBJkJBcVpPuyC9inQiR/oJjJy/CSQ79Snd+XFjBtDUpQJpyUaU8GCcd5ClbBemR+6pW EPG4SDSmSJV7ciSsFHkqO+4SYaSkVCw92T4YqgxnjcuN2Ja5tWeurVgrlFs0M/9HOBeuTW8bUxzT qtc1oh2tbSm8XAVdiEB0du1uQ3Mm07aZsWmqbHLdVCcBlVkzw6GuhvukikdASUdM6lKUAQUoKtNE roIKVFp9OlYxcUmiWeJKS/8UF/Es2ssdwfJc19IoLRd6sI0itE4HPSb7kunAZb5tnUZTaeHcxlJp zg2fEHRpS18qNGjOVG+bE9070SlPnG6znuO0nD0fuLSi5k2bR4OnTlMItZhezXKRs2bFqMlPrOLm elQdXEsrN8+hdo4whwsdO+smw3ya1axpo9xZvXk91Z1tbnBNKlSDarp8cm6r3Eyc59bqTsZBrnR/ Td1LKai5rvZUcXRjLNqEmlX/yCaFKJtx4+sqW1LYlfSymOXsTtIlv8121iSh7R1pRXtalZQRf6pF 7WuSBdrXtla2s6VtbW172+BFVre75W1vfasc3AZXuMMlrlAOU0IJ0nWGWEFuDH+7wOcWxoTRZc7v SGo7XN6vIqYtlqVMi5PvbteinrXIh/4kXn8aM7vF3V54+ZSv+rnXXuxVV/AqO7zNupK+N2GeW7OG uq8ytmSdm6eA+XrNA5dzwGg7GebaOULA4lWtBZbrgK+m4Apj+GSJ9VxMVXpWAIP4wwXUsGEDK+ET uxXD1wSZ2r6pORG/zcAsTl1gq+fMxIHOsNQFW1NnBs8Gc+1ydVVqBMkJTSC7/9RsVS1gOvtaz3MG 7sI7HiuVseY0o0Y4x08bMlOv7LXFcdnKN8OYj49aZDKv9MlCrub0qmxlZTaXx3lxc5vVbGcIyxNm z8RzWNl8T+eKeagtdKDdgqrNng7anX0WrJ65WudGL3rQUT1zYZVMukhfOqdNPjKg59w6ff650OWk p4QFnbaz2bTI1vSzp0kY4Qkv2tGaprGr00poWqca0et8s5AfzExVt1rSR8Zy37TsVCRXUKikVvGn oUdpPy+ZptNGM6qJemxaQ/vRLDw1rrttaGTbOsskRjanCy1tSA873MWO9rmJClRsi1rSe9apkp2N Ft89kpjIEmkdgckpU/YbX/8Fk6MxG7qlef37l+eJ1EEjWkjxIExhU/zsxBMa8V1GEuATvVfDEa5v RmoUo5ba70T661hmp1rNoZYc4jb8NwTLldUOrnBc0ezkUSvXxmsGsuNGTGQOUziuOD3xVL98WP8e mMajy2lZ2RpzdjsW6dxUq4GV3XLCKvrezcFMFjGLyDUB0L00qXhExj72ku8PMNSm7lOVc0E5rwWt CbzL1u3+bLb3luY9PiGoVUh3sFz97oPXStoNf3jEH57wi2d84x3/eMhHXvKTpzxzl3PAuBswq3HP fGQ7X/nCc8bsjVSVK7HodWjlb3f6zUl80Tt6QvZPdqJCe+If0pvlvjre4uz/te4B7zy3y73vuiE+ TT//leMjH/TnayupE9xkKKdT61NXdoljXLoUE9jlz79+y2+MN5/rvPmrxiuOj45BqBd9nOPn64pp 3uUf13znVO3+gpW+Ye1P/XTtB6v8v7l8rMg3j6qXWHo4TDKWI2K4IgIUiroWS4KQj0K4OFIkgtqj ZSm480olIpEXWxGkkbISJxGpXakkBTylf1EvK1mlE7Q42yue2AOXS5mVNOmu6xpAOlkliIrAGkSl hpqXjWPBkBM4iTKoCmQYBJxBW8qk1BPBkfOfTMnBHUwoRhLCFvQJA2HCDBzCWkGUZPknDbQlFpGV FpGiJrrBGXkiaMmjMuoX/yE0vetiwzzqoS76QR3ajyUsFi4Rw1sBwzWCwmgZIipUEGypj9iqQocI PN5ruqBRP66ZNOOTtXJDmZcboWzatJsbt5VqRG8Ttjurt030MJxboU5bmbm7NnPLRDFDNcT6REbL oN4DQLsIsj57rE3jM2Jzt0rMtFEEOqQStJ4JJ3rLNUysmhqrNGMkv8LptaTDxWIsRVsst95bKvwj N55JqQnSNlisC8GRsRyzqSjjv2u8Om4cK0aMuQZjOVOjOgFrsW6kOr/Kqw7zv1W0K2ojR/YzR07z RntMLDNrofCzureCteZ5uRf7OWZaPwZTumwMPUNswdprSIiMSIkcioecSP+LvEiMnIyM3EiO7EiP /EiQDEmRHEmSLEmTPEmUnKz0UknV8EHf0UigqMg4IUPySknUMq80bEntar31wi6YXELVY5QoXMme 3KIxzB+ZtEmWgK5AC0ZtPC70ixjE0Lyrmq6oTKAWA7zkW8jNKyr3u8da60YQskf6qzmkmzEYY7Db yD61JLOEvLLqQ7F/tL8CQ8v9Uzmn+T4Xe8uUEUt3HMi9HEty8zG2VLn/48oaEsAFfMEzHCgUPJMi xBcKJL1LKpdNWsE8dMzF/EIqAikY4TjIxKPLjJGcDBR/+5c43JeCU8r3yUEv3EMbnJb/8Tg4VEIg fEDP9DiDuSXNHCkdDKX/21TBIfTNBDSoz5LNdeGlNixO1mwf1zwiaylNH+lD95ATXvlNKRwRZyFO d6FOVDFDPAzPyJTN3OTO4SREX2mWAgG7DeGQ5Myo5dTN5gyRAVrFmUMgPtNEVvu7aMNG/vTPVEQp CJtFU7TE/mzFqHtEe0s3arQ2VVS0abxPS0PMxpvGmgq+XRysgBSsDRXQCzVGVSPGeOM5SNS0/YSq ZpwpuloqVGRRPPNGI7u5SRws/7xFCq1QIhMrMHNHYJu3ods+sLJLpzMyg6y6OrM5qdFLv8ywYfMq HUurKrurbTRLvLS5bQzHvYpR42M5qRvQG0Wf7knK8lKv4RLToZzPiDSf/61EoaqEvDXNuy+N07Pg HjM1u0IkLtbKHTTdUz7tUz/9U0ANVEEdVEItVECVU0RNVEVdVEZtVEeVU0ONVEmdVEqtVEtVnkfN VE3dVE7tVE/9VOe5VFEdVVItVVPlSFBNVVVdVVZtVVd9VViNVVmdVVqtVVu9VVzNVV3dVV7tVV/9 VWAN1sQ8VWItVvoUVmRNVmVdVmaFVWN9VmiNVmmdVvhpVmu9VmzNVm1dPmrtVm9diW0NV3Gdi28t V3O1iHFNV3VdV3ZtV3d9V3jNqnOdV3ptiHi9V3x9inrdV37tV3/9V4fJiI4Q2IIg2NnBHYQ92NPi I7FznzoVIK/ICLWQ2P+koFijsNilwNiLrYSNDYuM0NiIERtKJKFy/D1u0z8sndG6i4vgO8U29b0O etMOSgmDrYmaFYiavdmC1YidpQmd5YjXVKgsIjnZE0odPM/xSi2KNNqk3SKH/ciP5Vmc/diBiFqC tdqppVp7sFqprdquvdqo9dqs1VqB5VqvDdut1VqEAFu0TVu1FUrkXBBWeqUnOr01GqQOfKWdvJCB ISIyAiKI8ts08tszIsQxysOISxLFhSX4QMPSm07IXaIuaVzBvc7hitiPPQqKlViLBVnO7VyO7diK Dd2OBd3SJd3N5djM/YfP1VzVDV2QZV3YTV3Z/b04S0Y47SsJHVmVLZr/tYRZrCmzTrSwS6xK+MM0 /Jw2+DOxp1qzmno13e1HaepHBHVU2q1dpDDd0cVe0eVe1+Va7qVd7W3d03Vd783Y2TXf2M2gKgXF DsvQAz1ZDI0n4EU/soFGZCze34U3BfUmS5zEQ3tZeRtgTgxQ6EvU65XdBE7dqPVe7c1e0q3d8X1d 85Vg1KVg0W1g9O1e8s29B42/qJhe8BNZ3pBFJP3FLD1LCGqsXWM0kc1HekJevFTG/6VGYMs/cFw3 E603+j1gwvMIs+1Zgy1bqSVighjirp3aI9YIJFbiJk5bKHbiIk7inwVbsf1Z7UqXyf0Pc8nb/7lb HgxCidtAJ4xN+wlC/2Dywo4iQBnEzvHMODgOYzMsLq7AWPK9YzzG4Az23AjuYPGd3fQ1XQbG3thd YD2uYOUlRXx6RWzUswJdtlqENaNL5GxDUQ614RA1tiljqRoeRqQBRqNjsg99xg+NvIH9Wp5t2yA2 25sN4iV+Zbd94lVm4ikeW7ZN4rGN4ijGWl1mTM20Irn1orp1ko66k+3MkzZSDyTk24aDIj9cosGd D/RUlwTRLz2iuDlelde6j5Fr3A9cT/0409OKi/VdnnKOHruTWTrLV8X4CSymnXe+iYfllnkmO4Dd H17unXwWnoUFn3q+Z4FgZ4EWaIAu6GgdaIROaOtBsd/6DZlVZ6jciv9S/IsSqmh2bdmmlMXH2SDB IwvBzD1dS7S9qMup2MrD1Mr5a77eZYyNDmGpbNcGmtESdmkfZUqTlWSbNtD6tcrg8GRMhtOwYd+m HL5cTa8qUiJUwbhDciLDza7JHeY5epUFEZYIAbtdsdsDGRNmnkIZBOfDXVxBhFs2utPhLGOhjdyv JsOq/sysvsK1biPV6sO6/WeS5LfHxOaylijeBM9f8jeFe8MCDEFKUsBgJsFllkCk1WrEFqjKJL27 fmwxYtxCgs5JgswPTMLxSkH5fFa7dmwHtGYbHFyKiuO5pSWizeviJCa8hs3rPBKR8yUilM4YvMM1 FO1FsheiZUNsJk//1RQmXcIoQT0prOO/L5NhEtY1FqqqX9NpwSTLlm205S7uGea2qjlH9bNu6vZE /jzS/zxSEl5R7/ZKlDpuFnPRWovEdHW7SpRudNPkGRJlnI7kRnRknFYsTmazNt224fVfTOzf6QPq CeXu/GXu8AY3XkteAW/Fu9pWGf7fj96pT05ESOzFAibw4IWpkTXg+RbvTf5p7Ks2DqdFSH5FDbW0 9dZwGC1RL8PvFrZGDHfxdQ0Z8bvfDzfSaizI8DudJWVH0UGqnRNxE2dS/rZx5wasrXI+GvW+IOXH DF86EhvIemS6dMywrwrevQPM9Au2H4VSheY70FPn5OO8EOpyq7jJ/7STydrLr/kxaIhwNoj2oDef SolujDjXVja/czzPcz0fSTLv83FdiSzMrLO2Z81Sa4pQ86XFSfCayNPmHp52SkSEdDmv6Zy+Sjb1 7+VaHRLXvAUX4EtXYeQ4aa0SdUpPbn4C9L1FdTrU06VNdaX15aL9JJWcLzJ99clW9VpPCZcEStag a5w4ufrbNoAMdnMaYb6sq2EHxrQkblJUMasLzPa9S6hD2SvdS4XMuRi+YaEzs8Zi0he78BzuUWmf P2aP0bmkcvAuNmUnd2mHPuxGsPeDmwVVn5fMFAlMzUD0otzkKE2qJM2m9dDMls7Wa7bmzn9rzODM TiAkz4UreAQU+P8pcng0rsASlOwxdijX7k3N3hY9GfhJYj33een4fbQTNW/4jVJ1gu8Kb2n8dm+f OvkCh3STJ2D9Xu9wgvlOr3Gf+eANF8bpNrcTr7SbH3CTfz+hPzeVHbwyKzqSX+4ePvofi0v7dCrf RW8GBfFi3JmlxyZ3a9HyfsT7JLohT/m+BL9SN+H2dvpky3bo5ccef2EQXeSyZ3v2re68Srqkp6F6 X+ZQKma/Z8xGf06B6yWAB26C93ekrSjUHm2xbsK9DhcyNs4zRiOGJ+1aStp94+pNAc6Ml3zMh8HD LxOrpq1ISuP68kyQo0PhXO3LvrhAx8HQ/hTD7zjVl0/OT/3UDyn/2We42b9tZD798uhiaklPvTVN Nr58ZjmU0vftuf1s6AR++Tm5rHtwfNS/E+bRrLtvIf/wIV1EdMRyLP/kcwdSaprSaV+5z6HxUqv+ o1ssLgVeHVWqIn32dixyJ3f/+iN/C5VyRrR/+QcIAP8G/gMg0KBBggIHLixI8CHEiBInUqxo8SLG gfY2cuzo8SPIkCJHkixp8iTKlCIBrFTpkuVGmC5n0vwos6bJmx114uzpUyXPnymD2iNa06jQpEqX 2svo9CnUqFKnUoXYMOLVqhOvZtXqFWPXr1YphhVr9qxCtFDLOjTLVi3cuHLn0q1bFeHbt1652j2r 92tWvH0HO/07/zcwQrSGCTM2y/Qx5MiSJ1OubPky5syaN3PuHLIx6NCiR5Mubfo06tSqV7Nu7fo1 7NiyZ9OWrRRpT9yeT+r2jBBk792Tg5MM/pv3y5ZMiSO3OZK58OhC3T5EnFjhdYaCGW4Fyzdt9e3g LeJdGHbx1MXnudNFD9o9WbBR4beVSF/+/PhY2Y+t7b99f/yx911g41Xn3YEGFmhgdwfep5V69gkY 14N9VZggefmtpZ9iUrG1Hof/idhhWg2B6GCI2iUkXonjHcQgihWtl92LNBZknonXHZTQjTxixyOL 5fX443lAgqdjYuLtqN1+/OHoY3bhGUkjlVCyqOKT1hHpUJU5Jv+ZYJb26Tgkll0pCWSSY9rYlppW ujkinDKOZaKEc8rZ33ctOlnfh/U1aBWdXAaKJnd8QTmhn+bVeWiee9I5qIA4MuknnzC+iKiDj2Ko 54QENskloJyCKqqije7H6KaJVkppoZCOKiipq8Y5q4IubmdmmQEemaqibNq6JquAjrmrp47GOOCn vjZpKK+nItorsnvaeamd8jFrqaqbQsvggoUe+6qvplbrLbffYkqtsuiqei2t7daKKbjnpqpsp3oG uiyMcnpabKXlobttpPKuK6SwnK7pr7Ss1sjnrT5KuWKmDX9Z7q5YGaltjxOTiyzCwkIc68No3itk sU8G3HGU7ob/9tNN5YXEEk9BtexcUTt5JBPMMeH1ss7HITdzzUDjzFHON9tcs9FExwTc0kobt3TM TcusdNM25wwT0FRrHbTVNEN99NZYP4d02GSXLbTZXnPtNNhVM430zGinXfTXykl392ZDd3203GUn nbXbBs09uE5iJ8021XTDrbXijbsd+ONS7/243mTrbbjkVU+tOdF0F9652Y7j7PnniXuteOipj265 2ICzrjrobXueeVGOLz503JNDhzfvLFPes+CdBw+866DvfHjtg9d+XOkyH4+2y5xLzTzYwwO/9U7W Y+1z9oBzL/jxlmMvfc9wWy/82tMP/9v2qC9feffC2x4+++Ub/x5+/PODb5PP38O8f/QWtzzIvQ99 vTtgScRyocKobF4NhNcDIyjBCVIQggqc4AJjk8EKcrCDHqTKbSKzOwS+jYQ+GaEJU6jCFbJQhR98 IQxjKMMZPrCFNrwhDnOowx3ysIc+/CEQgyjEIRKxiEa0W05CeMQlMrGJTnxi94Lnr/adbymbUxvP mgPFLXKxi140YekIOL6kMEc3xEHhF9OoxjWyESVIKR7/1lfFAhqtf8QL2hx3Rr/6cU9+14Pa9gA5 OikOUHxtPCQiEymdN7atJLNDYvIkFzf4mQ5xsVOe36TYOkri0ZJoVCQoQylKN+JvbqV0ztNkV7dV 4pGQsFNlI//7hrtGpu92o7wlLkWpFnHNi2ApyxXGwPWvRZFMV90KmKyGmTFlqouGznwmNNvFS4rV K5jvGiYvAUYpUx0TWpqK1b6iKc5xkjMuJ0Se68K4v9/pDJ2rXGfkBMjK1MWSb4x7ZfKy9slc8rOf iAwg5U45wPYBB54EJKjt+EfHAhbveXbkXAD5WD1/UrSiUITmBglzoYyWs6Me/egHOWohqogUpCY9 KQW9KNAUonGfFn0pTGMq05nStKY7RClOc6rTnfK0pz79KVA7atOhErWoRj0qUpOq1KUytalOfSpU oyrVqTIxqFa9KlazihGqcrWrXtWMVsMq1rH69KtmPSta06r/1rWyta1ufStcmULWudK1ruOMK17z qte98rWvobQrYAMr2Ar6tbCGhelgE6vYxf7nsI59LGQjK9nJUraylp0pYzOr2c2e5rKe/ewQOSva 0ZJ2LqA9LWpTq9rVHrW0rn0tbGMr29nStra2vS1uc6vb3fK2t779LXCDK9zhEre4xk0sa5OrXK/2 kYQutcxzbRjd5d7SX3gzynRPR8bLEAVz9txib7wLFOrqcC8iKqkDzXsaEKEXNu6pUHuPG8EiTQlX hMJSq/DrLCStqE35vdGWMsamNtn3UALWL5kOjKFe2ShIgumSmET2KEkJykulutg2XaTfHXmpRGly WIBvJV8J/57TnXOMJCEn6TerXQ5y2gtk2uQpOkquj5VRmyX2WtziGJvPkpg8KIz/Nz4hv/NwOAak JzMHx0rGk7wH3EsxRRWgb24sW99isLlGhq8qK/OaVpayuKjVTG3SS5i6ypaWw4zmYC1sW9jc8jSj NeKU5kZt7runjUMH0DzLs5aGNB/18pxOe1r3fQQ19I0TV2Mee/d/pQyjjH1MxfkxmmuT1t+OCx1F 8Tp5herFWJ+MBbL4lCzLGubXm6kZrmQVSC9ixpPA2FUnL4uay2ue0ahwRTEsh4jMc1ZZiVWJ3Xvm bsWSpp2fK0c6iE7ux63T3ezgWGwBbm7aP6ansvFpUE7iGf+f6bufGDXX6E67EEIR9nUyN+wxCaF6 WBoe0McAHKYvL/NIVRqwhf+Eb1tZjEC/PLCSTn2mhb171lzh75ucxGH6MsyCv374YOKLwbtAvOI+ lbgE4Wvxje8U4/MlKcc1S+6Rk3w6IT85yllT8pWzXCVe4YdaYE4QmcOJ5jPPiM0HkvOU83xEPuEH SIC+EaGnhOj2MHoOkX70kyhd6EpvOdQt83KJ0HznFrG51f2z86xHZOs9/7ozYc6Pset87GY3+z/Q fvOHYD3ta3d71W8ed513Xe1pJ3vZ1X52uuP97F63+97pfne9wx3vg++74dmud8Dfvexgf/xgDC/z uUv+7YL/5/vbxZ55t1+e63CXO9u73vjLc17xoF+75lE/+s+fvvSkd/3kY/96yNMeLW0v/eRDT3Xd fz71vcf97yvie9L/nfeFJ3vbbz/83Cc/9FzPufI3X/vp2173lDe+8eOuee2z/vdW93veiZ935Gdf 9K3n/PIxf/7Ye738wJ899Wn/8444nSP1t3/Q6a9/oPMf//0n+v8tnUcYHdL1n//tn/7h3wAioAIa 4NA9IAEK4AMmoAJWoAACoAVGnQaWRARK4P1NoAdSIAgWYAZiYAPanwOmoApKoAc2HQNO4AouXQQC YArC4AKe4Ajy2AbuoAXS4ND5XQeyIAmCYA5SYBCa3QWO/x0KGiASOuAPOiEROh0SwqAS1l8HNuET VuDZPaEJhmB28WDLPZ0IiqFwkOEBmSEYpiFTACEbtqEbviEcxqEcziEd1qEd3iEe0qEaJlfk1Zzd vUbgxZ8gDiIhFiJj7CEiJqIiLiJfGaIjOiIjRiJoPSIlDqIkXqJlVaImbiIndqInfiIohqIojuJO YaIpniIqpqIqriIr4g0pvqJ8taIsziIt1qIt3iIqwqIu7iIv9qIv/iIwBqMwDiMxFqMxHiMyJqMy LiMzNqMzPiM0RqM02gYuViNVTSM2ZqM2EqM1dqM3fiM4PsY2jiM5lqM5niM6xkY4ruNbBYA7vmMA fAQ8ev/EO4JEPZLEPHZEPtoDPN4jR/jjRtxjPwJkSAykO+qjQdrjQNLjQf5jPRqkQCYkPgIkQUpk QDbkRcajQ2okP2IkO66RWEBkAEAEPJKkO0rEO2JESj7ESv6DSLLkScLkSLokRFrESw7ETRJETtLk TPLkTIrkT9ZkRfSjTsYkTgolT8qkUh5lT6bjSZVkUZqkUTIlSk7lUBplS0KlTxZlUyalV24lRWQl Vo4lWfakVq7kWVrlUoLlRBAlVTKlWYplXMZkS36lU07QTxCkPPYjQnJkX57EPO5jRWLkYGokRXrk XnKkPx6mYiLmYh7kPnakXzKkX+plXxImZk7mYxpmPjL/5ke2kVfUZVu65VtKpVOkpFxWZVB2JVpO pWiaZmnWZWt25VsaJGyq5lqq5myW5lLOJl26plreZTm9ZkQMZG5y5WmSpl0i53LuJlxe5WquJVQS p2+qJVDGJnEi529GZ3Fu51HSJG9mp3CKk3jWJlniZnLKZnA6J3PupG6KZk5S53au5026Z3eOJGp6 531qJ372J2sG53i2i09Y5l9K5kYq5GSWRGEiaEZSZkZGpkiI5EZCqGVGJIQaaEEupII2JGRyKGI2 6IN2KIV+6GdaFIFOqGCS6IlmqGaqqIe2KGfG44Um5oQ2aGRW6IuOaIIe6Iw6qGRaKIOGqIzyZYGW aEyt/yhQgqiPosSC0iiGHiiGrqiSRumLFmmBPqRnsuiUammIbqmSLqSGQqmRHimJTimQOimTfmiT PimIbuZEVmaVmqljZqac7uiXlqmYEimb7mmKSumYdtFXaCV42iV7HudFvGZaliVXcidv7udzEqqi PupXpuZoNmV5qmeksqWkCmqA6tRLCmpJfipSVup7cmp8AieA+iRpYupcGidzguV1QmqqsqpMumqt LqqjdmoDJYVE6iWWJqSEjgSBWuRlZmmNIqie8ulm6uhl/qiGFqadMiaMzmifJqif/qkR6aq20hm2 dqu3fiu4hqu4jiu5utW2nmsNlau6Aiq6tiutrCu8XoGUu84rvdarvd5r7cWrvu4rv/YVvv6ra/Sr wA4swZ4VwB4swiasRxUsw+aQwj6saDSsxE4sxVasxXoWxGbsIV4sx3asx34syF6jxo5sXYSsyV4G yaasyq4sy7asy74szMbsWJ0szU6GzN4szuaszu6sY9Ssz/4s0Aat0GYrzxZtQAAAOw== ------=_NextPart_000_000E_01C1A19E.2F007B70-- From ipfix-bounces@ietf.org Sun Dec 10 23:21:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtcdK-0004Q1-K7; Sun, 10 Dec 2006 23:19:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtcdH-0004Pv-I3 for ipfix@ietf.org; Sun, 10 Dec 2006 23:19:15 -0500 Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GtcdG-0005EU-93 for ipfix@ietf.org; Sun, 10 Dec 2006 23:19:15 -0500 Received: (qmail 28504 invoked from network); 11 Dec 2006 04:19:07 -0000 Received: from unknown (HELO ?192.168.0.66?) (unknown) by unknown with SMTP; 11 Dec 2006 04:19:07 -0000 X-pair-Authenticated: 207.237.36.98 In-Reply-To: <457BFA0D.7070300@cisco.com> References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com><4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com><45780A37.8010905@cisco.com> <45782D40.20002@cisco.com><457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> <1561355564-1165687692-cardhu_blackberry.rim.net-1740801836-@bwe056-cell00.bisx.prod.on.blackberry> <457BFA0D.7070300@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <1E183972-8925-43F0-A309-E96987A0332F@qosient.com> From: Carter Bullard Subject: Re: [IPFIX] Template ID as scope for Common Properties Date: Sun, 10 Dec 2006 23:19:02 -0500 To: Andrew Johnson X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1684893680==" Errors-To: ipfix-bounces@ietf.org --===============1684893680== Content-Type: multipart/alternative; boundary=Apple-Mail-1-672465500 --Apple-Mail-1-672465500 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hmmmm, well argus has had its IP flow exchange protocol for about 15 years now, and we decided over the years not to do many of the things that the IPFIX WG is considering. We've done a number of control channel data channel strategies, compression schemes, template oriented (not to the extent of IPFIX) messaging between probe and collector, etc .... and found that being clever was not really very useful. Data reduction methods can be interesting, but you have to be careful, especially with scoping, when there are multiple readers, and they are interested in just a subset of the data. We decided not to use the approach proposed in the WG. On Dec 10, 2006, at 7:14 AM, Andrew Johnson wrote: > carter@qosient.com wrote: >> Hey Andrew, >> Some of your statements are starting to get at why argus is doing >> what >> its doing, with regard to scoping and source identification. >> However, >> I'm afraid that you guys have gone down the current path too far? > > So what is Argus doing and why? > > > Andrew > Carter --Apple-Mail-1-672465500 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hmmmm, well argus has had its IP = flow exchange protocol for about
15 years now, and we decided over = the years not to do many of the things
that the IPFIX=A0WG is = considering.=A0 We've done a number of control channel
data = channel=A0strategies, compression=A0schemes, template oriented (not = to
the extent=A0of IPFIX) messaging between=A0probe and = collector, etc .... and
found that=A0being clever was not = really very=A0useful.=A0 Data reduction methods
can be = interesting, but you have to be careful, especially with = scoping,
when there are multiple readers, and they are = interested in just a subset
of the data.=A0 =A0

We decided not to use the = approach proposed in the WG.

On Dec 10, 2006, at = 7:14 AM, Andrew Johnson wrote:

=
Hey Andrew,
Some of your statements are starting to get at why = argus is doing what
its doing, with regard to = scoping and source identification.=A0= However,
I'm afraid that you guys have = gone down the current path too far?

So what = is Argus doing and why?


Andrew


References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com><4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com><45780A37.8010905@cisco.com> <45782D40.20002@cisco.com><457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> <1561355564-1165687692-cardhu_blackberry.rim.net-1740801836-@bwe056-cell00.bisx.prod.on.blackberry> <457BFA0D.7070300@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <1E183972-8925-43F0-A309-E96987A0332F@qosient.com> From: Carter Bullard Subject: Re: [IPFIX] Template ID as scope for Common Properties Date: Sun, 10 Dec 2006 23:19:02 -0500 To: Andrew Johnson X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1684893680==" Errors-To: ipfix-bounces@ietf.org --===============1684893680== Content-Type: multipart/alternative; boundary=Apple-Mail-1-672465500 --Apple-Mail-1-672465500 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hmmmm, well argus has had its IP flow exchange protocol for about 15 years now, and we decided over the years not to do many of the things that the IPFIX WG is considering. We've done a number of control channel data channel strategies, compression schemes, template oriented (not to the extent of IPFIX) messaging between probe and collector, etc .... and found that being clever was not really very useful. Data reduction methods can be interesting, but you have to be careful, especially with scoping, when there are multiple readers, and they are interested in just a subset of the data. We decided not to use the approach proposed in the WG. On Dec 10, 2006, at 7:14 AM, Andrew Johnson wrote: > carter@qosient.com wrote: >> Hey Andrew, >> Some of your statements are starting to get at why argus is doing >> what >> its doing, with regard to scoping and source identification. >> However, >> I'm afraid that you guys have gone down the current path too far? > > So what is Argus doing and why? > > > Andrew > Carter --Apple-Mail-1-672465500 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hmmmm, well argus has had its IP = flow exchange protocol for about
15 years now, and we decided over = the years not to do many of the things
that the IPFIX=A0WG is = considering.=A0 We've done a number of control channel
data = channel=A0strategies, compression=A0schemes, template oriented (not = to
the extent=A0of IPFIX) messaging between=A0probe and = collector, etc .... and
found that=A0being clever was not = really very=A0useful.=A0 Data reduction methods
can be = interesting, but you have to be careful, especially with = scoping,
when there are multiple readers, and they are = interested in just a subset
of the data.=A0 =A0

We decided not to use the = approach proposed in the WG.

On Dec 10, 2006, at = 7:14 AM, Andrew Johnson wrote:

=
Hey Andrew,
Some of your statements are starting to get at why = argus is doing what
its doing, with regard to = scoping and source identification.=A0= However,
I'm afraid that you guys have = gone down the current path too far?

So what = is Argus doing and why?


Andrew


References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com><4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com><45780A37.8010905@cisco.com> <45782D40.20002@cisco.com><457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> <1561355564-1165687692-cardhu_blackberry.rim.net-1740801836-@bwe056-cell00.bisx.prod.on.blackberry> <457BFA0D.7070300@cisco.com> <1E183972-8925-43F0-A309-E96987A0332F@qosient.com> Message-Id: From: Carter Bullard Subject: Re: [IPFIX] Template ID as scope for Common Properties Date: Mon, 11 Dec 2006 11:38:22 -0500 To: Andrew Johnson , ipfix@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0422789658==" Errors-To: ipfix-bounces@ietf.org --===============0422789658== Content-Type: multipart/alternative; boundary=Apple-Mail-3-716825510 --Apple-Mail-3-716825510 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I guess its not fair just to state, "we don't use it", and leave it at that. One of the primary requirements of argus records, is that we can provide complete accountability of the source and disposition of argus records. If an intermediate process modifies a record, it must "own" the record, which means it must either originate the record, or re- originate it. This involves inserting the modifier's source identifier, timestamps, sequence numbers, etc ... (or at least references to these things) and provide some information about the nature of the changes. This is important for when you want to use flow records in applications that have a high requirement for reliability and data integrity, which is important for billing and most security applications, at least in our experience. This accountability issue tended to add a lot of overhead, so that there weren't predictable improvements in data reduction, and in some cases, we got data expansion, which of course was not the goal. Data reduction works well for data at rest, not necessarily data in motion, especially when reliability has a higher priority, at least that is some of the argus experience. Carter On Dec 10, 2006, at 11:19 PM, Carter Bullard wrote: > Hmmmm, well argus has had its IP flow exchange protocol for about > 15 years now, and we decided over the years not to do many of the > things > that the IPFIX WG is considering. We've done a number of control > channel > data channel strategies, compression schemes, template oriented > (not to > the extent of IPFIX) messaging between probe and collector, > etc .... and > found that being clever was not really very useful. Data reduction > methods > can be interesting, but you have to be careful, especially with > scoping, > when there are multiple readers, and they are interested in just a > subset > of the data. > > We decided not to use the approach proposed in the WG. > > On Dec 10, 2006, at 7:14 AM, Andrew Johnson wrote: > >> carter@qosient.com wrote: >>> Hey Andrew, >>> Some of your statements are starting to get at why argus is doing >>> what >>> its doing, with regard to scoping and source identification. >>> However, >>> I'm afraid that you guys have gone down the current path too far? >> >> So what is Argus doing and why? >> >> >> Andrew >> > > Carter > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix --Apple-Mail-3-716825510 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 I guess its not fair just to = state, "we don't use it", and leave it at that.

One of the primary requirements = of argus records, is that we can
provide = complete=A0accountability of the source and disposition of = argus
records.=A0 If an=A0intermediate process modifies a = record, it must "own" the
record,=A0which means it must either = originate the record, or re-originate it.
This involves = inserting the modifier's source identifier, timestamps, = sequence
numbers, etc ... (or at least references to these = things)=A0and provide some
information about the nature of the = changes.

This = is important for when you want to use flow records in = applications
that have a high requirement for reliability and = data integrity, which is
important for=A0billing and most = security applications, at least in = our
experience.

This accountability issue = tended to add a lot of=A0overhead, so that
there weren't = predictable improvements in data reduction, and in some
cases, = we got data expansion, which of=A0course was not the goal.

Data reduction works well = for data at rest, not necessarily data in motion,
especially = when reliability has a higher priority, at least that is some = of
the argus experience.

Carter



On Dec 10, = 2006, at 11:19 PM, Carter Bullard wrote:

Hmmmm, = well argus has had its IP flow exchange protocol for about
15 years = now, and we decided over the years not to do many of the = things
that the IPFIX=A0WG is considering.=A0 We've done a = number of control channel
data channel=A0strategies, = compression=A0schemes, template oriented (not to
the extent=A0of= IPFIX) messaging between=A0probe and collector, etc .... = and
found that=A0being clever was not really very=A0useful.=A0 = Data reduction methods
can be interesting, but you have to be = careful, especially with scoping,
when there are multiple = readers, and they are interested in just a subset
of the = data.=A0 =A0

We= decided not to use the approach proposed in the = WG.

On Dec 10, 2006, at 7:14 AM, Andrew Johnson = wrote:

=
Hey Andrew,
Some of your statements are starting to get at why = argus is doing what
its doing, with regard to = scoping and source identification.=A0= However,
I'm afraid that you guys have = gone down the current path too far?

So what = is Argus doing and why?


Andrew


IPFIX mailing list

References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com><4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com><45780A37.8010905@cisco.com> <45782D40.20002@cisco.com><457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> <1561355564-1165687692-cardhu_blackberry.rim.net-1740801836-@bwe056-cell00.bisx.prod.on.blackberry> <457BFA0D.7070300@cisco.com> <1E183972-8925-43F0-A309-E96987A0332F@qosient.com> Message-Id: From: Carter Bullard Subject: Re: [IPFIX] Template ID as scope for Common Properties Date: Mon, 11 Dec 2006 11:38:22 -0500 To: Andrew Johnson , ipfix@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0422789658==" Errors-To: ipfix-bounces@ietf.org --===============0422789658== Content-Type: multipart/alternative; boundary=Apple-Mail-3-716825510 --Apple-Mail-3-716825510 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I guess its not fair just to state, "we don't use it", and leave it at that. One of the primary requirements of argus records, is that we can provide complete accountability of the source and disposition of argus records. If an intermediate process modifies a record, it must "own" the record, which means it must either originate the record, or re- originate it. This involves inserting the modifier's source identifier, timestamps, sequence numbers, etc ... (or at least references to these things) and provide some information about the nature of the changes. This is important for when you want to use flow records in applications that have a high requirement for reliability and data integrity, which is important for billing and most security applications, at least in our experience. This accountability issue tended to add a lot of overhead, so that there weren't predictable improvements in data reduction, and in some cases, we got data expansion, which of course was not the goal. Data reduction works well for data at rest, not necessarily data in motion, especially when reliability has a higher priority, at least that is some of the argus experience. Carter On Dec 10, 2006, at 11:19 PM, Carter Bullard wrote: > Hmmmm, well argus has had its IP flow exchange protocol for about > 15 years now, and we decided over the years not to do many of the > things > that the IPFIX WG is considering. We've done a number of control > channel > data channel strategies, compression schemes, template oriented > (not to > the extent of IPFIX) messaging between probe and collector, > etc .... and > found that being clever was not really very useful. Data reduction > methods > can be interesting, but you have to be careful, especially with > scoping, > when there are multiple readers, and they are interested in just a > subset > of the data. > > We decided not to use the approach proposed in the WG. > > On Dec 10, 2006, at 7:14 AM, Andrew Johnson wrote: > >> carter@qosient.com wrote: >>> Hey Andrew, >>> Some of your statements are starting to get at why argus is doing >>> what >>> its doing, with regard to scoping and source identification. >>> However, >>> I'm afraid that you guys have gone down the current path too far? >> >> So what is Argus doing and why? >> >> >> Andrew >> > > Carter > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix --Apple-Mail-3-716825510 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 I guess its not fair just to = state, "we don't use it", and leave it at that.

One of the primary requirements = of argus records, is that we can
provide = complete=A0accountability of the source and disposition of = argus
records.=A0 If an=A0intermediate process modifies a = record, it must "own" the
record,=A0which means it must either = originate the record, or re-originate it.
This involves = inserting the modifier's source identifier, timestamps, = sequence
numbers, etc ... (or at least references to these = things)=A0and provide some
information about the nature of the = changes.

This = is important for when you want to use flow records in = applications
that have a high requirement for reliability and = data integrity, which is
important for=A0billing and most = security applications, at least in = our
experience.

This accountability issue = tended to add a lot of=A0overhead, so that
there weren't = predictable improvements in data reduction, and in some
cases, = we got data expansion, which of=A0course was not the goal.

Data reduction works well = for data at rest, not necessarily data in motion,
especially = when reliability has a higher priority, at least that is some = of
the argus experience.

Carter



On Dec 10, = 2006, at 11:19 PM, Carter Bullard wrote:

Hmmmm, = well argus has had its IP flow exchange protocol for about
15 years = now, and we decided over the years not to do many of the = things
that the IPFIX=A0WG is considering.=A0 We've done a = number of control channel
data channel=A0strategies, = compression=A0schemes, template oriented (not to
the extent=A0of= IPFIX) messaging between=A0probe and collector, etc .... = and
found that=A0being clever was not really very=A0useful.=A0 = Data reduction methods
can be interesting, but you have to be = careful, especially with scoping,
when there are multiple = readers, and they are interested in just a subset
of the = data.=A0 =A0

We= decided not to use the approach proposed in the = WG.

On Dec 10, 2006, at 7:14 AM, Andrew Johnson = wrote:

=
Hey Andrew,
Some of your statements are starting to get at why = argus is doing what
its doing, with regard to = scoping and source identification.=A0= However,
I'm afraid that you guys have = gone down the current path too far?

So what = is Argus doing and why?


Andrew


IPFIX mailing list

Date: Mon, 11 Dec 2006 19:04:00 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Carter Bullard Subject: Re: [IPFIX] Template ID as scope for Common Properties References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com><4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com><45780A37.8010905@cisco.com> <45782D40.20002@cisco.com><457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> <1561355564-1165687692-cardhu_blackberry.rim.net-1740801836-@bwe056-cell00.bisx.prod.on.blackberry> <457BFA0D.7070300@cisco.com> <1E183972-8925-43F0-A309-E96987A0332F@qosient.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3483; t=1165863884; x=1166727884; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Template=20ID=20as=20scope=20for=20Common=2 0Properties |Sender:=20; bh=GeVsQ/tKl5D8q6fDs9AcfjtZPXuRf5gkxNKmKNsiFuU=; b=JIdFJBhtqzXj707mTqmJjPGUolPPN65Xihz6e6Y8SepTbHR7MRNvy8X0vt3tNh6/l7+LpAiX DTF/8Gp1/d3QWLtQHXdkMS31GHijwv+JPTgHm++7NX58930ApTpHxqu9; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Carter Thanks, that's quite interesting. Within IPFIX we're specifying a bunch of ways you might want to send your information, in the case of your application you could use IPFIX, you just have some stricter requirements about how you use it. You may even want some new IEs so you can do something specific. In the case of a middle-box modifying records then the Observation Domain would be considered to have changed and it is likely that the middle-box would have to start inserting identification of the original Observation Domain (aka source) into the records. That said, the whole options thing isn't particularly clear right now, and the need for more guidance has been identified. I'm hoping to get the ball rolling in the next couple of months... Cheers Andrew Carter Bullard wrote: > I guess its not fair just to state, "we don't use it", and leave it at that. > > One of the primary requirements of argus records, is that we can > provide complete accountability of the source and disposition of argus > records. If an intermediate process modifies a record, it must "own" the > record, which means it must either originate the record, or re-originate it. > This involves inserting the modifier's source identifier, timestamps, > sequence > numbers, etc ... (or at least references to these things) and provide some > information about the nature of the changes. > > This is important for when you want to use flow records in applications > that have a high requirement for reliability and data integrity, which is > important for billing and most security applications, at least in our > experience. > > This accountability issue tended to add a lot of overhead, so that > there weren't predictable improvements in data reduction, and in some > cases, we got data expansion, which of course was not the goal. > > Data reduction works well for data at rest, not necessarily data in motion, > especially when reliability has a higher priority, at least that is some of > the argus experience. > > Carter > > > > On Dec 10, 2006, at 11:19 PM, Carter Bullard wrote: > >> Hmmmm, well argus has had its IP flow exchange protocol for about >> 15 years now, and we decided over the years not to do many of the things >> that the IPFIX WG is considering. We've done a number of control channel >> data channel strategies, compression schemes, template oriented (not to >> the extent of IPFIX) messaging between probe and collector, etc .... and >> found that being clever was not really very useful. Data reduction >> methods >> can be interesting, but you have to be careful, especially with scoping, >> when there are multiple readers, and they are interested in just a subset >> of the data. >> >> We decided not to use the approach proposed in the WG. >> >> On Dec 10, 2006, at 7:14 AM, Andrew Johnson wrote: >> >>> carter@qosient.com wrote: >>>> Hey Andrew, >>>> Some of your statements are starting to get at why argus is doing what >>>> its doing, with regard to scoping and source identification. However, >>>> I'm afraid that you guys have gone down the current path too far? >>> >>> So what is Argus doing and why? >>> >>> >>> Andrew >>> >> >> Carter >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipfix > > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Dec 11 14:06:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtqSH-0001Bv-CC; Mon, 11 Dec 2006 14:04:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtqSF-00019t-L7 for ipfix@ietf.org; Mon, 11 Dec 2006 14:04:47 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtqSD-00040B-7B for ipfix@ietf.org; Mon, 11 Dec 2006 14:04:47 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Dec 2006 20:04:45 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBBJ4iWl000979; Mon, 11 Dec 2006 20:04:44 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBBJ4ZAJ002231; Mon, 11 Dec 2006 20:04:39 +0100 (MET) Received: from [10.61.80.85] (ams3-vpn-dhcp4182.cisco.com [10.61.80.85]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA22278; Mon, 11 Dec 2006 19:04:30 GMT Message-ID: <457DABA0.2020401@cisco.com> Date: Mon, 11 Dec 2006 19:04:00 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Carter Bullard Subject: Re: [IPFIX] Template ID as scope for Common Properties References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com><4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com><45780A37.8010905@cisco.com> <45782D40.20002@cisco.com><457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> <1561355564-1165687692-cardhu_blackberry.rim.net-1740801836-@bwe056-cell00.bisx.prod.on.blackberry> <457BFA0D.7070300@cisco.com> <1E183972-8925-43F0-A309-E96987A0332F@qosient.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3483; t=1165863884; x=1166727884; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Template=20ID=20as=20scope=20for=20Common=2 0Properties |Sender:=20; bh=GeVsQ/tKl5D8q6fDs9AcfjtZPXuRf5gkxNKmKNsiFuU=; b=JIdFJBhtqzXj707mTqmJjPGUolPPN65Xihz6e6Y8SepTbHR7MRNvy8X0vt3tNh6/l7+LpAiX DTF/8Gp1/d3QWLtQHXdkMS31GHijwv+JPTgHm++7NX58930ApTpHxqu9; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Carter Thanks, that's quite interesting. Within IPFIX we're specifying a bunch of ways you might want to send your information, in the case of your application you could use IPFIX, you just have some stricter requirements about how you use it. You may even want some new IEs so you can do something specific. In the case of a middle-box modifying records then the Observation Domain would be considered to have changed and it is likely that the middle-box would have to start inserting identification of the original Observation Domain (aka source) into the records. That said, the whole options thing isn't particularly clear right now, and the need for more guidance has been identified. I'm hoping to get the ball rolling in the next couple of months... Cheers Andrew Carter Bullard wrote: > I guess its not fair just to state, "we don't use it", and leave it at that. > > One of the primary requirements of argus records, is that we can > provide complete accountability of the source and disposition of argus > records. If an intermediate process modifies a record, it must "own" the > record, which means it must either originate the record, or re-originate it. > This involves inserting the modifier's source identifier, timestamps, > sequence > numbers, etc ... (or at least references to these things) and provide some > information about the nature of the changes. > > This is important for when you want to use flow records in applications > that have a high requirement for reliability and data integrity, which is > important for billing and most security applications, at least in our > experience. > > This accountability issue tended to add a lot of overhead, so that > there weren't predictable improvements in data reduction, and in some > cases, we got data expansion, which of course was not the goal. > > Data reduction works well for data at rest, not necessarily data in motion, > especially when reliability has a higher priority, at least that is some of > the argus experience. > > Carter > > > > On Dec 10, 2006, at 11:19 PM, Carter Bullard wrote: > >> Hmmmm, well argus has had its IP flow exchange protocol for about >> 15 years now, and we decided over the years not to do many of the things >> that the IPFIX WG is considering. We've done a number of control channel >> data channel strategies, compression schemes, template oriented (not to >> the extent of IPFIX) messaging between probe and collector, etc .... and >> found that being clever was not really very useful. Data reduction >> methods >> can be interesting, but you have to be careful, especially with scoping, >> when there are multiple readers, and they are interested in just a subset >> of the data. >> >> We decided not to use the approach proposed in the WG. >> >> On Dec 10, 2006, at 7:14 AM, Andrew Johnson wrote: >> >>> carter@qosient.com wrote: >>>> Hey Andrew, >>>> Some of your statements are starting to get at why argus is doing what >>>> its doing, with regard to scoping and source identification. However, >>>> I'm afraid that you guys have gone down the current path too far? >>> >>> So what is Argus doing and why? >>> >>> >>> Andrew >>> >> >> Carter >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipfix > > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Dec 11 14:22:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtqia-0000VD-8O; Mon, 11 Dec 2006 14:21:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtqiZ-0000Ub-0P for ipfix@ietf.org; Mon, 11 Dec 2006 14:21:39 -0500 Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GtqiW-0006aX-Cs for ipfix@ietf.org; Mon, 11 Dec 2006 14:21:38 -0500 Received: (qmail 80035 invoked from network); 11 Dec 2006 19:21:29 -0000 Received: from 207.237.36.98 (HELO ?192.168.0.66?) (207.237.36.98) by relay00.pair.com with SMTP; 11 Dec 2006 19:21:29 -0000 X-pair-Authenticated: 207.237.36.98 In-Reply-To: <457DABA0.2020401@cisco.com> References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com><4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com><45780A37.8010905@cisco.com> <45782D40.20002@cisco.com><457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> <1561355564-1165687692-cardhu_blackberry.rim.net-1740801836-@bwe056-cell00.bisx.prod.on.blackberry> <457BFA0D.7070300@cisco.com> <1E183972-8925-43F0-A309-E96987A0332F@qosient.com> <457DABA0.2020401@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <202B5634-5934-4B3B-88E4-36D23C817BF3@qosient.com> From: Carter Bullard Subject: Re: [IPFIX] Template ID as scope for Common Properties Date: Mon, 11 Dec 2006 14:21:23 -0500 To: Andrew Johnson X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0766946474==" Errors-To: ipfix-bounces@ietf.org --===============0766946474== Content-Type: multipart/alternative; boundary=Apple-Mail-6-726606681 --Apple-Mail-6-726606681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hey Andrew, I was/(am?) quite active in IPFIX, and tried early to help, but .... We've found that the template strategy is pretty unusable for argus. We have so many possible combinations of objects that, in worst case, it would take 15K template descriptions to describe the variations in records that a collector might see during the life of a probe/collector session. There are architectural/philosophical problems. Argus is pure pull, not push, we have integrated TLS in the protocol itself, support for arbitrary data flow merging and splitting, and multicast transport. Stuff IPFIX wasn't interested in. That makes using IPFIX a bit of an issue, and I'm still befuddled about the SCTP requirement. Many sites are starting to treat SCTP as a firewall bypass technology, and as a result, are not forwarding it. Carter On Dec 11, 2006, at 2:04 PM, Andrew Johnson wrote: > Hi Carter > > Thanks, that's quite interesting. > > Within IPFIX we're specifying a bunch of ways you might want to send > your information, in the case of your application you could use IPFIX, > you just have some stricter requirements about how you use it. You > may even want some new IEs so you can do something specific. > > In the case of a middle-box modifying records then the Observation > Domain would be considered to have changed and it is likely that the > middle-box would have to start inserting identification of the > original Observation Domain (aka source) into the records. > > That said, the whole options thing isn't particularly clear right > now, and the need for more guidance has been identified. I'm hoping > to get the ball rolling in the next couple of months... > > Cheers > > Andrew > > > > Carter Bullard wrote: >> I guess its not fair just to state, "we don't use it", and leave >> it at that. >> One of the primary requirements of argus records, is that we can >> provide complete accountability of the source and disposition of >> argus >> records. If an intermediate process modifies a record, it must >> "own" the >> record, which means it must either originate the record, or re- >> originate it. >> This involves inserting the modifier's source identifier, >> timestamps, sequence >> numbers, etc ... (or at least references to these things) and >> provide some >> information about the nature of the changes. >> This is important for when you want to use flow records in >> applications >> that have a high requirement for reliability and data integrity, >> which is >> important for billing and most security applications, at least in our >> experience. >> This accountability issue tended to add a lot of overhead, so that >> there weren't predictable improvements in data reduction, and in some >> cases, we got data expansion, which of course was not the goal. >> Data reduction works well for data at rest, not necessarily data >> in motion, >> especially when reliability has a higher priority, at least that >> is some of >> the argus experience. >> Carter >> On Dec 10, 2006, at 11:19 PM, Carter Bullard wrote: >>> Hmmmm, well argus has had its IP flow exchange protocol for about >>> 15 years now, and we decided over the years not to do many of the >>> things >>> that the IPFIX WG is considering. We've done a number of control >>> channel >>> data channel strategies, compression schemes, template oriented >>> (not to >>> the extent of IPFIX) messaging between probe and collector, >>> etc .... and >>> found that being clever was not really very useful. Data >>> reduction methods >>> can be interesting, but you have to be careful, especially with >>> scoping, >>> when there are multiple readers, and they are interested in just >>> a subset >>> of the data. >>> We decided not to use the approach proposed in the WG. >>> >>> On Dec 10, 2006, at 7:14 AM, Andrew Johnson wrote: >>> >>>> carter@qosient.com wrote: >>>>> Hey Andrew, >>>>> Some of your statements are starting to get at why argus is >>>>> doing what >>>>> its doing, with regard to scoping and source identification. >>>>> However, >>>>> I'm afraid that you guys have gone down the current path too far? >>>> >>>> So what is Argus doing and why? >>>> >>>> >>>> Andrew >>>> >>> >>> Carter >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ipfix > --Apple-Mail-6-726606681 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hey Andrew,
I was/(am?) = quite active in IPFIX, and tried early to help, but ....=A0 We've found = that the
template strategy is pretty=A0unusable for argus.=A0 = We have so many possible combinations
of objects that, in = worst case, it would take 15K template=A0descriptions to describe = the
variations in records that a collector might see during = the life of a probe/collector session.=A0
There are = architectural/philosophical problems.=A0=A0Argus is pure pull, not push, = we have
integrated TLS in the protocol itself, support=A0for = arbitrary data flow merging and splitting,
and multicast = transport.=A0 Stuff IPFIX wasn't=A0interested in.=A0 That makes using = IPFIX a bit of
an issue, and=A0I'm still befuddled about the = SCTP requirement.=A0 Many sites are starting to
treat SCTP=A0as = a firewall bypass technology, and as a result,=A0 are not forwarding = it.

Carter


On Dec 11, = 2006, at 2:04 PM, Andrew Johnson wrote:

Hi Carter

Thanks, that's quite = interesting.

Within IPFIX we're specifying a bunch of ways you = might want to send
your information, in the = case of your application you could use IPFIX,
you just have some stricter requirements about how = you use it.=A0 = You
may even want some new IEs so = you can do something specific.

In the case of a middle-box = modifying records then the Observation
Domain = would be considered to have changed and it is likely that the
middle-box would have to start inserting = identification of the
original Observation Domain = (aka source) into the records.

That said, the whole options = thing isn't particularly clear right
now, and the = need for more guidance has been identified.=A0 I'm hoping
to get the ball rolling in the next couple of = months...

Cheers

Andrew



Carter Bullard wrote:
=
I guess its not fair just = to state, "we don't use it", and leave it at that.
One of the primary requirements of argus records, is = that we can
provide complete accountability = of the source and disposition of argus
=A0 If an = intermediate process modifies a record, it must "own" the
record, which means it must either originate the = record, or re-originate it.
This involves = inserting the modifier's source identifier, timestamps, = sequence
numbers, etc ... (or at least = references to these things) and provide some
information about the nature of the = changes.
This is important for when you = want to use flow records in applications
that = have a high requirement for reliability and data integrity, which = is
important for billing and most security = applications, at least in our
This accountability issue tended = to add a lot of overhead, so that
there weren't = predictable improvements in data reduction, and in some
cases, we got data expansion, which of course was = not the goal.
Data reduction works well for = data at rest, not necessarily data in motion,
especially when reliability has a higher priority, = at least that is some of
the argus = experience.
Carter
On Dec 10, 2006, at 11:19 PM, Carter Bullard = wrote:
Hmmmm, well = argus has had its IP flow exchange protocol for about
15 years now, and we decided over the years not to = do many of the things
that the IPFIX WG is = considering.=A0 We've done = a number of control channel
data channel = strategies, compression schemes, template oriented (not to
the extent of IPFIX) messaging between probe and = collector, etc .... and
found that = being clever was not really very useful.=A0 Data reduction = methods
can be interesting, but you have = to be careful, especially with scoping,
when = there are multiple readers, and they are interested in just a = subset
of the data.=A0 =A0
We decided not to use the approach proposed in the = WG.

On Dec 10, 2006, at 7:14 AM, Andrew Johnson = wrote:

=
carter@qosient.com <mailto:carter@qosient.com> = wrote:
Hey = Andrew,
Some of your statements are = starting to get at why argus is doing what
its = doing, with regard to scoping and source identification.=A0 However,
I'm afraid that you guys have gone down the current = path too far?

So what is Argus doing and = why?



=

Carter
IPFIX mailing list
mailto:IPFIX@ietf.org>

=



=

= --Apple-Mail-6-726606681-- --===============0766946474== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============0766946474==-- From ipfix-bounces@ietf.org Mon Dec 11 14:22:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtqia-0000VD-8O; Mon, 11 Dec 2006 14:21:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtqiZ-0000Ub-0P for ipfix@ietf.org; Mon, 11 Dec 2006 14:21:39 -0500 Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GtqiW-0006aX-Cs for ipfix@ietf.org; Mon, 11 Dec 2006 14:21:38 -0500 Received: (qmail 80035 invoked from network); 11 Dec 2006 19:21:29 -0000 Received: from 207.237.36.98 (HELO ?192.168.0.66?) (207.237.36.98) by relay00.pair.com with SMTP; 11 Dec 2006 19:21:29 -0000 X-pair-Authenticated: 207.237.36.98 In-Reply-To: <457DABA0.2020401@cisco.com> References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com><4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com><45780A37.8010905@cisco.com> <45782D40.20002@cisco.com><457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> <1561355564-1165687692-cardhu_blackberry.rim.net-1740801836-@bwe056-cell00.bisx.prod.on.blackberry> <457BFA0D.7070300@cisco.com> <1E183972-8925-43F0-A309-E96987A0332F@qosient.com> <457DABA0.2020401@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <202B5634-5934-4B3B-88E4-36D23C817BF3@qosient.com> From: Carter Bullard Subject: Re: [IPFIX] Template ID as scope for Common Properties Date: Mon, 11 Dec 2006 14:21:23 -0500 To: Andrew Johnson X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0766946474==" Errors-To: ipfix-bounces@ietf.org --===============0766946474== Content-Type: multipart/alternative; boundary=Apple-Mail-6-726606681 --Apple-Mail-6-726606681 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hey Andrew, I was/(am?) quite active in IPFIX, and tried early to help, but .... We've found that the template strategy is pretty unusable for argus. We have so many possible combinations of objects that, in worst case, it would take 15K template descriptions to describe the variations in records that a collector might see during the life of a probe/collector session. There are architectural/philosophical problems. Argus is pure pull, not push, we have integrated TLS in the protocol itself, support for arbitrary data flow merging and splitting, and multicast transport. Stuff IPFIX wasn't interested in. That makes using IPFIX a bit of an issue, and I'm still befuddled about the SCTP requirement. Many sites are starting to treat SCTP as a firewall bypass technology, and as a result, are not forwarding it. Carter On Dec 11, 2006, at 2:04 PM, Andrew Johnson wrote: > Hi Carter > > Thanks, that's quite interesting. > > Within IPFIX we're specifying a bunch of ways you might want to send > your information, in the case of your application you could use IPFIX, > you just have some stricter requirements about how you use it. You > may even want some new IEs so you can do something specific. > > In the case of a middle-box modifying records then the Observation > Domain would be considered to have changed and it is likely that the > middle-box would have to start inserting identification of the > original Observation Domain (aka source) into the records. > > That said, the whole options thing isn't particularly clear right > now, and the need for more guidance has been identified. I'm hoping > to get the ball rolling in the next couple of months... > > Cheers > > Andrew > > > > Carter Bullard wrote: >> I guess its not fair just to state, "we don't use it", and leave >> it at that. >> One of the primary requirements of argus records, is that we can >> provide complete accountability of the source and disposition of >> argus >> records. If an intermediate process modifies a record, it must >> "own" the >> record, which means it must either originate the record, or re- >> originate it. >> This involves inserting the modifier's source identifier, >> timestamps, sequence >> numbers, etc ... (or at least references to these things) and >> provide some >> information about the nature of the changes. >> This is important for when you want to use flow records in >> applications >> that have a high requirement for reliability and data integrity, >> which is >> important for billing and most security applications, at least in our >> experience. >> This accountability issue tended to add a lot of overhead, so that >> there weren't predictable improvements in data reduction, and in some >> cases, we got data expansion, which of course was not the goal. >> Data reduction works well for data at rest, not necessarily data >> in motion, >> especially when reliability has a higher priority, at least that >> is some of >> the argus experience. >> Carter >> On Dec 10, 2006, at 11:19 PM, Carter Bullard wrote: >>> Hmmmm, well argus has had its IP flow exchange protocol for about >>> 15 years now, and we decided over the years not to do many of the >>> things >>> that the IPFIX WG is considering. We've done a number of control >>> channel >>> data channel strategies, compression schemes, template oriented >>> (not to >>> the extent of IPFIX) messaging between probe and collector, >>> etc .... and >>> found that being clever was not really very useful. Data >>> reduction methods >>> can be interesting, but you have to be careful, especially with >>> scoping, >>> when there are multiple readers, and they are interested in just >>> a subset >>> of the data. >>> We decided not to use the approach proposed in the WG. >>> >>> On Dec 10, 2006, at 7:14 AM, Andrew Johnson wrote: >>> >>>> carter@qosient.com wrote: >>>>> Hey Andrew, >>>>> Some of your statements are starting to get at why argus is >>>>> doing what >>>>> its doing, with regard to scoping and source identification. >>>>> However, >>>>> I'm afraid that you guys have gone down the current path too far? >>>> >>>> So what is Argus doing and why? >>>> >>>> >>>> Andrew >>>> >>> >>> Carter >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ipfix > --Apple-Mail-6-726606681 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hey Andrew,
I was/(am?) = quite active in IPFIX, and tried early to help, but ....=A0 We've found = that the
template strategy is pretty=A0unusable for argus.=A0 = We have so many possible combinations
of objects that, in = worst case, it would take 15K template=A0descriptions to describe = the
variations in records that a collector might see during = the life of a probe/collector session.=A0
There are = architectural/philosophical problems.=A0=A0Argus is pure pull, not push, = we have
integrated TLS in the protocol itself, support=A0for = arbitrary data flow merging and splitting,
and multicast = transport.=A0 Stuff IPFIX wasn't=A0interested in.=A0 That makes using = IPFIX a bit of
an issue, and=A0I'm still befuddled about the = SCTP requirement.=A0 Many sites are starting to
treat SCTP=A0as = a firewall bypass technology, and as a result,=A0 are not forwarding = it.

Carter


On Dec 11, = 2006, at 2:04 PM, Andrew Johnson wrote:

Hi Carter

Thanks, that's quite = interesting.

Within IPFIX we're specifying a bunch of ways you = might want to send
your information, in the = case of your application you could use IPFIX,
you just have some stricter requirements about how = you use it.=A0 = You
may even want some new IEs so = you can do something specific.

In the case of a middle-box = modifying records then the Observation
Domain = would be considered to have changed and it is likely that the
middle-box would have to start inserting = identification of the
original Observation Domain = (aka source) into the records.

That said, the whole options = thing isn't particularly clear right
now, and the = need for more guidance has been identified.=A0 I'm hoping
to get the ball rolling in the next couple of = months...

Cheers

Andrew



Carter Bullard wrote:
=
I guess its not fair just = to state, "we don't use it", and leave it at that.
One of the primary requirements of argus records, is = that we can
provide complete accountability = of the source and disposition of argus
=A0 If an = intermediate process modifies a record, it must "own" the
record, which means it must either originate the = record, or re-originate it.
This involves = inserting the modifier's source identifier, timestamps, = sequence
numbers, etc ... (or at least = references to these things) and provide some
information about the nature of the = changes.
This is important for when you = want to use flow records in applications
that = have a high requirement for reliability and data integrity, which = is
important for billing and most security = applications, at least in our
This accountability issue tended = to add a lot of overhead, so that
there weren't = predictable improvements in data reduction, and in some
cases, we got data expansion, which of course was = not the goal.
Data reduction works well for = data at rest, not necessarily data in motion,
especially when reliability has a higher priority, = at least that is some of
the argus = experience.
Carter
On Dec 10, 2006, at 11:19 PM, Carter Bullard = wrote:
Hmmmm, well = argus has had its IP flow exchange protocol for about
15 years now, and we decided over the years not to = do many of the things
that the IPFIX WG is = considering.=A0 We've done = a number of control channel
data channel = strategies, compression schemes, template oriented (not to
the extent of IPFIX) messaging between probe and = collector, etc .... and
found that = being clever was not really very useful.=A0 Data reduction = methods
can be interesting, but you have = to be careful, especially with scoping,
when = there are multiple readers, and they are interested in just a = subset
of the data.=A0 =A0
We decided not to use the approach proposed in the = WG.

On Dec 10, 2006, at 7:14 AM, Andrew Johnson = wrote:

=
carter@qosient.com <mailto:carter@qosient.com> = wrote:
Hey = Andrew,
Some of your statements are = starting to get at why argus is doing what
its = doing, with regard to scoping and source identification.=A0 However,
I'm afraid that you guys have gone down the current = path too far?

So what is Argus doing and = why?



=

Carter
IPFIX mailing list
mailto:IPFIX@ietf.org>

=



=

= --Apple-Mail-6-726606681-- --===============0766946474== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============0766946474==-- From ipfix-bounces@ietf.org Mon Dec 11 15:20:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtrcA-00049i-1k; Mon, 11 Dec 2006 15:19:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtrc8-00049d-Ry for ipfix@ietf.org; Mon, 11 Dec 2006 15:19:04 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtrc7-0008K5-Fv for ipfix@ietf.org; Mon, 11 Dec 2006 15:19: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.7p3+Sun/8.11.7) with ESMTP id kBBKJ1706363; Mon, 11 Dec 2006 21:19:01 +0100 (CET) Received: from [10.61.65.45] (ams3-vpn-dhcp301.cisco.com [10.61.65.45]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kBBKJ0H27052; Mon, 11 Dec 2006 21:19:00 +0100 (CET) Message-ID: <457DBD33.204@cisco.com> Date: Mon, 11 Dec 2006 21:18:59 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] Fwd: Template Set padding issue References: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> <45519870.5010404@cisco.com> <67A49DC0-8809-4A58-B86E-A4F2373E4C12@cert.org> <45521EF5.2020304@cisco.com> <4552241E.8010100@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian, all, At the time of this post, the last protocol draft, which is now in the RFC-editor queue, was submitted already. After inquiring with the WG chairs and area director, we could still apply the change during the 48-hours review. The change is simple, and consistent throughout the document. It doesn't change the protocol, it's just a terminology clarification: "Template Withdrawal Message" should be replaced by "Template Withdrawal Set" "Template Withdraw Message" should be replaced by "Template Withdrawal Set" (*) (*) required because I just realized that we still have two terms in the current draft: Template Withdrawal Message and Template Withdraw Message. This should be corrected. Note that the protocol draft is the only document impacted by those changes. Does someone object these changes? Regards, Benoit. > > On Nov 8, 2006, at 10:38 AM, Paul Aitken wrote: > >> Actually, it seems to me that "Template Withdrawal Message" is a >> misnomer: it's really a Template Withdrawal *Set*, and what's >> important is that you don't try to define new templates in the same >> set - else you might end up in the situation Brian described earlier. >> >> I don't see a problem with sending both Template withdrawals and >> Option Template withdrawals as two sets in the same IPFIX message, >> nor with sending a mixture of templates and withdrawals in different >> sets in the same message. >> >> I think it'd be a lot clearer if the "Template Withdrawal Message" >> was renamed to "Template Withdrawal Set" and this text: >> >> The Template Withdraw Message MUST NOT contain new Template or >> Options Template Records. >> >> was changed to: >> >> The Template Withdraw Set MUST NOT contain new Template or >> Options Template Records. > > Absolutely. Benoit: are we at a state with the protocol now (sorry!) > that we could make this change? > > - Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Dec 11 15:20:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtrcA-00049i-1k; Mon, 11 Dec 2006 15:19:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtrc8-00049d-Ry for ipfix@ietf.org; Mon, 11 Dec 2006 15:19:04 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtrc7-0008K5-Fv for ipfix@ietf.org; Mon, 11 Dec 2006 15:19: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.7p3+Sun/8.11.7) with ESMTP id kBBKJ1706363; Mon, 11 Dec 2006 21:19:01 +0100 (CET) Received: from [10.61.65.45] (ams3-vpn-dhcp301.cisco.com [10.61.65.45]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kBBKJ0H27052; Mon, 11 Dec 2006 21:19:00 +0100 (CET) Message-ID: <457DBD33.204@cisco.com> Date: Mon, 11 Dec 2006 21:18:59 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] Fwd: Template Set padding issue References: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> <45519870.5010404@cisco.com> <67A49DC0-8809-4A58-B86E-A4F2373E4C12@cert.org> <45521EF5.2020304@cisco.com> <4552241E.8010100@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian, all, At the time of this post, the last protocol draft, which is now in the RFC-editor queue, was submitted already. After inquiring with the WG chairs and area director, we could still apply the change during the 48-hours review. The change is simple, and consistent throughout the document. It doesn't change the protocol, it's just a terminology clarification: "Template Withdrawal Message" should be replaced by "Template Withdrawal Set" "Template Withdraw Message" should be replaced by "Template Withdrawal Set" (*) (*) required because I just realized that we still have two terms in the current draft: Template Withdrawal Message and Template Withdraw Message. This should be corrected. Note that the protocol draft is the only document impacted by those changes. Does someone object these changes? Regards, Benoit. > > On Nov 8, 2006, at 10:38 AM, Paul Aitken wrote: > >> Actually, it seems to me that "Template Withdrawal Message" is a >> misnomer: it's really a Template Withdrawal *Set*, and what's >> important is that you don't try to define new templates in the same >> set - else you might end up in the situation Brian described earlier. >> >> I don't see a problem with sending both Template withdrawals and >> Option Template withdrawals as two sets in the same IPFIX message, >> nor with sending a mixture of templates and withdrawals in different >> sets in the same message. >> >> I think it'd be a lot clearer if the "Template Withdrawal Message" >> was renamed to "Template Withdrawal Set" and this text: >> >> The Template Withdraw Message MUST NOT contain new Template or >> Options Template Records. >> >> was changed to: >> >> The Template Withdraw Set MUST NOT contain new Template or >> Options Template Records. > > Absolutely. Benoit: are we at a state with the protocol now (sorry!) > that we could make this change? > > - Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From stocknews@toyota-cs.com Mon Dec 11 15:35:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtrsU-0002fS-Qf for ipfix-archive@lists.ietf.org; Mon, 11 Dec 2006 15:35:58 -0500 Received: from [213.190.197.91] (helo=pedro.netmadeira.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtrsT-00024u-8Z; Mon, 11 Dec 2006 15:35:58 -0500 Date: Mon, 11 Dec 2006 20:35:49 +0000 From: Pharmacy with the best prices X-Mailer: The Bat! (v2.11) UNREG / CD5BF9353B3B7091 Reply-To: Pharmacy with the best prices X-Priority: 3 (Normal) To: ipo-archive@lists.ietf.org Subject: Get your Cialis MIME-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Spam-Score: 4.9 (++++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hello member, äûìó, ñâèäåòåëüñòâîâàâøåìó î òîì, ÷òî êàøåâàðû â êåíòóðèÿõ íà÷àëè ãîòîâèòü

Discount meds here

 çàíîñèëî äûìêîì â êîëîííàäó ÷åðåç âåðõíþþ ïëîùàäêó ñàäà, è ê ãîðüêîâàòîìóíàêàçûâàåòå ìåíÿ? -- Òàê ýòî òû ïîäãîâàðèâàë íàðîä ðàçðóøèòü Åðøàëàèìñêèé õðàì?
Press this button! From ipfix-bounces@ietf.org Mon Dec 11 16:09:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtsOS-0001hN-HL; Mon, 11 Dec 2006 16:09:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtsOR-0001hB-M5 for ipfix@ietf.org; Mon, 11 Dec 2006 16:08:59 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtsO1-0007yr-Iu for ipfix@ietf.org; Mon, 11 Dec 2006 16:08:59 -0500 Received: from [192.168.1.128] (unknown [91.89.53.224]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 4B39E13CF82; Mon, 11 Dec 2006 22:13:16 +0100 (CET) Date: Mon, 11 Dec 2006 22:08:31 +0100 From: Juergen Quittek To: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: Template Set padding issue Message-ID: <6B13B9FF27790C2A05C639A1@juergen-quitteks-computer.local> In-Reply-To: <457DBD33.204@cisco.com> References: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> <45519870.5010404@cisco.com> <67A49DC0-8809-4A58-B86E-A4F2373E4C12@cert.org> <45521EF5.2020304@cisco.com> <4552241E.8010100@cisco.com> <457DBD33.204@cisco.com> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Benoit and all, Now that I have read the concerned section 8 of IPFIX-PROTO again, I found some more beautifications that seem to be desirable. 1. Section 8, paragraph 11: A Template Withdrawal Message/Set is NOT a Template Record. OLD: A Template Withdraw Message is a Template Record for that Template ID with a Field Count of 0. The format of the Template Withdrawal Message is shown in figure T. NEW: A Template Withdrawal Set contains a Template Record for that Template ID with a Field Count of 0. The format of the Template Withdrawal Set is shown in figure T. 2. Section 8, paragraph 12: not a Template Set is withdrawn, but Templates themselves are. OLD: The Set ID field MUST contain the value 2 for Template Set withdrawal and the value 3 for Options Template Set withdrawal. Multiple Template IDs MAY be withdrawn with a single Template Withdrawal Message: in that case, padding MAY be used. NEW: The Set ID field MUST contain the value 2 for a Template Withdrawal Set and the value 3 for an Option Template Withdrawal Set. Multiple Template IDs MAY be withdrawn with a single Template Withdrawal Set: in that case, padding MAY be used. 3. Section 8, paragraph 15: If we replaced Message with Set here, we would change the protocol. Therefore I'd suggest the following change. OLD: The Template Withdraw Message MUST NOT contain new Template or Options Template Records. NEW: An IPFIX Message containing any Template Withdrawal MUST not contain new Templates or Option Templates and it MUST NOT contain Option Template Records. Thanks, Juergen --On 11.12.06 21:18 +0100 Benoit Claise wrote: > Brian, all, > > At the time of this post, the last protocol draft, which is now in the RFC-editor queue, was submitted already. > After inquiring with the WG chairs and area director, we could still apply the change during the 48-hours review. > > The change is simple, and consistent throughout the document. It doesn't change the protocol, it's just a terminology clarification: > "Template Withdrawal Message" should be replaced by "Template Withdrawal Set" > "Template Withdraw Message" should be replaced by "Template Withdrawal Set" (*) > > (*) required because I just realized that we still have two terms in the current draft: Template Withdrawal Message and Template Withdraw Message. This should be corrected. > > Note that the protocol draft is the only document impacted by those changes. > Does someone object these changes? > > Regards, Benoit. >> >> On Nov 8, 2006, at 10:38 AM, Paul Aitken wrote: >> >>> Actually, it seems to me that "Template Withdrawal Message" is a >>> misnomer: it's really a Template Withdrawal *Set*, and what's >>> important is that you don't try to define new templates in the same >>> set - else you might end up in the situation Brian described earlier. >>> >>> I don't see a problem with sending both Template withdrawals and >>> Option Template withdrawals as two sets in the same IPFIX message, >>> nor with sending a mixture of templates and withdrawals in different >>> sets in the same message. >>> >>> I think it'd be a lot clearer if the "Template Withdrawal Message" >>> was renamed to "Template Withdrawal Set" and this text: >>> >>> The Template Withdraw Message MUST NOT contain new Template or >>> Options Template Records. >>> >>> was changed to: >>> >>> The Template Withdraw Set MUST NOT contain new Template or >>> Options Template Records. >> >> Absolutely. Benoit: are we at a state with the protocol now (sorry!) >> that we could make this change? >> >> - Brian > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 4342-115 NEC Europe Ltd., Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Dec 11 16:09:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtsOS-0001hN-HL; Mon, 11 Dec 2006 16:09:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtsOR-0001hB-M5 for ipfix@ietf.org; Mon, 11 Dec 2006 16:08:59 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtsO1-0007yr-Iu for ipfix@ietf.org; Mon, 11 Dec 2006 16:08:59 -0500 Received: from [192.168.1.128] (unknown [91.89.53.224]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 4B39E13CF82; Mon, 11 Dec 2006 22:13:16 +0100 (CET) Date: Mon, 11 Dec 2006 22:08:31 +0100 From: Juergen Quittek To: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: Template Set padding issue Message-ID: <6B13B9FF27790C2A05C639A1@juergen-quitteks-computer.local> In-Reply-To: <457DBD33.204@cisco.com> References: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> <45519870.5010404@cisco.com> <67A49DC0-8809-4A58-B86E-A4F2373E4C12@cert.org> <45521EF5.2020304@cisco.com> <4552241E.8010100@cisco.com> <457DBD33.204@cisco.com> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Benoit and all, Now that I have read the concerned section 8 of IPFIX-PROTO again, I found some more beautifications that seem to be desirable. 1. Section 8, paragraph 11: A Template Withdrawal Message/Set is NOT a Template Record. OLD: A Template Withdraw Message is a Template Record for that Template ID with a Field Count of 0. The format of the Template Withdrawal Message is shown in figure T. NEW: A Template Withdrawal Set contains a Template Record for that Template ID with a Field Count of 0. The format of the Template Withdrawal Set is shown in figure T. 2. Section 8, paragraph 12: not a Template Set is withdrawn, but Templates themselves are. OLD: The Set ID field MUST contain the value 2 for Template Set withdrawal and the value 3 for Options Template Set withdrawal. Multiple Template IDs MAY be withdrawn with a single Template Withdrawal Message: in that case, padding MAY be used. NEW: The Set ID field MUST contain the value 2 for a Template Withdrawal Set and the value 3 for an Option Template Withdrawal Set. Multiple Template IDs MAY be withdrawn with a single Template Withdrawal Set: in that case, padding MAY be used. 3. Section 8, paragraph 15: If we replaced Message with Set here, we would change the protocol. Therefore I'd suggest the following change. OLD: The Template Withdraw Message MUST NOT contain new Template or Options Template Records. NEW: An IPFIX Message containing any Template Withdrawal MUST not contain new Templates or Option Templates and it MUST NOT contain Option Template Records. Thanks, Juergen --On 11.12.06 21:18 +0100 Benoit Claise wrote: > Brian, all, > > At the time of this post, the last protocol draft, which is now in the RFC-editor queue, was submitted already. > After inquiring with the WG chairs and area director, we could still apply the change during the 48-hours review. > > The change is simple, and consistent throughout the document. It doesn't change the protocol, it's just a terminology clarification: > "Template Withdrawal Message" should be replaced by "Template Withdrawal Set" > "Template Withdraw Message" should be replaced by "Template Withdrawal Set" (*) > > (*) required because I just realized that we still have two terms in the current draft: Template Withdrawal Message and Template Withdraw Message. This should be corrected. > > Note that the protocol draft is the only document impacted by those changes. > Does someone object these changes? > > Regards, Benoit. >> >> On Nov 8, 2006, at 10:38 AM, Paul Aitken wrote: >> >>> Actually, it seems to me that "Template Withdrawal Message" is a >>> misnomer: it's really a Template Withdrawal *Set*, and what's >>> important is that you don't try to define new templates in the same >>> set - else you might end up in the situation Brian described earlier. >>> >>> I don't see a problem with sending both Template withdrawals and >>> Option Template withdrawals as two sets in the same IPFIX message, >>> nor with sending a mixture of templates and withdrawals in different >>> sets in the same message. >>> >>> I think it'd be a lot clearer if the "Template Withdrawal Message" >>> was renamed to "Template Withdrawal Set" and this text: >>> >>> The Template Withdraw Message MUST NOT contain new Template or >>> Options Template Records. >>> >>> was changed to: >>> >>> The Template Withdraw Set MUST NOT contain new Template or >>> Options Template Records. >> >> Absolutely. Benoit: are we at a state with the protocol now (sorry!) >> that we could make this change? >> >> - Brian > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 4342-115 NEC Europe Ltd., Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Dec 11 16:14:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtsTT-0002tP-7x; Mon, 11 Dec 2006 16:14:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtsTR-0002se-Dq for ipfix@ietf.org; Mon, 11 Dec 2006 16:14:09 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtsTN-0000b8-C9 for ipfix@ietf.org; Mon, 11 Dec 2006 16:14:09 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Dec 2006 22:14:05 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBBLE4d3016501; Mon, 11 Dec 2006 22:14:04 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBBLDsAJ020428; Mon, 11 Dec 2006 22:13:59 +0100 (MET) Received: from [10.61.80.53] (ams3-vpn-dhcp4150.cisco.com [10.61.80.53]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA03699; Mon, 11 Dec 2006 21:13:52 GMT Message-ID: <457DC9EE.4060905@cisco.com> Date: Mon, 11 Dec 2006 21:13:18 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: Brian Trammell , Benoit Claise Subject: Re: [IPFIX] Fwd: Template Set padding issue References: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> <45519870.5010404@cisco.com> <67A49DC0-8809-4A58-B86E-A4F2373E4C12@cert.org> <45521EF5.2020304@cisco.com> <4552241E.8010100@cisco.com> <457DBD33.204@cisco.com> <457DC729.6030502@cert.org> In-Reply-To: <457DC729.6030502@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1145; t=1165871644; x=1166735644; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20Fwd=3A=20Template=20Set=20padding=20issue |Sender:=20; bh=YU3p6kbgDo1UNWX5JBNiyf8I309e+mxzcD5l0OOSzpA=; b=PUe/ppoOrpxq8Q5yTLthhqv5s82s6x+ti5jpN+72ayVDh7vYyX1uuTO8IgcvOZm/l2BI55PP Qw9GsBomN1c1fkq3MrjtbvNFcSchEUjZvSoAPSaOc+hostVRWFr4tNU2; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Seconded. Brian Trammell wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > All, > > Looks good to me. > > Thanks, > > Brian > > Benoit Claise wrote: >> Brian, all, >> >> At the time of this post, the last protocol draft, which is now in the >> RFC-editor queue, was submitted already. >> After inquiring with the WG chairs and area director, we could still >> apply the change during the 48-hours review. >> >> The change is simple, and consistent throughout the document. It doesn't >> change the protocol, it's just a terminology clarification: >> "Template Withdrawal Message" should be replaced by "Template >> Withdrawal Set" >> "Template Withdraw Message" should be replaced by "Template Withdrawal >> Set" (*) >> >> (*) required because I just realized that we still have two terms in the >> current draft: Template Withdrawal Message and Template Withdraw >> Message. This should be corrected. >> >> Note that the protocol draft is the only document impacted by those >> changes. >> Does someone object these changes? -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Dec 11 16:14:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtsTT-0002tP-7x; Mon, 11 Dec 2006 16:14:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtsTR-0002se-Dq for ipfix@ietf.org; Mon, 11 Dec 2006 16:14:09 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtsTN-0000b8-C9 for ipfix@ietf.org; Mon, 11 Dec 2006 16:14:09 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Dec 2006 22:14:05 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBBLE4d3016501; Mon, 11 Dec 2006 22:14:04 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBBLDsAJ020428; Mon, 11 Dec 2006 22:13:59 +0100 (MET) Received: from [10.61.80.53] (ams3-vpn-dhcp4150.cisco.com [10.61.80.53]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA03699; Mon, 11 Dec 2006 21:13:52 GMT Message-ID: <457DC9EE.4060905@cisco.com> Date: Mon, 11 Dec 2006 21:13:18 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: Brian Trammell , Benoit Claise Subject: Re: [IPFIX] Fwd: Template Set padding issue References: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> <45519870.5010404@cisco.com> <67A49DC0-8809-4A58-B86E-A4F2373E4C12@cert.org> <45521EF5.2020304@cisco.com> <4552241E.8010100@cisco.com> <457DBD33.204@cisco.com> <457DC729.6030502@cert.org> In-Reply-To: <457DC729.6030502@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1145; t=1165871644; x=1166735644; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20Fwd=3A=20Template=20Set=20padding=20issue |Sender:=20; bh=YU3p6kbgDo1UNWX5JBNiyf8I309e+mxzcD5l0OOSzpA=; b=PUe/ppoOrpxq8Q5yTLthhqv5s82s6x+ti5jpN+72ayVDh7vYyX1uuTO8IgcvOZm/l2BI55PP Qw9GsBomN1c1fkq3MrjtbvNFcSchEUjZvSoAPSaOc+hostVRWFr4tNU2; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Seconded. Brian Trammell wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > All, > > Looks good to me. > > Thanks, > > Brian > > Benoit Claise wrote: >> Brian, all, >> >> At the time of this post, the last protocol draft, which is now in the >> RFC-editor queue, was submitted already. >> After inquiring with the WG chairs and area director, we could still >> apply the change during the 48-hours review. >> >> The change is simple, and consistent throughout the document. It doesn't >> change the protocol, it's just a terminology clarification: >> "Template Withdrawal Message" should be replaced by "Template >> Withdrawal Set" >> "Template Withdraw Message" should be replaced by "Template Withdrawal >> Set" (*) >> >> (*) required because I just realized that we still have two terms in the >> current draft: Template Withdrawal Message and Template Withdraw >> Message. This should be corrected. >> >> Note that the protocol draft is the only document impacted by those >> changes. >> Does someone object these changes? -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Dec 11 16:19:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtsYV-0004Ih-DE; Mon, 11 Dec 2006 16:19:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtsIO-0005ln-N7 for ipfix@ietf.org; Mon, 11 Dec 2006 16:02:44 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtsI7-00076l-Jf for ipfix@ietf.org; Mon, 11 Dec 2006 16:02:44 -0500 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kBBL2K2w001835 for ; Mon, 11 Dec 2006 16:02:20 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kBBL2ECm001819 for ; Mon, 11 Dec 2006 16:02:14 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kBBL2Dj6001815; Mon, 11 Dec 2006 16:02:14 -0500 (EST) Received: from [128.237.236.9] (vpn-10-25-4-22.remote.cert.org [10.25.4.22]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.66) with ESMTP id kBBL2Daa015437; Mon, 11 Dec 2006 16:02:13 -0500 Message-ID: <457DC729.6030502@cert.org> Date: Mon, 11 Dec 2006 16:01:29 -0500 From: Brian Trammell User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Benoit Claise Subject: Re: [IPFIX] Fwd: Template Set padding issue References: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> <45519870.5010404@cisco.com> <67A49DC0-8809-4A58-B86E-A4F2373E4C12@cert.org> <45521EF5.2020304@cisco.com> <4552241E.8010100@cisco.com> <457DBD33.204@cisco.com> In-Reply-To: <457DBD33.204@cisco.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, Looks good to me. Thanks, Brian Benoit Claise wrote: > Brian, all, > > At the time of this post, the last protocol draft, which is now in the > RFC-editor queue, was submitted already. > After inquiring with the WG chairs and area director, we could still > apply the change during the 48-hours review. > > The change is simple, and consistent throughout the document. It doesn't > change the protocol, it's just a terminology clarification: > "Template Withdrawal Message" should be replaced by "Template > Withdrawal Set" > "Template Withdraw Message" should be replaced by "Template Withdrawal > Set" (*) > > (*) required because I just realized that we still have two terms in the > current draft: Template Withdrawal Message and Template Withdraw > Message. This should be corrected. > > Note that the protocol draft is the only document impacted by those > changes. > Does someone object these changes? > > Regards, Benoit. >> >> On Nov 8, 2006, at 10:38 AM, Paul Aitken wrote: >> >>> Actually, it seems to me that "Template Withdrawal Message" is a >>> misnomer: it's really a Template Withdrawal *Set*, and what's >>> important is that you don't try to define new templates in the same >>> set - else you might end up in the situation Brian described earlier. >>> >>> I don't see a problem with sending both Template withdrawals and >>> Option Template withdrawals as two sets in the same IPFIX message, >>> nor with sending a mixture of templates and withdrawals in different >>> sets in the same message. >>> >>> I think it'd be a lot clearer if the "Template Withdrawal Message" >>> was renamed to "Template Withdrawal Set" and this text: >>> >>> The Template Withdraw Message MUST NOT contain new Template or >>> Options Template Records. >>> >>> was changed to: >>> >>> The Template Withdraw Set MUST NOT contain new Template or >>> Options Template Records. >> >> Absolutely. Benoit: are we at a state with the protocol now (sorry!) >> that we could make this change? >> >> - Brian > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFfccp4/8LCZ4pwvYRAgBTAJ0RbnB68IhL/Yt0v9nEgVXA78GWWQCfYdHm HaKASFQ1khBnd8zE1sOndSI= =EP36 -----END PGP SIGNATURE----- _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Dec 11 16:19:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtsYV-0004Ih-DE; Mon, 11 Dec 2006 16:19:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtsIO-0005ln-N7 for ipfix@ietf.org; Mon, 11 Dec 2006 16:02:44 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtsI7-00076l-Jf for ipfix@ietf.org; Mon, 11 Dec 2006 16:02:44 -0500 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kBBL2K2w001835 for ; Mon, 11 Dec 2006 16:02:20 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kBBL2ECm001819 for ; Mon, 11 Dec 2006 16:02:14 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kBBL2Dj6001815; Mon, 11 Dec 2006 16:02:14 -0500 (EST) Received: from [128.237.236.9] (vpn-10-25-4-22.remote.cert.org [10.25.4.22]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.66) with ESMTP id kBBL2Daa015437; Mon, 11 Dec 2006 16:02:13 -0500 Message-ID: <457DC729.6030502@cert.org> Date: Mon, 11 Dec 2006 16:01:29 -0500 From: Brian Trammell User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Benoit Claise Subject: Re: [IPFIX] Fwd: Template Set padding issue References: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> <45519870.5010404@cisco.com> <67A49DC0-8809-4A58-B86E-A4F2373E4C12@cert.org> <45521EF5.2020304@cisco.com> <4552241E.8010100@cisco.com> <457DBD33.204@cisco.com> In-Reply-To: <457DBD33.204@cisco.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, Looks good to me. Thanks, Brian Benoit Claise wrote: > Brian, all, > > At the time of this post, the last protocol draft, which is now in the > RFC-editor queue, was submitted already. > After inquiring with the WG chairs and area director, we could still > apply the change during the 48-hours review. > > The change is simple, and consistent throughout the document. It doesn't > change the protocol, it's just a terminology clarification: > "Template Withdrawal Message" should be replaced by "Template > Withdrawal Set" > "Template Withdraw Message" should be replaced by "Template Withdrawal > Set" (*) > > (*) required because I just realized that we still have two terms in the > current draft: Template Withdrawal Message and Template Withdraw > Message. This should be corrected. > > Note that the protocol draft is the only document impacted by those > changes. > Does someone object these changes? > > Regards, Benoit. >> >> On Nov 8, 2006, at 10:38 AM, Paul Aitken wrote: >> >>> Actually, it seems to me that "Template Withdrawal Message" is a >>> misnomer: it's really a Template Withdrawal *Set*, and what's >>> important is that you don't try to define new templates in the same >>> set - else you might end up in the situation Brian described earlier. >>> >>> I don't see a problem with sending both Template withdrawals and >>> Option Template withdrawals as two sets in the same IPFIX message, >>> nor with sending a mixture of templates and withdrawals in different >>> sets in the same message. >>> >>> I think it'd be a lot clearer if the "Template Withdrawal Message" >>> was renamed to "Template Withdrawal Set" and this text: >>> >>> The Template Withdraw Message MUST NOT contain new Template or >>> Options Template Records. >>> >>> was changed to: >>> >>> The Template Withdraw Set MUST NOT contain new Template or >>> Options Template Records. >> >> Absolutely. Benoit: are we at a state with the protocol now (sorry!) >> that we could make this change? >> >> - Brian > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFfccp4/8LCZ4pwvYRAgBTAJ0RbnB68IhL/Yt0v9nEgVXA78GWWQCfYdHm HaKASFQ1khBnd8zE1sOndSI= =EP36 -----END PGP SIGNATURE----- _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Dec 11 17:44:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GttsF-0005tz-21; Mon, 11 Dec 2006 17:43:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GttsD-0005tq-Vt for ipfix@ietf.org; Mon, 11 Dec 2006 17:43:49 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GttsC-0008Fa-54 for ipfix@ietf.org; Mon, 11 Dec 2006 17:43:49 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Dec 2006 23:43:45 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBBMhhue009876; Mon, 11 Dec 2006 23:43:43 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBBMhcAJ001241; Mon, 11 Dec 2006 23:43:38 +0100 (MET) Received: from [10.61.64.156] (ams3-vpn-dhcp156.cisco.com [10.61.64.156]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA12570; Mon, 11 Dec 2006 22:43:37 GMT Message-ID: <457DDEFB.9080904@cisco.com> Date: Mon, 11 Dec 2006 22:43:07 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Carter Bullard Subject: Re: [IPFIX] Template ID as scope for Common Properties References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com><4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com><45780A37.8010905@cisco.com> <45782D40.20002@cisco.com><457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> <1561355564-1165687692-cardhu_blackberry.rim.net-1740801836-@bwe056-cell00.bisx.prod.on.blackberry> <457BFA0D.7070300@cisco.com> <1E183972-8925-43F0-A309-E96987A0332F@qosient.com> <457DABA0.2020401@cisco.com> <202B5634-5934-4B3B-88E4-36D23C817BF3@qosient.com> In-Reply-To: <202B5634-5934-4B3B-88E4-36D23C817BF3@qosient.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5549; t=1165877023; x=1166741023; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Template=20ID=20as=20scope=20for=20Common=2 0Properties |Sender:=20; bh=2VHoPODl6jm4hs4773LNVbXSHTkhfjB/JYsyJ8j0iu0=; b=pMzkPxMgM0FWrC5qIBcONhJmmVKEAMNTdPSXmiiawOx8O2CzF0rIb4Zq/DgOh86k23s6vxxV OUqZw7UnQ8Prm+m+n1zZ37ZMxsdmgtjlTjPiOgbiqIxxtiAM4pc7yzUT; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Carter Bullard wrote: > Hey Andrew, > I was/(am?) quite active in IPFIX, and tried early to help, but .... Yeah, I do remember you from a recent WG meeting (Vancouver?). > We've found that the > template strategy is pretty unusable for argus. We have so many > possible combinations > of objects that, in worst case, it would take 15K template descriptions > to describe the > variations in records that a collector might see during the life of a > probe/collector session. In theory it shouldn't much worse than TLV. The Templates are the TL and the Data Record the V. OTOH if your data really does vary for nearly every record then perhaps IPFIX isn't the best transport protocol. It also doesn't sound as if you're sending well defined Flows in the same way I'm used to. > There are architectural/philosophical problems. Argus is pure pull, not > push, we have > integrated TLS in the protocol itself, support for arbitrary data flow > merging and splitting, > and multicast transport. Stuff IPFIX wasn't interested in. Yet... :) I'm sure we'll see a number of extensions to IPFIX over the next couple of years. I have to agree that there are a number of areas that IPFIX doesn't handle particularly well, but it should handle the applications it's currently targeted well enough. > ... That makes using IPFIX a bit of > an issue, and I'm still befuddled about the SCTP requirement. Many > sites are starting to > treat SCTP as a firewall bypass technology, and as a result, are not > forwarding it. I think it's still early days for SCTP. I expect it'll gain acceptance after a while. Meanwhile, I don't think it will be an issue in the enterprise environment. For the moment IPFIX will mostly be used inside the firewall. Andrew > On Dec 11, 2006, at 2:04 PM, Andrew Johnson wrote: > >> Hi Carter >> >> Thanks, that's quite interesting. >> >> Within IPFIX we're specifying a bunch of ways you might want to send >> your information, in the case of your application you could use IPFIX, >> you just have some stricter requirements about how you use it. You >> may even want some new IEs so you can do something specific. >> >> In the case of a middle-box modifying records then the Observation >> Domain would be considered to have changed and it is likely that the >> middle-box would have to start inserting identification of the >> original Observation Domain (aka source) into the records. >> >> That said, the whole options thing isn't particularly clear right >> now, and the need for more guidance has been identified. I'm hoping >> to get the ball rolling in the next couple of months... >> >> Cheers >> >> Andrew >> >> >> >> Carter Bullard wrote: >>> I guess its not fair just to state, "we don't use it", and leave it >>> at that. >>> One of the primary requirements of argus records, is that we can >>> provide complete accountability of the source and disposition of argus >>> records. If an intermediate process modifies a record, it must "own" the >>> record, which means it must either originate the record, or >>> re-originate it. >>> This involves inserting the modifier's source identifier, timestamps, >>> sequence >>> numbers, etc ... (or at least references to these things) and provide >>> some >>> information about the nature of the changes. >>> This is important for when you want to use flow records in applications >>> that have a high requirement for reliability and data integrity, which is >>> important for billing and most security applications, at least in our >>> experience. >>> This accountability issue tended to add a lot of overhead, so that >>> there weren't predictable improvements in data reduction, and in some >>> cases, we got data expansion, which of course was not the goal. >>> Data reduction works well for data at rest, not necessarily data in >>> motion, >>> especially when reliability has a higher priority, at least that is >>> some of >>> the argus experience. >>> Carter >>> On Dec 10, 2006, at 11:19 PM, Carter Bullard wrote: >>>> Hmmmm, well argus has had its IP flow exchange protocol for about >>>> 15 years now, and we decided over the years not to do many of the things >>>> that the IPFIX WG is considering. We've done a number of control >>>> channel >>>> data channel strategies, compression schemes, template oriented (not to >>>> the extent of IPFIX) messaging between probe and collector, etc .... and >>>> found that being clever was not really very useful. Data reduction >>>> methods >>>> can be interesting, but you have to be careful, especially with scoping, >>>> when there are multiple readers, and they are interested in just a >>>> subset >>>> of the data. >>>> We decided not to use the approach proposed in the WG. >>>> >>>> On Dec 10, 2006, at 7:14 AM, Andrew Johnson wrote: >>>> >>>>> carter@qosient.com wrote: >>>>>> Hey Andrew, >>>>>> Some of your statements are starting to get at why argus is doing what >>>>>> its doing, with regard to scoping and source identification. However, >>>>>> I'm afraid that you guys have gone down the current path too far? >>>>> >>>>> So what is Argus doing and why? >>>>> >>>>> >>>>> Andrew >>>>> >>>> >>>> Carter >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ipfix >> > > > > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Dec 11 17:44:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GttsF-0005tz-21; Mon, 11 Dec 2006 17:43:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GttsD-0005tq-Vt for ipfix@ietf.org; Mon, 11 Dec 2006 17:43:49 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GttsC-0008Fa-54 for ipfix@ietf.org; Mon, 11 Dec 2006 17:43:49 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Dec 2006 23:43:45 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBBMhhue009876; Mon, 11 Dec 2006 23:43:43 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBBMhcAJ001241; Mon, 11 Dec 2006 23:43:38 +0100 (MET) Received: from [10.61.64.156] (ams3-vpn-dhcp156.cisco.com [10.61.64.156]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA12570; Mon, 11 Dec 2006 22:43:37 GMT Message-ID: <457DDEFB.9080904@cisco.com> Date: Mon, 11 Dec 2006 22:43:07 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Carter Bullard Subject: Re: [IPFIX] Template ID as scope for Common Properties References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com><4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com><45780A37.8010905@cisco.com> <45782D40.20002@cisco.com><457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> <1561355564-1165687692-cardhu_blackberry.rim.net-1740801836-@bwe056-cell00.bisx.prod.on.blackberry> <457BFA0D.7070300@cisco.com> <1E183972-8925-43F0-A309-E96987A0332F@qosient.com> <457DABA0.2020401@cisco.com> <202B5634-5934-4B3B-88E4-36D23C817BF3@qosient.com> In-Reply-To: <202B5634-5934-4B3B-88E4-36D23C817BF3@qosient.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5549; t=1165877023; x=1166741023; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Template=20ID=20as=20scope=20for=20Common=2 0Properties |Sender:=20; bh=2VHoPODl6jm4hs4773LNVbXSHTkhfjB/JYsyJ8j0iu0=; b=pMzkPxMgM0FWrC5qIBcONhJmmVKEAMNTdPSXmiiawOx8O2CzF0rIb4Zq/DgOh86k23s6vxxV OUqZw7UnQ8Prm+m+n1zZ37ZMxsdmgtjlTjPiOgbiqIxxtiAM4pc7yzUT; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Carter Bullard wrote: > Hey Andrew, > I was/(am?) quite active in IPFIX, and tried early to help, but .... Yeah, I do remember you from a recent WG meeting (Vancouver?). > We've found that the > template strategy is pretty unusable for argus. We have so many > possible combinations > of objects that, in worst case, it would take 15K template descriptions > to describe the > variations in records that a collector might see during the life of a > probe/collector session. In theory it shouldn't much worse than TLV. The Templates are the TL and the Data Record the V. OTOH if your data really does vary for nearly every record then perhaps IPFIX isn't the best transport protocol. It also doesn't sound as if you're sending well defined Flows in the same way I'm used to. > There are architectural/philosophical problems. Argus is pure pull, not > push, we have > integrated TLS in the protocol itself, support for arbitrary data flow > merging and splitting, > and multicast transport. Stuff IPFIX wasn't interested in. Yet... :) I'm sure we'll see a number of extensions to IPFIX over the next couple of years. I have to agree that there are a number of areas that IPFIX doesn't handle particularly well, but it should handle the applications it's currently targeted well enough. > ... That makes using IPFIX a bit of > an issue, and I'm still befuddled about the SCTP requirement. Many > sites are starting to > treat SCTP as a firewall bypass technology, and as a result, are not > forwarding it. I think it's still early days for SCTP. I expect it'll gain acceptance after a while. Meanwhile, I don't think it will be an issue in the enterprise environment. For the moment IPFIX will mostly be used inside the firewall. Andrew > On Dec 11, 2006, at 2:04 PM, Andrew Johnson wrote: > >> Hi Carter >> >> Thanks, that's quite interesting. >> >> Within IPFIX we're specifying a bunch of ways you might want to send >> your information, in the case of your application you could use IPFIX, >> you just have some stricter requirements about how you use it. You >> may even want some new IEs so you can do something specific. >> >> In the case of a middle-box modifying records then the Observation >> Domain would be considered to have changed and it is likely that the >> middle-box would have to start inserting identification of the >> original Observation Domain (aka source) into the records. >> >> That said, the whole options thing isn't particularly clear right >> now, and the need for more guidance has been identified. I'm hoping >> to get the ball rolling in the next couple of months... >> >> Cheers >> >> Andrew >> >> >> >> Carter Bullard wrote: >>> I guess its not fair just to state, "we don't use it", and leave it >>> at that. >>> One of the primary requirements of argus records, is that we can >>> provide complete accountability of the source and disposition of argus >>> records. If an intermediate process modifies a record, it must "own" the >>> record, which means it must either originate the record, or >>> re-originate it. >>> This involves inserting the modifier's source identifier, timestamps, >>> sequence >>> numbers, etc ... (or at least references to these things) and provide >>> some >>> information about the nature of the changes. >>> This is important for when you want to use flow records in applications >>> that have a high requirement for reliability and data integrity, which is >>> important for billing and most security applications, at least in our >>> experience. >>> This accountability issue tended to add a lot of overhead, so that >>> there weren't predictable improvements in data reduction, and in some >>> cases, we got data expansion, which of course was not the goal. >>> Data reduction works well for data at rest, not necessarily data in >>> motion, >>> especially when reliability has a higher priority, at least that is >>> some of >>> the argus experience. >>> Carter >>> On Dec 10, 2006, at 11:19 PM, Carter Bullard wrote: >>>> Hmmmm, well argus has had its IP flow exchange protocol for about >>>> 15 years now, and we decided over the years not to do many of the things >>>> that the IPFIX WG is considering. We've done a number of control >>>> channel >>>> data channel strategies, compression schemes, template oriented (not to >>>> the extent of IPFIX) messaging between probe and collector, etc .... and >>>> found that being clever was not really very useful. Data reduction >>>> methods >>>> can be interesting, but you have to be careful, especially with scoping, >>>> when there are multiple readers, and they are interested in just a >>>> subset >>>> of the data. >>>> We decided not to use the approach proposed in the WG. >>>> >>>> On Dec 10, 2006, at 7:14 AM, Andrew Johnson wrote: >>>> >>>>> carter@qosient.com wrote: >>>>>> Hey Andrew, >>>>>> Some of your statements are starting to get at why argus is doing what >>>>>> its doing, with regard to scoping and source identification. However, >>>>>> I'm afraid that you guys have gone down the current path too far? >>>>> >>>>> So what is Argus doing and why? >>>>> >>>>> >>>>> Andrew >>>>> >>>> >>>> Carter >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ipfix >> > > > > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From replica@alomebel.ru Mon Dec 11 21:12:45 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtx8P-0005p8-Ql for ipfix-archive@lists.ietf.org; Mon, 11 Dec 2006 21:12:45 -0500 Received: from ip3e83447e.speed.planet.nl ([62.131.68.126]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gtx8H-0006UW-B8 for ipfix-archive@lists.ietf.org; Mon, 11 Dec 2006 21:12:45 -0500 Received: from [194.161.54.94] (port=12466 helo=ohourqfnkkn) by alomebel.ru with psmtp id XOmIDW-b51699-00 for ; Tue, 12 Dec 2006 03:12:54 +0100 Message-ID: <000701c71d92$f82ba8b0$00000000@Sanne> From: "theaters done" To: ipfix-archive@lists.ietf.org Subject: dreams outside Date: Tue, 12 Dec 2006 03:12:26 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C71D9B.59F010B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.3 (/) X-Scan-Signature: 2e8a07f64def4bd8598257bc442beb9d ------=_NextPart_000_0003_01C71D9B.59F010B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C71D9B.59F010B0" ------=_NextPart_001_0004_01C71D9B.59F010B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Building blitz checks wii, strap iming, divides. Liveaction doll = ringwald ritter scoobydoo monstrous tails uncle, scooby. Surreal animation suzan pitt. Holy tango francis emmis star. July tao folk theory jm weapons delusion. Still unresolved excerpt oneills opinion. Laughton, oscar, levant = marilyn, monroe gregory ratoff robertson widmark. Reshaping railways bfis, doubledisc transport combining favourites. = Cartoons mastered superior vault lesters deluxe, outing annette. Majority leader frist rtenn sen minority daschle dsd. Von, lohmann frontier civil. Housed mock burial tree! Indeed, spiderman = anchorman fahrenheit. Advent fragile regarded dreyers betrayal gripped obsessive fear, = witchcraft. Reasonably memory expressed feb. Gamefaqs metacritic mpcom tvcom dd login background. Patient slasher = archangel, oxford. Online, stuffmy logoutgt playing, viewedjust = ratedgirl daymore! Computers whatever taste formats manuscript unbound. End, whats benign, devil, path legitimacy? Wordplay indepth crossword = puzzle? Abundance testament brethren catcher ryeabout security policies. Voip centercrm bull corporate guide awardswhos tmcnet provider = directory. Records venues prime metallic foil essays noted? Exposure, barry fact = thomas ben men pockets crews, within? Episode skies us exploring = reaches. Drops shuts liteapple calls ipod theft costs lab, phishing. Courteney, cox elliott, glover. Crew prepares building blitz checks! Online stuffmy logoutgt playing viewedjust, ratedgirl daymore. ------=_NextPart_001_0004_01C71D9B.59F010B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"Terrence"
Building blitz checks wii, strap iming, = divides.=20 Liveaction doll ringwald ritter scoobydoo monstrous tails uncle, = scooby.
Surreal animation suzan = pitt.
Holy tango francis emmis star. July tao = folk theory=20 jm weapons delusion.
Still unresolved excerpt oneills = opinion. Laughton,=20 oscar, levant marilyn, monroe gregory ratoff robertson = widmark.
Reshaping railways bfis, doubledisc = transport=20 combining favourites. Cartoons mastered superior vault lesters deluxe, = outing annette.
Majority leader frist rtenn sen = minority daschle dsd.
Von, lohmann frontier civil. Housed = mock burial=20 tree! Indeed, spiderman anchorman fahrenheit.
Advent fragile regarded dreyers = betrayal gripped=20 obsessive fear, witchcraft. Reasonably memory expressed = feb.
Gamefaqs metacritic mpcom tvcom dd = login=20 background. Patient slasher archangel, oxford. Online, stuffmy logoutgt = playing,=20 viewedjust ratedgirl daymore!
Computers whatever taste formats = manuscript unbound.
End, whats benign, devil, path = legitimacy? Wordplay=20 indepth crossword puzzle?
Abundance testament brethren catcher = ryeabout=20 security policies.
Voip centercrm bull corporate guide = awardswhos=20 tmcnet provider directory.
Records venues prime metallic foil = essays noted?=20 Exposure, barry fact thomas ben men pockets crews, within? Episode skies = us=20 exploring reaches. Drops shuts liteapple calls ipod theft costs lab, = phishing.
Courteney, cox elliott, = glover.
Crew prepares building blitz = checks!
Online stuffmy logoutgt playing = viewedjust,=20 ratedgirl daymore.
------=_NextPart_001_0004_01C71D9B.59F010B0-- ------=_NextPart_000_0003_01C71D9B.59F010B0 Content-Type: image/gif; name="twodisc Hollywoods.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c71d92$f82ba8b0$00000000@Sanne> R0lGODlh7AHAAYewAAAABYEAAASNB3qFCQ0AhncCigCKi8u0xb3ltK/L7kcdAFEkAI0XAJwgDLYq DuskAQ1HAC5IADE0DW03B3kxB5M0C8ZIBOQ6AABtAClsAEJbDWpSAoVqDqVWALhSBttcCQZ9ACyL AEqOAG5zAIhyAJdzAL95DNqCAQCRACOcCTWnAGCqAHaUAK2XALytANGfAA6yAyrHAE3KAFqyDXq/ AJy5ALy+AObGAA3iBifnAEPrA1PUAILrAKToB8LZDunYBgUHTBoAMz4NO2EMQH8NM5UAObcHSNkA TQAiRSEgMk0WS1sbTYYVQ58SNcsqN+UYPwBOSiZGPklGMWozPX5LPaZHPbNBP9FMPABXRi5jMzlm QGdgRodXAaxRP8RWS+NhQwCBOSJ+STuHQFmCSYd/OZaOQr6DO+CJPACXPi2cNDanOWKlRnmnPKWb RsuSN+qXRQ3IPhzLOj/ORGLEPHTKTZuxR8XJRdPLOQLoNBHVRDHeTW3ROIrmNZ/UMcLRReveNAEB ei4AeDIBgmALh3YOe5UJcbcDhOwOgwAlhC0YiTQWcmsZfY0lf50jiM0Rf94tjQQ6iRVIc0I0hWRA c35JepgyjMxDeOo4iQNaeRlleztdh1xWg4dii6JXiMptgOVZegB2dBhxfkWDemSMhnJ+jaOHd7xz cel2gwCogimTiDStgWCgd46Tg6WXdLGWdtaTcgDOcya1dznIg1fGhH2xi5O6c7vCjOG3hwLtjhfc fk3ld1vicYTbeqLgfL3Ud+zfdgAAwCQExDIBvlYAtHwLxqsAt8oDs+oGvwofzSMmwUUVwVghyo4c s6gjwr4rvOEbwQBJvhoxvT9LsWFItoVBt5hKy8FNxeREswNsuxVVtUZut2ZjtXJqypRXvcBkvNdk uwCFvCiEw0ByyGSKunGOwq16ybh9xtGBwgCnyR6juz6kvmGfv4ebyZeYtM6ex+ylxAC8yiDFyUS/ vFLDyYa7zqq2wv/1+JSTlol+jfsEAAD/AP//AAIA//EA/wr//PX/8iH5BAD//34ALAAAAADsAcAB Bwj/AGsIHEiwoMGDCBMqXMiwocOHECNKnEjxYbx4AjFWHHiN47WONUAK/OixI8mNKFM69OWLIMuX AlvWkKmyps2bOHPq3Mmzp8+BFy/WCDqRpNGRJpOKRCpy6c+nB1tKlTozZlWWULNq3cq1q9evGIOG 1fjwpNOQBD8mDXmS7detU2lOdUnzrd27ePPqzUo0bESlbNUKRoqWsMmRe3nKrDtz8UvGiSNLnkx5 L9mMlxceLpnWLVPBh9tWTukYq9zRqFOrXq1To+vMDTcDLlyyqdGzrB+arksVa9XcwIMLD07Wr8O1 mz0i5viZ8M0D0GscwEu1cUzfvodr3879pzVrNcAr/xQ61Phx0SBtI0+bnrnN6PDvLr4e1/rv7vjz 63f4/Xt4hsVJlF57BSnVVHO04fYQdNMxONB0edX3m2n37Wfhhfn1B5544XE4HmyaBRbabYWdJY88 JCo4EYQCNRghhdg1BhmGNNaomng4/tfhhv7ZJJpyyQHWEYrXECmPeytC2GB00jVp12OnDTSjjVRW mdiGA2mYZX86qnQbgculRyRHYw5ZA4pHSuRgi0qyGOGEV1Vo5Zx0fsUjQTz61yNOZhWolnOgmYkW imydGNGSLkrXppNPzidlnZBGuhWXWW6ZI5YebnTgQbIddiRyoAmU5oJuspmooonBJOmqrO60p4eU 7v+5pZdojfhnkUUWOtiJaapl6Jlqttgkk4qe2uqxyO73aoc75ijQnbQauFxIJ9760ae1EnjkqA65 eGqbpSYr7rjDUcrsfxxqeVNo2Q52Era5Cobmmb9uy5CbDBorLLn89ntjnjvOKrCP7HZK77W94sqU vfSKyu29BHm7qL8UV6xXupVi/CzGmWramVvuBmommrluy6uoC5oKX7gW2/jByy/XAPMHBMEsc8wD 2TzzzjQLxLPPPM+c8841/2yQ0QrZXHTPSwd9M9FNO/00fxkzCy2eXdZkG8pJkawUmr2inKahDyO0 8kFLtmyl0lBPrTTQNL99NM5yT10Q2zjbLfTQPdf/PTfTcP+NEN55Ly34QrAWpGe6emaN0oCg8kpo rtQi9vVAY3db6prFqr023XvrDXrfhRs+9N2ly00436yfnlDbdg/0i82/1G567Le3jvirPWpcdccV /Qly1+/G2+vYyNvLsEJpT6yv5xgSvrropAOe+0Gql+523m/7nXToU/8iO8ziH4677ugjlKesy+rY e07JORyYkbVSSyjmwCrf0KIscg59jasbXeCoNzjtoQ5wftMZ9xZovYXErHC0W5r4yjfB7hkwgQY0 CI56By32oYtPkBMRrgiVuXjlD1gnXN5ClDQsRv0PgAJUINNAxzepwS53GIybAKPGEBnyzXa1m13Q /x64Q/OlT32M29gHr+aTIQFmciAZ0+ROlkIVHoplkloTsSI1PSLOsG3e4+EBr7e9G9awgYaz4AeC WAPx0W6CbRSiGY8YRsU1Tkt3apwSdXKga5GESAWTHArFNsgXGgRf/cMiDKsHNzWq0SF1y14DfVjH AWLPaHIUCBzJZ7vxefF12qukpQDGOzyZC36QkxyunliyQdaLkIbM17681cI5Te9pEJQkJFOXy0l+ 8nxjvOQX1yjHTsINjpssYjDJqL6qLZGDz/qJp4p0hyGR7H4GydyoqAg9faUNVfH5HCMbiUBdXvJ6 kezlAEOnTmGyrphwxF0QMylHNIqyIZgyZcDy+P8TbHnmDmcyIfJSWBBuvpBY4DKVC6l0S1w2jZkE XGbrHtnIdWbwZqhzY8yAWEyC2E5p9TSiJRmST3TFynE+MdlH7iCPagb0Vw0rWyFjySZhIdSmqKoS 0SRpPV4OkZz2vCDseApUUPbUizurJ8/gWVEy3lNxzeKgHrPC0hMBtKUtJehBqPhKmfZrZbJ0Ev8S pUhDDmeCxoznPCnYyfK1MY5Qed9JUZrSrJqMqw6DaTZRdtCcsrBzw/prWc0aHLRyFK5vdStigfhW rZQUS125a14lJ8iY8vWV3dxcYJnkIHwRNj+MlZ3s1kpaTZr2tJOy2luw2lKA1uCq8hvoCQnpVXL/ JbR/gL3t8z4rHDaGVpNsBG5wE6tYVlGWpVflVmVNRi+9tiyREQvsLBEFXd5qx7fYTSxxiYtWuBa3 TidzLUwl21z5TVZtnVVZQTSbr29a97qndWtb1Rrf7X53TpI9GdkadlmCUNZz1P2rynYr4PeyRr5p Ha5aS5vWVul3vJnDn9gwa7FwOc+mnAVrTQ184NECt7HI9PA84zjiZEHYvMz1r1nD+c1wYnjDWzRw AGY8Gt+SeLHeNSxqP4ysCO8Xwl21YsVkmeEB4xTDLs7PjJfMZBr3ZMk7aTKUJxLa7tYOyhSsQZMV +9uDTNkgUg6AQL48ZieXuckI+bKanYxmMp/Z/5XKk5yUMSePOQ+EyQSBcpjx3GYy69nMb94zoO8s aDGf2c1om/MByAyhPs94ZXwOc0EQPRlKR3nQNlkzphkyXy/TGI5/dvJ9PW3oSZs51KYutaZJTWhV n5rNmJ7yNl2pZVgbus62bvWrS/3mVB/a1WJ2M6ojgugpW7rV0Ak1ZxW15GRPuUGRBnaeNy2ZY+fE 2hsRNrURgmDE1nrKjC0flr2bEDRPm9e1/rav1T3tNOea3b0uNqa1iWtevzveeO51q8Fs613DO9Db Lveg/bztZjM72E4+FZQXjefpOHrfEEcNwaX963NPPN/fNva9FSJvYA8c48gU94y7rclxN1bgE/9H ua+xvfJon1vfEZewqGRNtnrzG+H51ja62W3nYe+b5Td/+bp9nWGGG5pzGn/2w2EOdLykHN84h7rU 0w31pncc4BQfeaevDGgug3vH/KY6zIeOdYj8Od1Pv3o2ybbkBx/p6mf/t9x5TuNc63zuDHm60ImO r2fn1OBSNvqw754avfvc5xGndNKtHuu6+xvc8TRtEL8ccpCPuuxjt7ikmw5wtAM66UFfSNtVCHfH R33vEEc14tVdaNF/vvE7Z3d7jZ7bbzv80Y5nvaRRXxnDm/7n5oa3pnMefNfv/PC/9zaOv33fX3w9 78kXvstfPvzYV7z4dD9+wDOf+cGfPuZT//3/3Tkfc7XzHVHPTluzaf/wVYOfMr4PgDUE/evog176 2+e97jdvZrZqMgEiZ2jGxG6Rh3IYN34f933cd30YN3X6F3oQCHyGZmfvd39zhoDWx3Gvp32xZ3Cd RXtbRHu2Z3S3p4DuJ3EbKIGWkmrfh3we9xDyxn1k9gsAWAMJIFz/ZjszCHZ7d38qSH0JaIA4F4Rz x3KWVnoeh25qV31yt3oNoXfvp25ERoLgVILSAXh2l4ILGBkpBx7DBk3i4YL4p2swSISKB2gJkIY4 yHViZlhLlmXDxWr6lnKEB4UsSIZCZ34aaG8TqIVMqH8+uHQ/aHZEuIUL52y2FzHOJmYiuCaI/0d+ e5F2S+aFNPYdyQd603eAsMeBeDiHfShmCUBjN0hikzdyN8iG2hVHDUhoptaD0eeJFOdusZh6sPeE gXhvF0d2DphxsLiFKrdu1tZww7ZF95coYhiF1ZaAwSdlG0KBGbd4msiJN4d99ad5ajhPABhmE0R/ zrdphFd/n0h2u/eLTRhtjkaNmqeExZeLvCeIvAiOuuaMcsiC+feMAbCITYaP38cioYZ9kLgXelRS H+Q+A5lttbgTN5iQNQiANGiDNNiQQcSQH8ZG/8hh4nI2YYVFniUpvCMr54IpG2SQ0ugTauiQo/iQ NFiDKClfplWRFnmRRVddgHUsjMMl+TRVAP8jkhF4E6OYhgopkW10it1lgzU4jy+5YkmmRdE1WFSS RErUPiYVTXRFGaMoEFU5EBKZkMKVkkfZlWbjQom0W1YCKwEZTdC0T8CDGiVplVqZkCMmlCl5eV5Z I/5QA/5QlztxNg/CYkxJIyfFMe7jO7HikVRpEFpJlFWZhmx1mHNJJ3dZl5DJE7jlV8lykxoUVTl5 LsDRk0TJlleJmCXJmI1JlwLxmHhplz3xgXPyBzXAmgnxWDipIWe5OFNFlQpJELe5lp1pg7zZm6Np JXhpmgbmmgThmn9AnFgDkhuTOKXUMYQpGT6ZmKHJmD4Jmpz5m1Rimo+JmrzFmsd5nK35na3/eRA2 yZyjhJNmWSmjoYbVaZjWuZtY6ZvYKXmpuB2nORD3aVbG6Z3gKRDiCVUmdSlSCTxXU5vraZVYmZig maDwuR/z8KAEAaF2wVbBNYCocZp3yZ2omZ/d6Z8DAZ79CZJkiTXkOZWpcZVryZ6GyZ7ReSHzUAMv +qIwKqNdUaGLpWOqAZnCWZo6SljiyZ/86aHjKZVmaZOXGZJ7JKBqKZ8oWhA9qaLyqR0POqUwOqMQ GqMz+hQhVlwD6A7uQBBfOhk6GpkZup0+6p/E+Z8fOisdGZJkyTEbBFnr+ZPVmZtNep3dEaNTiqVV KhBX2qc8QaHcVRDu8AuFeqijkaHcGZmf//Wd/emhPzqe3smmA6mclRqn6ska0fmkvNmWm9qeeXql egqofYqlNJoTcchRVRamhioQXuqliSGcGMqh0OOo+xmeHzqp/pkpRlqeUSmbApmWkaGbnCqaKYqg UlqlfCqjzGoQNHqqNeF/VQZiwHWoYQqrXxqmeqGo+Kmh//OouSqpkGqrrkmbj3WZmrmCwroXnoqb bOmutxmlwbGsfqqsElqv0HoT82VjNzZPhdpWNQCrAauteFGmdomh+imkuoqrQ/qff2Cky4mWmBmx d6QaLeqb0/mZCKqxw0Glzaqs9WqlpGoTcCharjpB/1o7XuqvA/GqBGsXs8qtCdufC5umQv8amIHZ QXf0puh6ou/aqe0ZtMjasc9aqqIKsn56ryNbEWvlUaOVsnG0sv7qstj6sjDLYbr6qGkKog2rTwHJ T81ypM9pm9IJn5u6sdwxqvgKsqZKqnyKE9gVYgFrWK06t6zqqtc6n15Rs+EZpF0LnupCSr+jWkm6 mdd5uIipHxKqtmtLr0i7pynBpXBoqDamsoaarQHbsi0rsHoLFSAKpMiJnMUpuk+ZOPuUNXjUHfEK tKCarFQ6EKI6qoxrqvkqESNWgJmrfK2Ko+WDua/auVkRukFKs1yrpubiLISrpEgaHCoKpaEpr8Dx uhGatPZaEB6bpbVruziYY3BUqK56slL/G0TXirkQYQzAWxFb27d/W7yFK6ACmTFyuq4H6qTHaiF7 mr3Pqqevy7hMW18hR7es+rt4W7eZK8ANYQwIbL7me74PEboKQbN2tJxgW5NEujjbUayJiyH36rHM Sq+0u7QU0W0lZrevSrmXa8KIOrDZarUCscAtrMAwzMANjKuTWsM0PKSv2SXMaZkGOhwoyrHb0cGw y7bXS70i26zZ2xADWKGXa1oBnLnis7JOTLW5WxAJ/MI1gMAtvMUyvBAOK6n7Ca5HakfIG8EF2cUS Ib1DbK/6G6FFG7IowZKodahxSIpyW8AGPBALrMBZrMV+rMVo/MCOerN9S7r69JGjFDBR/2migZwQ +nu0SRu71PvBa0xlE6lgWxq1LGu53/u92prAgJzFevzHetzICDHIYGyzJBW/bHqTp9Qq2UEZ+bvB axuysjvESmu7TXtymqyyUttG3nvC2AqmLxvDLwzDoSzKLmzKo7u1fKsQc7VEAUqksEwfsRwZ9/un bYu03IyqkrevhkXHbJSt4tvEeGu1oMzHydzHoszMDyyuaEo16vm+zsQqjhIjklG02WzEtDzJ/ty/ qOVb/4pjhwV2VBum6lzKV4zFo+zOCaGmhow4A9rKcnos1VEQ16wXb2y92SzEHF3JVNa0gvrN2oqy wbzC5CuwpHzMDL3HpezQ3gG/jHwQJP+XH49xH1Oi0fs8u4vrz5ALuQDNY+RGilLMquLzB77syZ+c zoCMzFt8xcsM01lRxgvRYEPZHTDhKHEiy9tsy5E8vT2tr/T1Vr77pcdZO2f9Bymr1ipsxe3M1G+9 x6DMzvjxDDVg116ZXVeN1QYRFzmt0WuszXDcxiAduU6LgyvrDkhNuW10nGb9C66prZwbyqQc1XxM EFE9HM+w2XjN2RyWZdo10tuxG1ISJZPxsYH9p24su7m8Eb81lFCbsmxEnGbN1lWczLjNzgvd1N2x 2QJh156N15+1yzdGiviR1VttFaOxzyKbpbb8tt7My8AM2a0ZRIsdtT86qSz80g3txyz/vc6s4du/ 7dvAfdfCTVivzW0Wqh0UgtOnfao/bcSlyrbOHa3/G9qsCdnzhNT/qtaK3bKim9kNrcy6ndDBAdzl Hdx3/dupUQ8OLhkFLd3+xx03fdHLLd+wq7aP/M8ka9xOa91Hvdja6t+K/d8GscwxfNlNvds84Q0u XgMvbhOcreDmfd4LLhn1UAMPnuM6zuN4IccLRtyjfRp/vRdhveEZ/sio3RMJFuLhBroMG+DqrOIK TeU54Q0EEeMxrhLC3dkITt7mPRkPLhA+zhD8wA8HceZqXhBqfuYD4eYCAeeiJT5nPk9t3uZCXQN3 /uZozud6vudpDuh/LuiAfuduruZS/3HmvmDocs7nff7ng47ncj7pfW7oCiHn88DofY6lmp7pjw7p jB7nhS7oQQTndM4P+u0OdX7m/6nYg2zIlE3XKe4t4I0SWA7jAuHit57rXF7j4h3cNo7jDp7jYz7m CNHoou7nyb7scI7sp+Xm82Xq0k3py57s1G4Q1+7skG7tny7qaM4Siq7sgf7oh97t237u5U4Q2r7s HnvmSMzGbg6hjZ7ubP7p9H7upx5PdQ7pv8DqsOqdJq6mmN3HUC3KB4DADYLw+5ISWL7luK7lML7r FDHjYE7jDI7jOp7xZX7p3Y7s987t537YeI5M0F6fHo/m847y5G7u6F7p5q7tzo7nf/9OE+se6SBf 797u8iHP8Zgu6h3ctp5upSm/80Qf8pS+763p5n9Q50vPD47t6jiMygo98Io4HcZg9Sy2Ebre8Lpu EF3v8BHR2eN94zQe7HjB48Pe48Se8dje8W6/8+Wu7RTU5sNV59kF9yqv7nlf7Xqv7DHP8n/f7PbO 8jl/831v86CO5kte743+oO4+3yE79H7+94F++JFuO6zZ5t+p9GEsrmJc4Cx98AhvvqLPKH2ZEBL/ 4l+f66qP6xPh2WPP4F4u3olh7AWB9huP9zh/8oOuEP2O6tte6mjOr7o/9JY+7mue82sO85ae7pJf +c5//HGv8jJq6dAt+BEa70hMpc//n/ijLvOSj/3ECefHyfmjS8Ok69QIf/C6zSBXb/r+0xC33vrz //Bbz/obQfsL3uVmvxdpDxA1BAqsV6+GQYMDBfLjp7AGQ4cQISqUyLChQ4oXIf6q8evXxo4hF14c WDHjw4YTMaJkWZKky5UqYaKUKTOiRostb060yG9ejZ9BdZ4c2jKo0HlJa740ufLk0pFR/9SYyvDP VZRYFU4VONWrU4HGDhwQa6yGMbRmxY4dW+OA27Zvwc71VteuQG816uLVazfvXLDPajwTLFhgYYWE AS9m3NhpQcgDIxe8WfnpS5ZNMX7syc8jR85gbWrOjNMpT5I2i0a13JNoTJykXaJm/yg0Y1KguDtj nvgTKEaoMFUDT8k0tkWuVyFqxZq8q0OuGNGeVTu2rECycrHD3e74r8K9evmG5+t4ZWHEig8PPmzY /Hv4kglSRngwoeXXKvWbXo3yc2iOWApQJNZ0Qq3A4fYrML/iiJvtNQdHapA4iOZxzcKGdMsQwuDm Go0/1aBScKjlpFKOpOie6ypFjMgSi7rp0JJLO7fgYqvGxfK6Szy8/tprR/G+c4ww9dxbbzD14lPy vYQmI0i0zmb7MCcEMROQI4ZA8+8zAiWcMjXjIoxqNzCpJNPADsXM6cyogqrwp91+S0opn2Za8DQr XfPSzChpopLEi6riJ7kSk/OqOf+tWuTOxbi2uxG7A3CzLcce+wJvpe/Ie8+w9NBjb0lQHatPIcpI DfVUgf7jMtVVUXX1VVidOso3h3ATaNZbY9W1sa+oSrG5rb4CdiW23mqrxhmNrXHOeSL9yVlaMS2v xx951DFTTc1LMrH2jNz11FIhE/egbx3ziNVUQ9Kyy3LbdRcwSXO7dc5cfbM32vfeEUjfd8FyjiqA fT3U14GGBexGZRedl9ncjprXKR0xjbivTEH19Mj1tu2XSXLtQ6i+UjferKP/BgpwXZFTbvdejGz9 TU6H8XXsHZr5rVnlggVekblgr2KR2IGSPVbZsZpNyljfoHUYvPD8utRHiUPtdCD/jXFmbFT7OrZ6 rnPVPXlrsFGldVJ5bWVZXlhp3npgn33GyO1ef1YoLqIddctouIxu9uVcIZ74Wh81vdZSJb1VzNuw Afs468UTdwi0AVF2fHL4bLO33oajdZlv826+ee2VDDY0Z2KNTVbhYu9mNum9ofWbYoondijibAtn DzHKFSd1XKwBu6OGO35vd9Wuczd+MYYnvbzvzEHltwaboZ/8VxYPTXSuGR3Kvmi9l503UhzlnJ3a 2islT8jj+w053PnmCh749+FPf/7EL09efHzppVf8fKP/PHFEAcxQbcOejU6nHaT1zTZy2VvZooW+ u/wocJZqGv3eNaomyQcsd5BE/wd/90EOdrCDAhnhQEqIkROaUBIKEWEKU0jCFbbwhQ6R4QlruBIZ snCFKoThDW8Ilhm6sIVC6SCzipibI44weTKb2b4GojarXa9tvSIdYxplt2U9S38xaxb4BvJA8w3k fIJDnwXbBTL5hMwpIZSE8H5XwhDWwIY7dIoQVUhHEcIQhTHEIx33qEM9BrKHdxTkHHHYRyC+sIR5 TIoIf3LEebTwN0mUhKQ0x8SV1Ox5NnteFAM2wOcM7GDICppTwJc8ZxVNdZYU43isVS3CtbKMZtwV 7560wTiO8I1tVMguBZnIXypyh0HkIw/r6MdFItKYxkwmIP/4SxrmkZl+jGQfH/8pzSI2spKrQxsm MaIvTf4PgNYToMDkZkrT4ehY2znaWxgmp1MCxmkVhBq1YknLbzXOPCPUpRz9KDx++hGY/lwmIIlJ UGg6M5CGTChBAxrNQxYUooZMIW6a6c9sKrGaLONmvp4IvU6CbYoEU1L25haXZy3qXgj8YsOYNi3B iXFws8QnrOijNVzCMI4CCaHweCrJxgC1oQ+dqDIPmcNCGtWg0tShD5VaVB6e8CgZrSRGV7hRbSrE ZZtjjNq8GlLHTfGcByPa0G4UL+6x7mirfGd5JJit81Wqpsb7YEB9ysY+znAuwozoQS96TGf+FaFF Pegz9TpNPVb0mondZhGzWU3/l0bWm98EZ2XBOtfFCK1R7gwKAl12Sv3xb3wzpSDhaIpZq4Fwju/7 IEKJyhi+/tGvQgXsUpk61GLGNpq3jShjB0urOVLyiHq8H/M6B0XUOoZu3VluSh2oNFUiRWZOC2Ms y5dcsAWvhjuMn04Fu1eB6vW1UR2mQCG61GCa16HlVWhg1VtQSUp1TpCUZDUfC9l7FRe77UIYjWzk vd+kcm9dXBhSMAIkbM1zv5R7nwd9Gby7vvaw522va80r4fcO1rfpPS9DNbzMCQvxohat6jWpmk3O 8a+tC95V3RK2Tu6l1VkwEy1jaFddFicOwg5WYU936UuJ9raphOSwhg9rRyPn/5XISBYvMt8rzPIq eb6QtK+8lPgwLOf4Wy8mZbEiBVp2Ko1s8qRukE6rZZXFsbW6ROqHJ9xQq164zbptqlDp3GY389Gp FK5wkh05K6wCpaIl5GiK0RyroRkQae2ckxfxtjSugkVIZz50mkEIQvm1FsKV5jTMxma2eLV0i1+c bKdDlTBI9e2UReNsgY1r6ppqWn48ZS1PaQ1rLSuP1JJ9mP1KjeuShs9RyTKao++nOWBj1o3dhd+y mZ3sBXMT1FqltqdDDe1TmW652tEid+plyV9jm661jp9PgXduced6f/l7Gdmkm25XmbSU9eKs/SIL b3y60SG1Hsiz8Y1Ps5Utxf/r9vS/UeXf/ubtWdGFdLgNHrZyo7vZD492/lbs7tBS/NRzY66vN+dw jUNc4pc2d8hr2nAFhhbcJo/3OtV5N4EbmuXHi/hd/T1zM+LKpZ8m9ZhxvquA/9yMmsa00FFrOb51 VOZGZ/rMW9t0zF5y5/uDetWtfnX6cXF1gMZ6173+dZy9095gJ3vZzf4tA0f67Gtne9vd/na4x13u c6d73e1+d7znXe9753vf/f53wAde8IMnfOENf3jEJ17xi2d84x3/eMhHXvKTp3zlLX95zGde85vn fOc9/3nQh170h7bFQEpfg9OPXvV/t0XrUV/61Kd+9YJPQA0SUPvMx14hrp//vd9vPxDc497xrde9 QHh/fNT3fu+3/33tnS/8xhPf9MQ/fex5z/hrXEPywm8+5F3//dcbP/zUpz7is699h2gf/YkPvu1/ b3v4K776sE+++GFv/eTLXvDqF0j2B3L+9TM87nO/4Hu/xEEAnJs/8rs/+zu+6xu89Ts/jFA/CTw8 A+Q+6FMZBBSIDayBDny4+/s+8Cu+Edw9COQ/9AvA9BNA+Ou+5stAkUEAGfxAlqMHW7DB+svBHNS9 +duYQziEU/lBjBDCufK//lMICqyBADTCwmM+4Is/q5FBD+TAgZBCxwEALMTCjZG+GzQ++rs+B6w/ W/hB/fsWIlSIM6yBNBxC/yB0CCJcw1j5QThsDCZUwhTsP/+7wyMUCGf4O+cDvgGEQXf5QASUwkKc QrDRQoFQxHLBQfKzQfozPS8Uv0kkw36BwzScw4HAxDa8xE58DxS8wwhUQjusw2voQz6sAWdAxby7 QIcwwH6ZQYwwRETcGkZ0iCxkxFwEgBrIwkXcxYEARlvYRV7sRQAoPSx0vWSUvvCTw090xk10xjaU RoGgRjW0RjR8xmmExmrcRm4UQmnsxHDsRk10Q2+Uw2hEx/TLQ6eQQCNkxVVUxT5kxVZ0QvcTCHvc GEIsxEOkQlssRlwESEX0RYLkRV80RoxIxiy8QYUsxmREvYd8Penjxmvsxv+KtEhzvEZx3Eg2zMaL vEhw5MiKVMeQjEaQ/ESneEOV/MgJrMBSdElS5D9n0L5VrMmBiEds6wfKeUFBHMRD5EcPNEQaTJlb DEaBdEik/EWEVMqAHEZebL2HzEVJlMjrW0mW/EhOZMkz5MRx3MptxMqv9EqwvErAsMqRRMn/O0Ij XEJ2PMWZjEl6lMe41LJ+0Mm6FIi7zB3m68ld2cAZlEWH+Ml/XAldTMql1MLC/MVcpIdktMGo9MUQ nD7YM8tvFMmu1EaTzEiTFMuzzMyStEjOpMi5oEwgLMe23MM8TM15pECb5MOanMsFu8u8lE2dDBu+ bBfAtMK/3E0rtJqiZMr/wzRMxDzKpTRGp6wBemDMp8zFEgRDjVRHjxRL6cRMjPTIzbTM0sTOseTM zBzNrwRNtFTBmCRFPEzLVaRJmFRFhYDN5KpNvMxLvHw43tRN+uTNRCTOxAxOpUzMgcRC5SQ+LYRK gITIYwRDMjy9z0xQBc1O64TO7uxMjFxQ8LxOcjzJ6tTM6exI1ETCJLTD1axJt5xH9WzNHKtLuzzR GqhNFXVPbPPLoORHGAXKxAFGxczP/jRGqazRhgTQYyTQ4wvQ8iPC0lNJr6xMaFzDcdTMCKVIIiVJ Bl1SIxVJc/zMk3RSAHRHFWTNUzxFtVxPnFTP2ExRMR3T+JxNfIPRF/XL//kcygX7TadoPUgUQUZE vkiUvQf0zkorx3KMjyQ0xfRURbdMzfV7zUOTTTI1UUQVU7uENqGkwjWdz0Nz0zf1wtObUzB8QBF0 jD1FLU3cVCVhx7Qcz/KcyRTMPlQkUfacq9lk0fhUCBMVt59U06CcwjWN1AGd1Ek0vQCdSi6kVEoE C2xcsGAVmQhkwitNvz70v5mMx3lk1hJNVBZ1TxQlU1PbR6G0z96c1X+rvvAzwUmkU/vbOywtT1BF QUAFUSYU0VPdr0Vt15VY1BSFz04bSlp81Nxk02SLxG79Vv37Qqr0u1AURT+VR/X7UhFNRXZFVGk1 1FVV1Gp1VFmFWBlV0/9shbYS3Nd9jczCW0tz5VglBFHylMtmpUvaXNFDPVF55bSJ9Ud/jNhsxdea klTCfEouZMb861Z9LUO8C0Uk3FBSjMu3BFPXFNr2fFV4Ndn3hFdYQ9O/5ECYfdFaJEoajQ+ZTcgC Bb/dc71/+Ifyq4Gt/drS21qFEFuB+FqyXbtj5dgl7L/z3NIv9VIWc9eFTdqBkNZ5rdgqhFhtDcyo 3ZhbrNq5AFyFUESbzVWv/Ycc3FqtRdyzPdyyRdzHbbtSLUXKtUO4XFaavMl1jVtDpdtWjdf3XNqW ddTAFMxaFRk3vVEcHU6kzNHVJU6l7MHWM9vTO9vUa1yxbdy34z/LbUn/jk1Wp0hVzHrVMV1RFa1b VgU2+1SIRq1CipXamWXKgjRI6k1KG4Xd8XtcsrUFxdU/3GVcyJU7Yx1fPETBg03Ft+VcV61b0G1V 4lVZbXVRNHXeWsxNlSFGo7ze/cRP2CVcrJU+su1e3dVeswXfu1PbtqxDhyBUTltY43XXz+2X5cFN GqxgqGXZfpzR1u1f6+VfowTO6RPDAIbcEc7d8HXcEj5hyV3b8hXPnDxe0FVY9t2YoFM7V6lgfI1R wMzbp32X/tRfhORPDjZBBpzdAka973XcgTDhsVVhyaVcgf3TZIPgpJXX5I2VMZM2XZFfWs3g3cxb vYXeDwZh1R3ODwbi/+KkPttVXCVG4RMe4SV24hXGUgp0YXEz0+PF45VhHgNbule5Vqd1WlmUXxeV WtctTv0M4qldZOwVv+414jg22zZu4wKWY7erQD2kuETFiKN1ly2iOsyBFd0k3frM4C5OH8FVvrhj WEW9Yl1ZuXZzN1F23kEeZEQk5EKenFQ2PD+YPBhGXglOunWLFxtekli15X0k5R7GmV0+PD94Zl9O 2XJRORpjN5BrjFxmXmu94B1WZVR55l6uAXAWiHH2ZsaAZVyRumtmjOWd1Ril32U2Z/OA5nHuZWiW 58awOEOLGT8GFZelRVodXXw+FXomZ3K254E+5xq7t5ib5VtuWUDe2//Dy4d8oByKdgqEFueMRuhw 9uaLbhlr62NizrJY6cCm5dtA1uCD7JfUnVqrjZWPHgiKnmmnmOmPtmmaxumYxoibtmlxrgGc/umg lumY3mmF8GmaFoii9mmgHuqmduqmdgidVuqpluqcXuqaZuqnJuqn1mqi9mqqPuqK5mqsDmuzXon8 2iqBW7GSvmWYjWcfbuR2aekxfpepLmux5mqrjurF6Gmyzodwpmg/EOxnFuyovmij3uutNmusLuvE 1uuzPuyxnouenuzHduzGHmtRgmyj7uyx9uuz3mmjvqQJnraFLul6rV+89c1bBU7Wfe0Nju3YDsgz ztEfvu0BdVOvxmv/zp5sxvZtsLjsijZsyYZmwkbs4QZuxWZq5F4JzM5q3obs4P7spE5sz+7qsKbo 6OAZvg7tpP5t75buxEa6V2spkt7iijVlXW7t4mTd/K1r905k2t7f3Kbe+W5v9t5ty1bu6K7s71Zs ngbszCbn407ux85r7JZs597vyBbr6G7wBadq0Ebwv+7pP/hoYHEb0d5vz8br/lbu0k5ntNHApl3t +4ze/R3c+q7tMW5p275VM1bxuqbsDZfu8LZxHO9uBDfswRbwiu5lwu5qA8/q7E5uHf/q79Zp6vZu 5q7q5TZy6wbu5kbuC6/qr6hxvr7u3rbx8QY0UFagfjY4uk7xGSdG//uWXvb+zaKM8fw9ZBqf8CgX b+WG8COnaSDf7x4XasDuaOwW7t9u7gDXcT8/8r/u6yVPcAovcgk3cmEB8Cynbl/whRqQdCzvbi03 b0xnt4aeuTFXZBmfcdc2zPsGdTYHYceYcgYH8AfP8Uq/cz3P88L+8UIfdP8m9EdndajO6wPfceqO c13v9Xyo8hXZCqrAcien9HyQ9Pjo8qBb64VhOiFWTET+Ww9GcxT/dBbH9vyMcEC/dUtP9RtXdf7+ 8R7Pc3G+7m7n9a8O7+d29HRPdyL/9jlv96cW9mE5lOeOdF+g6Eif9Er/cJAOZWvDOkaWSmoPyIPc 9pU2dUQOzoQ/ZP/ddmqJ5/AHz3VeH+qh7nE77+15v+p1X/RDL/KgNnaMd3Ikl3fo9nDkHmp8n3hJ R/ZJh/lJ/3Y5nwv9WpowT+gIT5xd/+mN/ukFqxrjyXC3CRgVwYh+7/eZf3mmZ/pTn/NaKbCxyXmd D3TH6fmBKGegnysiwR0Lgpvt/qTrEQhlf/mBUPaZj3mybwysz5xQw3lgswG5l/vk6nqhw/pwtueC 5vokQRzKiZvNNhiFKHu1V3vC1/elp3HHCLh11jIbGIjHf3wLwp2+9/uqy3s+xyxOoSVyGh2CuR59 d3rRX3u0V/pXKWZom3uBUH0zIpJPQZLXnz30sHvL/3uw/xkWMXv/3Vd6s1/6w4+7yK8ByZd84zES r7d75fN62K99AAqdnaGitY9+3k/8wzd9uAv+4Y+VZj4P2KcaJFF+WOlYhj80UC3+jBGIb/iG+Wn0 z4d+h0B8sk/6+E96tAd+4V/91af7wHVzp9h+hAcIAAIFPqtR41nBgwkTGmzo8KFDgQ2vXZtosCJF iREHAoBokGNHjyJHkiwJESNFihdNsmzJEuFBhd++OaTp8ibOhn92Gvyj0ydQh76GehxKtKEvg0mT 1jCa8ynUqFKf2rBRo+pNjTW0juSKM6FWmBALMsQpMOVFlWivgeyo1evWkHGn0rVYsYZKvHnr0iVb gybMmTX5EvZZ/8Pw4aBCmy5lrBQpZKJOCVOubBmi1YaZrWZmCfcjSNADQZMWqREsx4Oh46ZmrTE0 WwB3J3LEOLd0V7mXW95Vq9f3yt0tyX5D+IzmzOTIhT9FjFjkUqdGJ0Nual0pU+bat7PcbJBzZ5Of 3+om/Vo32YIEjcdU75YgbonkS1c8qzbjaIzzSX7m7rH3Xnj9FqB/BgEG03F/CWaTTQW29NxIkk13 lIREnXPhUQ5q6GBVWGl2VXi5iSafXHCdxxVD7hnEHkwEnXbbXOTht1JKNQo4EEr7QdTahg+hJCCN a/XYkGB/DaacgQoOORVTTTrm2DlIXdjUOdkteSVlWIEHYog79v8H44mjueZQis9ItFBbZnaEWkMk glRfRzbuNVtqsd31JW49AtibQz/yqeGCBjLI4JENYumSZEhlt1SUNVR5IaQGNXoopVF1dmmXXpY0 3348KmScmn7BF6NunOqmn2w0pkXjWSSqhCeMG852X1qz/oZlkUUKSmSglbLUmGPZVenLo9JNSqyv yeLE2XcdZtpmeR6deJuYsSq0opobuQdAtjFNK+Ncr8rGZ0quahRbaTrKSu6e9wE323bLKYjkrrwm qSxJTgJ73ZRJQVpslJPiO7BH3n131aZtmbaawnl+ahx8ZKV5JmqtrYZXfvbZ5ppEcFZLXrVLwisg WnrdOnK8SOr/mty8RvZKcFHWNebvv1RG2i/MORf8kIcbesXiQmJ9uuLQmp5U8rsbYxySjToHlxfS Fh2N8m70DqYkvS87fZ1HURL7KKTIEovslFvnrOWz28FaNHvXPlSWw7bZ+qPJF3nVNMw12jqRu+8O aejVhBpp9kPRMdrv14zyKzDhBDM75Gdwp5ee29hCGzLJKBG4quYE6p133eTe6iPdKd8r6ILKISdv 49hBKSmVyD42rKOt204pgrnHtDvlN0Ft8qyfB3cSkAR7Xveq/xWo+qAuz/sy4FtHN7u/jEUa3b+M 3769hn6B+jC2cLukNN+lNw3c1pqrerKQ/i2X6/tJsswy9/pW/wnR2FPqXzb3/ffoV3tyB0CS+Glq fEse524XPCAVsE/Lqxev3qerlvlPUvuTnVIEFqkKclA4kwOV0AKYEwAdUGrlO9rwlLUx9A1IbuuL 1+CU5DyPTFA78qjBDW9omfzxj2awcxT/OijEy5Sld7wbn2+U1i6S+ah45BtY+4IHtbVQrWr1Wh3q dmU1y+iwIfLIYWVk15iaBbF22hsiGvtCtLYtxHclO6D6RiakN3rki1881BQ/F7VaVfEyhGreveSl NcKA0SE6vCMOuyiVRgXMZo2sXUPOmMZJSqWNCBrh+fiYOT7ukYEQUSQi9eTCFbKwR4LU2gRrSBk7 GgSRduxiIf+nUraA6c+CDpEkJXP5lEtCRYp6I2HoNoe0uyjSi8WUFQHllMIHEqmZqGuQKuvCylZO k5pepAwjLfjIH+qym5WSoif3lLx2zSaWOGzlOUWmKjnaZUOCLNTzoseXUBoylK5Epywntb9tltGb /nRQHp8GRyaqD3hoYeUdjzmkOf5uildK5QwHxzpCFhKWn0wkPSuzwWz+s6PIFB37PHmy4hkSna/E qEILpEe79BFQ9BMc1qIpFYTSlJqvPGQi60JLSO6Pmx79qXbm1MKGtpCkTLxmPVGKRwbKcXPunF+u JLobUN4zp+m0p07NCMRtArWr2xllOP8ktQCh754JTacKRZr/LAnKb6rHrCgsY5nRqPDvZrj0Kl4r w0KhdtKFJFVoSpeKPHxBVDgnTehcLXrOama1lnl97GWEN6Am0nGFdavpNBkL2ZyZE6smzeFcNyta 0GVSdJ0brFFRela0jhZmicUpRvFpUta2trbfHGpB+Uq30l31mrC1bbJAm9NDHtaqiA0scJOrIVrt toTK/N1DwChd2ioXS4w152JLetbQVre762LqJpvaR1eu1ruHAi1C0Urc7FKXLggwyHvNK1+RKDNI vGVpS0s6X0qtN7afFW4xuZsTBBC4BvHdL4J1m0kHphbBOXvHYmFbUfXe9KRQIfB7M2xgB3OYfG/M Y345nCwI/+PwHV+EMIlVa0329vYpGNbwgTN84PnaosY1roEtkos3pgozxCJeUoobYuIavMPEcfXt it0rYw3Dt8AbNm+OG5LjKEdZx+UTa4N/PLAUQ/iQRY4wmGfb3ptg+MkNkbGZlTtlKtsYx1VWbtT2 puUHF7nOJC7yDb9sz/JO2MVLRvOf01zbGxO6ylSWr4/nvOUg27mLRoYrYocbFUDHt8wvNvCMRztl g2x604r+tNNQzGUiGxnFNvUtepFbkkpjWiSZTu6a3fyQN4P6UDe4Qa1FbeovC1kevLamRcuLEyaz 2tIzfvVjbXxjHDO72Zyuta0NgusaTFvLd/4yl31N5BYbk/8wr3YykwWt6Vm32dnQvhKub31rh1Qb wXU2yLu3beIu47m4SZaKpZvskBiLO9kl6fS5ba1uaVNbxNf+9bu7HNvDoncqBX5xpcHdamQnW9ls JnfAsaTudLd7v3beNsgTXuKRqPrCD3/4k9EsWk/L2tOdpnXGt7PuhnCc2h2Xb7xNDXJ4K1y7lwE3 xOF7Zop7FeDKZvahY76hjVd74DfHebzlvfMUC5gvxz55mp28cpYbmuVK17i0nz5fXX/84BoKeg28 IfSUDxrmUn5zuQm2Nl2GpDy6mfnTxS6t7fjDIP7wR7RygjnKkD3nO3dJ4E3jkUp7AwGN9wbkI9+m j9iu7pb/Sbqzjx6Vtsw9K4kX/MWmwpXQC57yW3lIefD+kYEjfu/iMcnfaxB7wH+k76WHSrQsBu+P kNhTWXE96l3t+MY/ufEEtvzpNYT81if/81Kx+NE1L3rnS6Xz4ikR9a+vI+t3xfSThwjrw/573I+k 73+ffd8BcH7bm2XzwZ+8XIqMfPk/JfvfX7zjm2z8tPN/+T4jf/LxhdcRGkS4nVmUCvaNCPaBjJgw TN1R3+g94Mf43kYsDH/cH/L53+k1YFzgGgDcwHssoFeE4PeRXmiEifkxDO1NIOakhu6NRwAGnt1t RZBdoPe5BWuU4GiQoEGo3ekdH6Z1hDcIoQZu4ANejghS/97gGeHoYaDpFWFUHJrmxRphRCC0gMl7 mEcCol4WWovRaOEVzl1/4EmJlOATciH8lQqYBCAbruEGRsSO4EbsKaHsyZ76reAdvuH9mWEadl8Z xiEc2t8N9uEZ2l0Zqh3kCeFWQF7zpV0Rngcd7qES/iEctmEM8iEU5oShudkUNpsBHmAFgqEoXqHD UMsSomEYJqAYymD24SAOnmEbquEMymIl7qHlqeH76YbtpR/gzV5H9OIvph8b5p736SHwQSHnWeIF umIx3uL7UZ4POuIQLuIfPqIT4mIg1iIfBh8zwqIgmgTmcVrcSd/mIWAqOiAkpgs6tqI5JuMqcqH9 MWM1Fv/jMMZiPWJjM0YiPTbiRuzgHNZdL6ZgPeZiNioeLObgLF7OMuohLr6iLUYeIrrFNJaI2lnj IDbMCWrjQWajQ2ZgXRQaJ76dJy4bTuCUFY6itHQhqZAiBX7hSqJiwoSiZ7zhPNoj/HFjQdJjQw5k JZYK+73i3znjTUoiP+qjl3BgThqlMt7kK+7kDLZJNH7EEE5k/0mjJVKiQ9oiT24jR15iUdLFsr1c 0pFkS8hVrHyLKh4hWooGKZYiFsaHSvLHFsLkM+6kTSplVnbkUxZiW25jQAIeDgblHaofLZai/2Wl Rh6mTdolIHolX2ojADCiD06jVEZeZE7lVV5jTsqHRn7/ZS3a5TeCI9LJ2mgS4E0cmbVgJI+s5jqq y3iE3sWQngKGoMUkHiXyoyEi5VA+IWf241uwJSvqoj8CJmHa4V/SHkI2pu4B3w26YF0up3JqZfPt IBxO5g1C5GVGZmYO4pgA51Y2Z3Ri4uWtGRVSoUukl1VBjjkmC/c5SGh25kPsokOYXx3WJ33K3hzC p6+8Z11ApHX2YNpF5WaJZUiSZ0mCkn/5zHruJ38WSIMuZXziJ36a3302RH7WJ1Hup4b8p+RZp+S1 FkiGaNyVJZ+VnHC052a1pFxa3/lJqIVCBIXWp4p6FSICqI3y341qGvSF4yeWBHZ9ne2s331eaIu6 aJEm/5d/Amg01mh1YV7XnaeKmSiQDgz6+d3sGamVmheH1qiH4mjbQZ84kuOBVt2Uwgz7CWkdEmmV VleHfmgPCiiskRtIRsWPts43Pqhl4Gn9SYV8yugcst987oaeDgwiSmZD+CA+Zug/udxomtt5Sukx ViEAtmJdEOP4DWpLPOiZCqNxFmmVAmql7iOEUgal4kSh4mhUCuUzdhVJAlyPYCpzjt9M0oWlMp9/ DKovnl9I9Gmagiqtimr/dKiSSueq5pWr9qj2SeAthglNvkZPDp4LLuFyLmu65OCquuJvFmt3cgxv gkxKOisLmkhtgqtApB91uobtEeYRjsgkOt8JZqu0cv9guLqetDIhEhqhI4arM34MuyraXuLrQapk Xn7nV/6rN66rwF6rG9bq3jnlZi5jGSZqYU5iugblTaYraJirUSZs9y2sY+bjbyaqMRJjyMLkxDYi vBKsg/3rwF7iybZsTyYmIC5fxMrsbnrmqLbswAriztrsxgYgcv7iViBnp2LlPernRqpqYxoj05Ls Qt7sVursQMLsj7Hs1N7szsqmYnamR16kzzbtPuaec5qhagZnb/4sZHIMUAZkMKprahBtxGakoiZt ty5t1lKgBDZsUg6j3D5mIcrmyiosY/Ys1M7s13qjZkriy3asVjos44JsUlotw6rf0CphhTomYqos V2r/oOTu7dJm5skSrOP6Lah17jYSboxwbT6qblHWrOKGYcwWqyqy5NHqJOzu5gje7sbyouX63S8a 7eIq49Z2pOBGbhze5s9aLe4qLfMCq3yN69ambkP2poq6iVwkwL3i5jW2JHXG5lF+i3dOp7ceJdgm JzyK79YC5tASp9F26/AuDGi+prPqIAxaK07SL2KyZlNyq/vObZluRwIEMOR4U4Neqa/+KvdgL/bW QAAv8P/qTKG66VMoMAUzsIMSML7A6pAIsAU3hAA78ANXyqlOpmTCKUuAcAO7JyXNqJZVsAencAhT CgkHKKoyYk4ocAcTzB3UwA7fwQ7H8G7QAz3EAz0Y/0Q8kAQHG0QDfzAIA/GVdGkNR6UJjwQHJ7Gv +DAWG8QPO3FdxAMR1wARE7EQF7EQe7BDVHEF47ASNzEXa0eSHiqTRnFLJDEKJ4sPazEP33EbS8UY j7EXC/ER10AZH3EKL3Ehd/AS7zECt8R/2ihE8p8Nm8Qhs3Fl8OcP3/El8/DAaHBD/EINeLInu5/o tZ8RC3IgF/EXf3EZg7EXxwMTV/Ea5zAMb/JPHIZXuSNzMqkNj7AJT7FHLLAhU7JBZurjOoQeZ3EW X8aDIuNNhHInO/MvOLOsijLzHfER+3FD+HEY+/EQw7ISM7AhWzAb4+mgdq1D8AReiSxElHCAzjCq Ov+EBFOxA6uxMt8EMuuxFm9xpWRiS0RzKIPyMxtENJNy9RG0IGNzGaMyGB/0QQ8xRMxzLOfwN4/q pvAF8hlGUKDzT8kivApEBOcrs0qjRAzhsiZhAvAg8orvt4Z0swLAHYPEMW9rFzKgAtKhvsKjmzAl A3bEL4TMQAt0d/Ig/zau/a7jJHLja4RxPACAEINEUw9EAnixA3ME9lL1Vpy0QATwu/brmERrrc4j SPzBQOwEWaezTN4iojLpZX5fIuYraFSkGwai64Lu62LtUX/EHbj0S/cwvSLs51Ir2j4r2c51T/e0 QPP0J4PyT38ywJZv48412L6mGAPAUg/xEFN2R5T/sVsMsStTdgB3tjifNA5noVZXtVsybcDWpXiC iWLY8kbXwAGsLg4uaYAqojRGJDQuYmDbNWorZdqObtPiM1+3LlFiI+puJ3C7hWIDgGF3cmIrtj8f dnPvdu0mr5Nl7kdY81JvhRcLMlNndnYzdQIUsXhLdUgsMABM9VW3iWlDaObyM016Zd0FRUdgNIT4 0wHIRX7H7kAkqVxUZKFaXlujbd+ibF9P7tWWSl5r8unpM8M44VAvrsi+rywCNE+Pxj8DdTSDxHQ7 NuTuJgIAQIgXeENstyljtkE0NT10RHd/t1Nbs2iLc3qjt2grsDnX9FfDYDdqry3Xd0941AHEdgDm /7eQN2I0aiduA+hlwjVmuqzxAnddt8k8GMQ8SK1cLLhL57FeazmD0yxvJyRvxy7p4mAoM7dAFzZj R/dW/PRxmy4dxtcrPpxtGnFlM7Ugczd4b8WKGzE9BHCfg3FHqDc4uwUH33jobmdX1iQAAIVY68SP 43eQE7mQA0CROyNc4+haD7gjWqVuR7bufuzD1sA8TDkAjHrqkm1E5PVLh8RLa/L8Orl5HO9mWmpy xyCZNzdzZ7iZ9zRzT2zuxvpNvpdAhPiLifico/J3n/h3T/ay/zFTc/Z2p3CgV3WNU3vBfnpqh6c3 Mvqiu7ZG4/dWRHq4T3rdtnMi9rdrIGptMyJtLv+gY8+5tY76lJvvag6jDw/EgjfEvVMvhHfvCz4r docM83ryQBg2r+f66UEzaxj29L43ZzY8+n5Eph0xZVv2sw/Eij/1Zq84xoNzVC81VI/JScNhVY8g 9U6g/ao2BgoEWTe6c3SUuBtEkMu8SHBo2pmDOaidOdTAzpdwJEsxRVd0S5g6lYu60U850ZcEJu8w qzP4ANeFrgP0P5t5mqc5dEuz1Z2c1mFdiWfzNa9yQjv0ZUe1EPv5IIvEPKcxPfuKfdeyN8U23Md8 kRc5HJs7z3sDzuf8zivpCLez/wq9SSD9vIt60hf94JPE0peHPivfVEB3Yu96YiefNA/0Ykc+ZUT/ 3Nb3W4kHMhgDchGnuNhnthhbdhFH9ULLMg6n/kTjCzrfty7BPc3D9tx7hC7zfN7jfeTh/CO36aEG fTGLhLwL/kMIv9F7BuYsPnewcD8/fsEr9nOLxOTvxrepXJl1vTWPcYqbsmZXixiPd5+7slSDs8eP vwvnjOu/PWzLfuzTPe3XPs7bPt7z/I3Wvi8TBtGb+rzLe/EXfUsgMxoBxK8avwgSrDHw4EGDCgUq TDhw4UOJEylWRFADwcWDGjE+jFfj40eQIenFK0kP5Mga9BKYNNmS5UGRCRLUoHmz5sGcNWlW9PkT aFChQ4kWNXqU4oEaB5g+VMpU6URvB715M2du/6rVq1drmHs4tUbVrGHBIjU7L+E8tDXQqlVrMKJZ uXPpQkTYEC7EuA4LLuxbN+FFwR0DD/YYD/FHeosXJzS5sqTJkwkaP0Ys02bCnDY3cwb8GXRo0Uef Nl1quqLYg1erUvXalXVYslRltx4tca3bh23Zvh24tuBt4aAbPsTLEGHyiceLA84oMaNgjRxDimyc MjFKlJAZM5acWCTnm555ZjY/HH169UCjRgVwGqrPsmG5du2qFet8sPvV51ab9qC2gvsNLeYAey8o BCdSECgGzRIIQoYAgLC4CB1KjsIEAXDQp+kwQjC66CgKbyUAsusORcZAWoyyxDbrrKeedFqPxv8a a1QKQQCgQo2iqRg0BwCsHtqQyNlsDPC/ANlKC7h5KKxwIA6RknLBiqisEqm+4Ipowl8UrBBK5Jqj SEoqpRMMABENGxEzAFD67rvuKGtsMcRi2qkinI7ck8/RdDzgvfh+quo9q6wKkitvCgVr0dZs6w9A JNn6RcACg4uwS7quHNLKoTYFKq+EgssUTFH5MrVBMjscDIE0CZsovMsge0+7Wt9cSTKWUJxRp856 7RPYYDUl8r0iDyL2qxoAUE3R+oCcL1nalEV22g2PTShHY4stttr/tlXLWoKIdRKAebQ1Flttq00X XXatVfZYddGlFl6J1MUW3iK9rBbCCZUVl0j/gbaNN9Mhz32X4G0RRjZNIi9S+DJkSzKxWjcnJpYe N00CoCZdyxtPovKEHZnkBOPFl0EGFW0NqyDFeta2rPi7FmVOFeQW5ZsRNBfccs31eUJ/2Sp3Q4P8 9XfMnGvGl1Omcb52YSwdvLleqKl+10txtRb636K1jlK5lGm2d+x8N/owzYwGhjoxZTeOx+LF3NRY 7oxBSsDEk1jSkyKRS/4bcJrFFnvIR11OlNhlZTOyarOdrnfwpgV3C0EvzbUr6OTe2/enpx0vu/Ec Qx+d7MZNj1whzzc/+l+EMu9X1OYIL7Pspx+2eUi4wTMRbrcZm7s7jYFfMR49ZeTV18CVF1b0/5zp HZtQR8XaT3FHmYa6aZwTV31IcJd8Dy2iEzcXrxyPS5h7wq+HfPTZqeXwXuxT37dfgbdOnP5+sV6/ +dK3Px132NJdSt6ju7hlLGO5yhECbXKSlYzHb55Z3gSD1b/PqSohiqoNWWxTKGnVjnTawxIIeTa0 pemlSwI71phQJz/Qza59ARScT9InoawZ7WvFutS/wMQ5/oFuhqX7YQvdZrbtFKtOdkMgx9rGIvGI 7HijicppKFhFqcnQdPDykWwUhyBGHQtaOiNd1YiYMu9dK3xZ85YPb7g5zaUrhieT3LtqeEI6CvFp 1qrcvvz1EYqZb49Bo1DluBZCDBIxji7snf/baLUx303rIAj83U2cSJ70NGWKPLIiBduVLYTZa0My U1zFqLYgPSZMchUDIb54Fj4ntQ5ZWZufwNxIsAt6MotFat776KVLIM7rlPgjpetWqMrGealopowa mRSms1OeEHJEiljCIrYhBDpSOxZ7Ip6Eg0kqOmWT4awLf6Y3Fk/Z6JWWKlDsLmSc23wKPV+K0i/i QRDE2PMuERmThQAXkpFYZ0Upklti8qai7pwHPVM8iGl2JE6HAsacRYHnXP4joL9MykIXPZWfgPUl elLsSfR8Uj71aUXwKEagkdSd3R5Tq5Uc6SlLSQhDH1pTGj0PPRXly5ZChaEBHahde1IQQRH/cpkI 7WU5SQtc2/7pHZBIbKUtjeR21JPJmVo1pjbV6lYrUhBLJVUvzVEqVyXyEZEyZIdm9ald7rLJWOnN Vi+Fa0KoesmFtkemmPSmQskqLHkk5K99DQpe4uKXsLJVsCOSVV7UatR28hSpS5VJSSaLK+JBJlfa oSuNGiqo9uA1scGSx19HG9jAhnY5+URsSW30HD7dUyUUItFfxhrO6nDnJIqRq0SuU9duYlWmV1Uo X1GrntIqi7SATW5xJZJRwkbWKBP10EM4oh6R3LOekK0nO0d6INF86jG7lUl4XfrSc9alNDO96jeD y9zhbA9np5XHRJU3US3lpbDKOW8WoWMY/w+FCCinpWFQLmPURR52p4VMJVHoazL+PiQydAOoQana YHjCj0g4uiugmkIthTbYvWZB0GgBMNqDmBjFIWancc6nXwc/eCPSCQxhnlPdhyQ3xScuynUdIzR7 homfQpToZyxYEd/KVUWQwdaRO5UqyQFKWR/GUXx0dFcYq7guJXbeiXGpTE9eLVtWc6bo4gc/W3qZ fmDbVtboKK82B/N6amvVhtQGyTnfkUiBJdZfS4zndaEPOxVDZrgqxK2D6fHL7uKeMXE6TGBGbW2a PbQxVVlKsln6rgh6io4CtdANVzqoWBZxDfRcYhKTOo9CDmGY84Vpq9mxSq6e2l3Whswhlv/yakx7 jrXqTOcPEWZt8z0xabeF4rV9rndtW+TmVHihY+8S03V04Sqzl2unZQxBdFLWEYM4bfapCtObziuH qTRFC4JY1BIhMWmFTWr2jXiEq7T0orFIZnAPmFM45Jr6bjk2e88YRK1SFkfS9mstr3vYn+NzIoso qwIW8JeGHGO/Ecnvbvd72wraDkoYxHEQzppKuJ4IoLYHZUF5WsMTT3dREH6s5GoZ5p98Yfaut+jE GZJ2f15wIGVZu5vDcIYMkrNGGhai7c33tDHP83te3u5p8y53Ksf4uevNcFKauX03/1x5idQYqk/t SiK3paaPBeWlFElQVF/5UfjMblO7vHH/Tp/54/zNcJvzd9Y7r/r65P04B7VKRA3DyMNEtHBiIxdb Tj91GQNdRItPndoUx+KVv+1t+Wk2ki/d5eQ9Z7D4lf1Pp+FWezpNdyCu3VPGdjfShW1quQPQ9NZ2 4TPrfu+515zedq991QjeEYG/h+gdQbqWoVZaPZoY1Yif/VCfGvmnX7yFtKe98ysPeY1nXuwVjzjN a4bJHO0oUKZRO+qJYvjk6zn5Ovd8onffTGdi/MFdBuWb4Y/KMUr/bBtJHOEHXzESU2u+jg/ekIv4 oqnzTqbR4C+oeumZfInRQu3MBGdeYKyTmsldyEjVxozTvin0Eoe4EE3myE8o5Eu+AIvU/wTsu+YC 3UgGRIAt/yjiIkxM4FZP3XIM+ZCvyURQq06us/JKB0MDB3Fs2NhNOFaQ78JJQWrMdGwsOkYLAZDO 3VbvuEywtFAQg36wpmjKqtgLCz9DwNgNB+NJLoyQeagrOtJGTQZPOuThCeslxXDMBpdLwBKwC7Pw 5OrwNkyLBoMQD2+jxv5rTQqDDWnwBKOwBHXMBPswtBhKkxRxLkwLDiHRCh2xLlyr/85GRAaPDZ1Q uRKOIkgwCilRFEdxCE+wCiGRFENDxnzvTDBiEJcr4cAQFacwFWsRDxkEDGPRxMgQcHhxODiiujIx EW+sE9sOEWMxFJ3MFl9MPXzxCLHQQf/0sBAX7KGKzEauxBL9q2pQcBa5LBlzLBRzjr6ccdSqiBwZ bL+4rw+lRAhVrRpP76Z+IhB7LyM2kRAPkelAsQqpsfrqy4rOMR0755AcUWFejdGcxs0icP0ucG0Y 8P3mDwQv0MvsL3IObWCAbwZprM6ELwA3xPjyDLlO7cZ46ZN+bmEm8NgM0iHZryAprdXGrP0UUiJb cpjmTyJdMiZpkiRThmFO8o7gsa8gLdq+bXDmTSDBbohQ5hlq4BmwDtL0LpXSJ/tKKSOnC0TYsAD7 zLSKpe0icRdPj9Wsr0yGMu8Msh8h6fmM0tUuTfZgT/L4Ti3X0hqjCZpSzb0Yr2bIkh//be+HoAle lpIpE2Ipvw4qk7IuL85xWOUMCUPYdhEK204rvxAR55Iw/S4HrQ4vse75zEaEhELa3PLjqNHQqs8p B/IwL6i48NIsr+50QtDRhMx93mMwN2QpaxP6WLMw3zKIQG7GpgPwACsrQ3LxDi4XtU4cbcY442/9 po81gS4qcXM0HxIiPxPDvgwEQy065e19TFPM5EXFVJMzjzDkYBM0LQ4AbLMpAfMZBjM08c0wN7PI Oi9EMtLl0A/etNL1CjE48a49L+0yNXP7ENPqsOcAy1I3KTCXUmU0dY8/BxQ1UQs8O1M1y5I5+a1Y 1jNfMFQ2D4I9GRQuZWj6No88M3BI/xoT1aDw7U5QjBo0M5XzPfvzLCe05j4UAUGUQj10jt7zJ/1n 7yiPrJJzITHwID2PmbTHAS9wPYtkNs9TMJmyKUvS/iAySn1JfbBTNHfyIz2SjITwSEOwk6bURW9y J6kNShGyTEPHNam02grUJ2HyCodyXVaUSM308ZbxSNZTPTlUTzE0MAFzeYxwEmnRFD3RTgvVHQ11 PTDUT/mUQ/PUHOWCG4nxExGVUgGSUouiNhk1U/HUSdHTHyE1DFFMGsPwUpfRUktVKBZVTyeCTxXV T1GLCN9wGlHVJ/zAD2rAVmlVV41CUQOzT1/VU51UxWR1GHf1IGz1Vm81IZAVV5FiLf92oy1yw1gr 0bVsbIIytVE7FVsdVdT4cFofQllz9VibdVmVtSh0Y0kkpTe+VS7SEMDQ8U5tU1ibsk//skk1pRnL sIJc80gAAFnF9VhzlVnJ1Vx9IkncAmF7I1rRlV2FYrpWEV6vEDSA1VNlU0Px9FVVMF8vc8gc7FQF Mt6mBCnR0Q/8lVn/tVnDFVeTFSh4Y2FftqJ0qmHlsVqVMBCZMVEZtV439Fhc1bvS42PhNWg5Fig9 ZWQ95Vb9tVyXdWWbNmVbdl2VJF1jVmqTZGYngugcptUeBgKNEyV1TuusRFueFEHIljYb9TyJREPL LEq3bErdbCwnjUDb1MxoUtHA1kr/H+0hn6cnd1TWMJAl/yxxStZaTjZZC/ZwnTZSonVJXJY3opZh r5YVWWXgeE3lWvQpnxHcboZenbRsmXKZQPRy21IqaRQ+0bL+zNIpSReUxFNIjxPWZi7XitJpbLVw leVfEVdgCdZgoRVAnhVJGFdyY8xKAG8xg+85YQg8j1JP01ZYmTQwobdzaW78YJQ6yVN5e/Q01TF1 H69AufPdHvTfqNN2k3ZcTXZlVZZl1TdX0dVqrbZxF1ZJIldXd6ImWnH/MBI3X/TfNlNsfQlPnRcw oXdsOjc5rdNA3U+BL3fvrtc/XTfrcCo26Q8s0cfevtdxrrdkbfd8ExdgwTV3CxY3/6R2N+I3ZqW1 fhEKARLAtYDP4GrMha0Vc7UXezsVZ5KUUWf4yhApQU3X+mg4dUlzh2mYMit4QXM0LYeEg0MnXD84 fdd3ZeGXSSYCYU9YWoHXtnisT6IoMwwDI+msBQvOLUM0ieVIM8lYZxbVYj8ndM2z6pZXjLLXjupW NK23hmtUQIV495D4QHPEfJUVfVPWXHeXXBfXih2XfrFYiqtIi7c4guy3I9QU2Lq2Ab/WTM8yTqsm PaslPTmVgHEp2rBzJWfySo00cyXwe+v0S3GyJjNZ/WTOTff4GQP3WN8jaTeEZZV2d0O4kJ3WD9xX eKn2WQ82UrI4JTCDRGoEgmgCwP+EkXiFqmh9AmM1FWN/cGhBVrAAtomfVmBVlpuVVS1+mUmA932p uHGj9m9e4zXKarwamUZ44kXUcD6ni8bUEGh9VJp71Vfr8FTp91BtapeXVnEJVpsPl2UlhWrVdXHX NWFHhiseejWOGTzaeU/g+TxYmJmBsZ5nrAghkC7kVQTpkKKGOWS5apsDFmUL2YMJ+T/E+ZwVlorJ OV1h2qG3Ajbswz5ua6JtBJ5BhpvSMMYUc3hryj9k1r1EWJsDtmkTF6VT1i1s9XGD95yFd6qnGFgg 2qY9witIpMCOxKIz436FkXJ905mH2or8o4SPWqB7mZvHNaVZdh5++Zej+oQZGn7/gVlY1vmmI9oc 4qE+YqXAkhk9ZASSxZoJn9lazbqKjBqdUcug03dpdVciDlqc4xqdsTh+EVqn0LqmncUrbHqn/0mw hQNGZiSsATGxX1CxF3t+5TfEoDigx/WJJzumy1mqKQKFpxiza+SzPxs29Fqix8sxvBqhNEO1/3C1 uQqzFzmbFZd9DfqxD3pcLVtcXZuhZ1qzXfaqIToh1PmmZQWZmaqiwdo8bvawk/usdWOzsZu5Qnhg kVp3C/ZxEXmq5Xezd5tP6uMhuPu3eeykKppvNqNme7Os0RswGvrA1fu6X7upJ+K9lXp95Rucq5hx h/mQqTpYHtq3u7sr/OmYP1xY/5KHujbawEODvg/cqrFsYEHYrct1kAW6um81oUl6fmscv/dEv3Nc na8imUd7giyxxEWjwm/cWWmcyJtbkHl3tmF8qeU6qsd5nLW7atnbRoD7prlbrz08yPuwwk18vo+c rE5WqSEciicbihn2yO07ypm7ynGarzd8K6x8y+vQn72chFWMskW4wVW6ieF6t7X7YIn5fcE8PXzb pnP8t+V8zn+QrhWaVsX1rWEbhKFbxsv5ZWH6ihm7s51lNXp7xxcdDykcw6fVmyMcZQdZuidckW38 vlNceTz90BUd1Bk9t3f1g5Easll8xdkau9E60GGWzXHcu+P80N181kM9s0kd0v93ncxpO9d/V2HV /LJv+9WJXSKy+tixkKQJ3U4fG1wjmyLK/HcR/M+jPdjzGqdjvdMjOttpXXL7XH0dHKW92ZyhHNPT 2qF2fNjbnd9f+9ZzV8nHvN4p3Kq/vKb0e937XeH7Ks/LPN6fNigsXMEdPd873bsXHuPD3LmT3Nv1 vCKeHFq5fXk2fL8z3uS1CtXNnGnlgpip/OB7m91PPsRipMSZOsJ5fRRJftF9oQZ4vufXDoq2HNc9 Xuax0BeO/iCQPulFjeb5pujH/ekFC+mPnuepvuer3uexDIKePretO+praup/nuevgeyvYeytHrW4 Kehlfsbv+uvB/iHK/hoOouz/sb64fIXmF57cNRva396KfL7qE4LsfcHsyZ7uAz+xHlkzRLzdt11m jVrk/f5IsD7rj37w537we97ws56rjudFIujYW12qybnOJT9w0N7yCb8G6p7uzZ7zOx8nLDpGGH/L u1y3ZbquTb9krD7wVT/zMd/wyz7xQaZXuGkZQ9vLYXamM52qz133+aT3MX/sV3/6zz7xnwh5aL8O /Qm8McPEX3qEq3jKG/v5+0Tpz37ufV7uCT/sX7/zHwKSKbWrP6OuD3n8rxvky99GOB/tpb/6AcLX tRrXBtbw5auGwoUMGzp8CDGixIkPE1i0WCNBxo0UO3r8CDIkxXgNSZJUeLJG/0qRDecpdFkD5kKY NF/OnIczJsudPHv6/Ak0aFCECYkiLFjwYNGCAgkiTSg0qsiLDTVKvYo1okmTKlWu7PpVZE2XZGni zKkTbcyaWdu6fQs37sEaAOrOJZqUoFKFAg1ClQugrVWFg3cGlot4a1eUdEuGDUl2LduzaSXrZFgW sebNhut65izxcMOEAP4iTXr6qNG8EEWL/vn6beyFh2c3vg26bbzdJ7nS3V2yYe2OZynPC2w2p/Lk mHM7f+7QNvSJpKEuVXja4LWEBue2xiodtO3h06MCB14SANfz3yWqfekSAOXLy21ehl8+/+bxnxvb FU5Xba71F9h/no3nn12+HP8YoF3XFAhAQRHWtV1dUDHYYIEKYQjhbB3StmF/GdL234gAbohigyBi GOJnIrLIEIcvBhgiii8SqCJusbnmVWDxHLhbh8DNyCCMOR2IE5J0LScTWzfJpF+UbXkYI40PGTjc axCCyGWVJZZGV3UrlmYQhQ/W9leKPGppJV3yvClPm1lWCeCadHY5p5opnvglbn7+yaaVBsoZHaE8 3nnYj42dtKVKBTKqp5+iFXeWfJJSip9kTUrJqVsH2sVmeIf65+Wdf5LKZWkLzvXggggRtOB2D27n Kp8rllpDnADEyWugGnZ5q6lU2mlroZIeayqyo/66Z7B6Iqiehj/y9puPGyr/uhJ5gbYUE3LIcYup WTZB2Wm5QFHprLE6Hqvlp4VqiRCYgb1a4FESJnWou+uGupA8oumqEMAJykggljDamGqfp94Wqr7A KounskXSyayX06r346eKgphxvi2KCJO7x1WmnGVqRTafuSr3hC7C7e2La7NXKhtvjLGyelirLkeK qsu6xpmrm0HnKWydEzG7I88Uxzxz0evu3HPURFscLUk+9nb1xl1pK/NMSx6Z5FoQlTxWySufzVLL UZ8Ic7rbun2QvHytqqpTEVZX84B7Vlwg0Le9KbTAfOuINLJs98y1sfw+nHSqES9O47aiomQtxjZi jS3DSk963JGWIhef2O9Z/yY22qaLxN+gL+eLY4wiMk3eiLVeeCFfAiL9K4eA++u3vyzePmDuX77u 9Iw1Clciw8R/zPzeY96ooeQRJare1gV7ZpLxkb9OloskbjhZZZnad3r55oNU1EKv3kUUX0Ltzmuu uwYN+PmIhdcR/guhtxi1vD0mluKkhVz2SVlknmS/BCqQIX8pinXatxfvBAVo9eNdwIK2QNnwRH8o oVYH/9e/n8zngCe7D/lIl8EUKtCBr0qfUVoIFL9dMCa6mgec6qdC8GzwI77pDUMU4xOyDRAzTSqi EXOIxNOlaTQQfB8GN5IAeUTRhgGTYRJPtxIgrgeAIDFbWcgVLvrU54pkXP/ZCx/YRCfWbx4JsCGv cFjG8vnGK+hZjwiNI0RMFfA9o4ujH/PTQLfcUIrycOOb2EhDOP4RbefpIRd7QsJNiZGEizwdP65y yYVkUoGb1GQVd+cSONWgkwohZSU55UP2hOQbC/kGK4noNfGhZZYmM+EpOWXKUXoyJJ3MZflMyY84 RTGKhLShReYRzIZk0pe3hE5KPOiRV9bAla+UZksEeEL4ZGZ8zZRSLjfJTIj0MoXAJEwVS/cmfiBy l91MoiunyUppvhOW3IrlfWbZx3ZO55L86Gcp+wlQgI7Sn+wsJUP4yU6EGtSg4CzoPwk6UHAG9KHL HChFywnQOCEToDnhh0b/AlpRfkIUpA99yEQj2lCCQlSfPnmnS+MJT2saBz8j1OYQWRqlkS5Ulxbd KSnH2VCGJpSnRA2nQnU5TmX2lKhM/SevPOrRNyUgmUflqUg9CVSH/vSg/+xqU3EKkmo6xKUPGR2U xnJTsOonqUFNKkPgwdSUIhWrcxVqVU3aVLfStaAi9adHLSIPfhJzqh+dKlfrKtS94vWwCw3qV9Ua zWlKliEwtea4rgkuJ0F2n4dtK2MVAg+48iO0oqXrURF62rl+86QCjetFXevQUWrEIlCVYik/Ctuq qrOXLmntZ3M71M2KJJ4wjallr4lHMBJQuNBh6y71CtpMlta0RVUtdcup/1XXZpWvDskkbXWJkZB2 lqc44WdkMgmTrX62oj5lbmTnSdl5UtM92XRvp5zbWMZK95JwHWV/26tfpe7UqppMrUSLqtsCd3e2 hv0rbXF7YKTKRKEb1WVv87teAOuSg8ytrEI8TFz4js2Ey7Xvc9yqUpCOM7SjDW1eszvg6ibUryUt 6TJp/FMaC9igUwWoVW6s0N2WBcjILK8/L0zRJGv4khw2cYg/DE8T69OXLobuWrOCEQZTJGWiK+8A Dyjlzcy3lTENMydVjOY0q3nNbG6zm98M5zjLec50frNQiutH+ZLVmsc1Mxmp/NYakHatvv0JVRic ZeLYEqXjEld54CviK/9SU54hfqmfcQpXF7v4j1aZbUYQXZiyRkSAlCyxmOdb2UirUL5RZvWl1Zrp /55SyxAJtcmYJL5actM5ZIWyr+PY616/GtOClnUZO82RiyDbIZlB2fi2CeZFa6aafSbjmKFM7WoP e9to6zRGFqJsb3+70ZLMNanre+pfv1TVKXQ1u7kN79OJe9wVGcwXSUbiaDtb2umuNLA/jGdtx3vg UlL2pz3NEXDTu4C1pKXDuXzqa2NbrH/Es3PogXGCa3wiBjcnog9ucCbN1GvNvrfZxDzZhrh64yCh x0JczvKYm1Ph3ibMoUNuS7SSe5u7jguky/xrmXvE5TAvutAHnuWbD2b/3FTJCC2/XLqZjjHa0574 zwV+9IxnXCEYh/nR4510ptM84YXB45McflmIT5vST0751xtC9Bp4vetef/uwD+1xm0PR5vQm29Mz C3XQrHzSQbc717lO97obftsIT3aiQ31MbNp0hFI3YD7hYlmKL94hdZ+74jd/95nX/ODghnbpol5y e/Ib81EGuNtBL3e5x53otIe9lJFdGHrr3tb3POHfw8hrt2Pd7nF/+cs/fzaL2x4r4nY8FJeukZJH soiaoo/qBU/c5TOk9sVHPPLLJVaJaz8oHzd403HP8LGh7ItlG//Kun542W89+cJ3v1SarveFf7o5 qWf/Hk9mavY3HbRngXTwZzp9NnwC+BGehnd814AI1HvUN0k3oYCdsnUXeDqTpoHvVoEgMXr4J3r0 lFnho00j14GconWxl4HCln0nyBPQ53hLN2ol6GjmJjouGCWzl0CQJmw4yBLmt2z0xX5nZX2nt3o+ SHBPxmdI2BMgOHPEIS4nV4QByIQbJ0+v9xMBAQA7 ------=_NextPart_000_0003_01C71D9B.59F010B0-- From discover@alofatuvalu.tv Mon Dec 11 22:19:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtyAe-00020Z-CG for ipfix-archive@lists.ietf.org; Mon, 11 Dec 2006 22:19:08 -0500 Received: from [218.85.86.146] (helo=pc146.broad.dynamic.xm.fj.cn.cndata.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtyAZ-0005XO-3W for ipfix-archive@lists.ietf.org; Mon, 11 Dec 2006 22:19:08 -0500 Received: from PTRcIgbb (unknown [116.110.120.36]) by cndata.com with ESMTP id 3DEC76A2957D for ; Tue, 12 Dec 2006 11:19:03 +0800 Message-ID: <000901c71d9c$3e89f240$925655da@09e202c87455468> From: "Images Video" To: ipfix-archive@lists.ietf.org Subject: Google Date: Tue, 12 Dec 2006 11:18:50 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C71DDF.4CAD3240" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.3 (+) X-Scan-Signature: e4e7b084ad5ab70bec6636d1707b49c1 ------=_NextPart_000_0005_01C71DDF.4CAD3240 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C71DDF.4CAD3240" ------=_NextPart_001_0006_01C71DDF.4CAD3240 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Images, video, news maps more raquo advanced! Discover new onesabout for. Searchsign inbook images video news maps. = All books full view the text of and discover. All books full view the text of and discover. Discover new onesabout for = publishers? All, books full view. Discover new, onesabout, for publishers. View the text of and discover = new onesabout for. Help all books full view. Help all books full, view the. Searchsign = inbook images video news maps more. New onesabout for publishers. Search help all books full view the! Book searchsign inbook images = video, news maps more, raquo. Inbook images video news maps more, raquo. Searchsign inbook images = video, news, maps more. All books full view? Video news maps more raquo, = advanced! Of, and discover new onesabout! Full view the text. View the text of and. More raquo advanced search help? The, text of and. Help, all books full view the text of and. Discover new, onesabout for = publishers. Video news maps more raquo advanced search help. ------=_NextPart_001_0006_01C71DDF.4CAD3240 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D"Book"
Images, video, news maps more raquo = advanced!
Discover new onesabout for. Searchsign = inbook=20 images video news maps. All books full view the text of and = discover.
All books full view the text of and = discover.=20 Discover new onesabout for publishers? All, books full = view.
Discover new, onesabout, for = publishers. View the=20 text of and discover new onesabout for.
Help all books full view. Help all = books full, view=20 the. Searchsign inbook images video news maps more.
New onesabout for = publishers.
Search help all books full view the! = Book=20 searchsign inbook images video, news maps more, raquo.
Inbook images video news maps more, = raquo.=20 Searchsign inbook images video, news, maps more. All books full view? = Video news=20 maps more raquo, advanced! Of, and discover new onesabout!
Full view the text.
View the text of and. More raquo = advanced search=20 help? The, text of and.
Help, all books full view the text of = and. Discover=20 new, onesabout for publishers.
Video news maps more raquo advanced = search=20 help.
------=_NextPart_001_0006_01C71DDF.4CAD3240-- ------=_NextPart_000_0005_01C71DDF.4CAD3240 Content-Type: image/gif; name="News.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c71d9c$3e89f240$925655da@09e202c87455468> R0lGODlhPAIYAoewAAYHDYwIDgCAAXmAAAACiXUMeAB+frO4ybzWzJ3S7zwrB14aAIMmCZgcALgr CegjCwBNABhGAElFAFVCAHhCAJdGALJDCORMAgluAhRrAEBZAFxUAIdjC5leALVkAtNlAAmKACmF ADyCAGNzAXyDDKWDAL+OCuaDAAuhCCWjADyrCGepDHGiAKeeALGZAN2pAAC3BCfAADuzC2O+A4mx AJfFALnHAuu7DADrABzuBkjfAFTdB33uAKDpCs7uAOTtAAAOMSUATDUAM2gDNY4AS5IASMwNQO4A NAAdMRoXMUMjM1QgSowcSqMhMbQRNuosTgYzQhJLNElMTVcyPItATpE0N8VNPe1FSgFTRCFaSzNU SllWOYpbAJ5mTbtTRtFcQwB7RRuEPDV+MVuEPoeNOpZxR8uCTOR5QgGSMh6mTEaaQWuTMX2aRpat S7+iRO6SRwC4MyHKTkrARGe1Q4O1P6u1PMXDS+LMOQDhNizoOznZN2fhPIDbR67VMrzsSNbmMgAH hR0Aij0AgmwIgoUAg5cAgLwNc+gMjQAkfCgbjDQbhVIje44tjZwufc4pgd8YiAdOcSVLeTxLgVND iXVKiphChbpOiuQ5hwBVfhNahU1WjVFWiH1seKNehLtnhu1mdQJ7jCCEhzp2hlODjIN0cZ12gs6O fuWDewechB2XhzSYiW2siIGScaqcisauh+icfg6xiSXLh0jEe1O/i4O4jabKhbW4iNy8egjsihXn eEDUfWzdjozUc6HTe8HYgu3pgQYOyBIKw0IBvl8Nu3wAwJUOs8oBy+0KvQcfwCoczEglymIZzn4j x6kswMYmstQStQJEwCY5u0QysmNGs3RHwa03v749wNc2ygRoySBrtjljxW5UvoxezqJnxL1hvt9c sQCLvB10vDiJtGeBtId4sq1zxcV9xt2AwgCWxS2rxjSfv1yjxIKuupWkxreSt96nvgDExCnLvEyx yWO9tILBtqrAxf/57Kytq4KGi/8AAAD4APP/AQYC8fUA9ADy+f///SH5BADCxSEALAAAAAA8AhgC Bwj/AGsIHEiwoMGDCBMqXMiwocOHBg/UkEhR4AGJEy9ihMixo8ePIEOKHEmypMmTKEXeuVPDzh07 MGG2hMmyRs2ZK2PaGbgzJU+CPWX6HEq0aEGNFS9OzDhwo9GnUKNKnUq1asqcM1vO3OkyJk6BXLP2 LCqzrFahVtOqJVjRosWka+PKnUu3rlyWMmt2xbv3pdeuLoGSLahTq93DI5ViVPzWbWPGiCNLnkz5 8MqbgYWOdfkSrFewZ4kG5Vp4bOXTBxcvRbq0qVvFTlHLnk27NkS8oDv35Ux6p9+cuE37DAr6s23U GyEvbpv89fHn0KNXXplVq1+aeXvrNStc9Fnj0iMz/z86HnbG2OHTq18flfP1sJ3f46XesrNh0aV/ sq+LVONriowt599+HM1Tg4EEJqggfYHl1Bt2NgHmV4TVPWWWgocF6FpjzjEHGYYEGTjPiCKCaKJ0 7/kmVmAU0nQZWlTBeGJarLX2mICOfajUiSSOeOCPAiE445CoYaVTTDc5qFlv9xFpIoBNqQYbgDUq NySCPZI4kI9OdmkZTw3ylh1nEZImFpHypAnigP8ttxpTbvrHZoJZ/tjjlkJ6qedcL11nU4R8ASYh fRWCKE8NhyL6ZI6OcTjlhjuip56QWuZpaZ57ZpqWiqRNGF9efYbm5KGkJrpfjW/GNqBqq0HJFIg+ 3v8ZK5CYamorVLiFGmhZu9pXKIZqCpRosOw51VZrSQXY31uSrncnngfGKiKXt1aLq29I1jRhT7sS d6KpBKUJbnqSsmpjo68qiyGWWkbrLq21WivvcLzq9CJfDIL3LamIEnuqq65NaSWy5zUb3bQFUVtr vPM2fJJvetXnYld7ihusuASay2yqNxp7rK2UUuvwyCZpuxdYWPn5q6HEYoyhh2y9SjBb6tKZpaXR KkzyziaZSR2SWwnWpcVPmneejclyHLPM+5UY5NOzVsrz1CTpmt+Fmpaq4LLJUvlfwDEbfDCe07ab cIIIUI1YWGE57G9tfggUtx9xb3hucnEi29+xO6r/548/QAKeM84lihweAogLlLbadR3JuGx1R46Q wQKjy+yc6f0t+I+C/+20u1Krt/hAiCf++OlF9dNPDauzN3fdNdStYcEbw9w32NL9TZDn/mBZg+5R hyi64osXPzrqyIu0uuqtt34c3bFHL7fcc0cPF94za2ze7bYBrrnmBnk/ou52Bsnwc6aXfnzy7IPE PPMDLQ+39NAPJDnddCsrZ8HXR6RxbeTTnQB/R8Df+QhwlAJR2hZYg+K174ENUZ1A5CfB+DkPcrHD H+wyCD38aa9rqjoam8Q2me8NxIQC1Nw8PEerLbHHgQ2MoekgSMOEVJB1zWMdQW5ImfplkHr4M0j+ /2jWqtRsDGkklMz3lkhA723uQEwUnOGg8osqVjElpSOe4ra4vhrSUILLA2P8LIia+gXxh2fcYN72 x7W9wQk6KQzfCX+HwADmrCpWtKJPZqhF0nnxjzpsHvzAmDYxVuZ1aEyk5Ja2N+zBqW8fmw34BAI+ 79GxkuBbIRSf+JRf1MCToPzkFT9pksRlkSCnBCQEP8BKVvajlR+QIAJa+UpWEqSVNYClLj8wkF0K ZJe67GUwhanL+/lhl2mMXt1w2RpctgWYrTwAMAsCTWYyEyqWZOIl6VjAg5iQinoM5UA8ScqRGK+P qvzj6qwJy0K2cpa2JGYu43kQdvLylvSU5zzvuf/PX7ayerg8Jis3iEiB8nIx0WSLM+FiT37i06H+ hGhUMMnNilrykpPkZFHISRBxCmSUIZmhKf2YTgjW8p66RIDqaHnSiLq0nvnMZz8fStOZGlSe+LMl 7DpoUHpK05b9iWZzZkrUmhr1KU7cHQorSknynVCjKQGlVPMoyqqW05yobCAfS8q4c3j1HDXwKi5P +s6TrjOe9kTINdUaU5n2k5kGnds/NQhEDdJNl/5Z60Scea5r6vWlRy1KJRHSuaQ6dbBU/KgeFWsQ jpaEgTHkKvLACtaVuhKeH4CnSt+J2Zf+FbBsdehfcelXegaUoHX15zwRCtSaxqa0Ei0qaIni1IL/ DDCpBbxtEy+60XFWlZwgvapIUinZ0311IOc46weS+07SXraWqo3oNPfpVtCO1pb2RGQxC+LDt5qW lQyt5kw/K9vyDmWSTS1sbilp292ydyjA/e04w+nR9XSuuJWh7HHD+tVWngOzZz2pSjEL24UM86jX 5SUwq/fDYfI0p9j97kErQt7pwlSi5PVJbTkZQPQOdoDwdexVgUvVUIr4OR2uLX4PQ1n+ejWslo2l gAnsSulK2CF6XWuCvcvLRT4UtXGz8I4vbN7ZFvkk922vE3HbzSZyk8kmmepHSUnV31YZjrdN8ort st8WU9asYCZrZlsHy8AmJMdtxXCEUVrdZQ6U/8F3vXF5K4zW6s7ZzkhuKlOdPEfDsheTKibJFeMr ThLnsb5w9CZUQ+KNRjd6yx15sUD0C1bW0XKmNFappXVs5zRTU6acZrOo+fnm2P1TmRks8J1jO97P Zhibu7OoejeXTVrbOsTldOxipxrc7qXwoouGyKNr4A1iD6TYkH6Il/WL3HOwlKUxHrNyRdvpOqv5 2oCFbY/nemq7mhqi1jYInUk9ZDNr2CEqvnWH33uSQ0uZyqIksXCPU9hfi+TRwy62ox2dbGVXetIv 1qWAG0jWC4JavNStrqsPXFRYxrnM9qMemhU8zWpSnNoHx7ZR1r1hJy8Zo+7lM1FELO9cI5o2tf+u NaOPPWyB6LvfDaF0WAki6coOUoz9QBwPabNTH0/PVriN41OV+uRvNnmjUo23fKccnaDHOtgK4bfL kY3vffMb2TCfOcBn3mL+aj1+yaXgzg9JkJ2W3Ywb1JPK+/zkJuv2iYFGCUjn3tH4JvrPSY47Q7BO 7H2z/NhTz3qzmd3lf/cj7P+e4AV5HkQf8vTnmrovbw8bvreDGOogMXShRzzo3NV7zyN5ecuNre+q C74glV621rtOxuhErvFo39ms02t0uBd95Er3LZUHfWJ6S363mC+I311+kJcbu+/DT3bNJ+311Sf+ 6+oBMiLn9fm2i5zdlAcxru1+cr9tM4odET3/8UlfdeMfH+aS5vqL/5361EM/QWlvWL0v/+HcUnSb I6+v3XOfuW9quSFYF4CBd3z4hnxWd3o0R3PPx3wISBe8xXZuh38ed3T5VxBJ12t+c1jBJ3xTR3UB SHUDOHyjt2VfxWxcd4IJ2IAOWHl8Bn6xdn29xVi6pyD/J2zGJ3VXR36lR3qCV4Ls53ztx3pEEQBE qIILoYF7RmtPJXkb2G4mtn87c4DEJ3pXV4V9l3WE537nQIRc2IVFWBRcOBReGIZi+IUE4YUeQYYG MYYBIBBq6IZmWANsaFt/w4WCY4eAE4b+4IV7GIdw2IYOMYYFIYg18Ad/0IVSFYZs2IVyyIiM/zgQ iuiHkbiIB7GIakiIC0GIZBiAXugNj+hyXeiJc3iGflhDx5V+qLiFRbiAPvGGJ3GJrlgSrjiJgPgQ sdiItTiJg2iGsFiLJ6SHuOg9eNiHAZCHRfhEt1iJX0iGh0iEhhiG1oCLvCiJpUiGaPiHuLiLbZiM ChGL1liK2oiNyRiGokiEVueI0+iL3PhA6+d1XQdWXMiKrQiOJDGL9PgR14gQ67iGn4iNpJiNpAiI 9ihH31iMwSiMRGiMBhmQDfGGRdiMAWCIf2ANXPiMn2iPvuiP+aiLDLmPypiRDnmPIZmNLddoBfmF 5WiOXIhsIZmRf6R6iedVLQmJ6RiHmCiNvf9YkP6YidVYkyDZjx/Zjff4kTYpktS4jUPJj0hph3ZI R3rojUkJkATxB7hIlTVgDdFIi85IkUeplH+okxgplbZYlC55i+NohlJ3kgHgDc+Qkmu5ksU2k1zV Ze64k1IJlsuYlwKpl3BIk3sJlAkBlX95l3kplC7JkGPZiIgZlB0ZlQHZh5DZlL/zlD15mOFYEFRZ kRJ5lZPIlRb5k2XJl6LZlR7plX5pmpfplTlYjsQmiGPImmIZmyXlZeonl9nYi7KJm6Z5k4bplbhZ mnapjZYZlLpJlHMInOJYjAkJjMQYnLKJmtpIlYZoDRAJkVy5lKl5mrdZhBx5mpY4nHYpmIz/iZoF uJK4KIrouZKUuJjFRWn/ZpvdqZW5mI5++Yi8GZiVSZjYGYhGCZ6+SZ9fuZ/e6ZP4yZRdSGs6mZ36 WIqfWYjU2aAV6ZlcGI3aiZjfuJ2g+Zw8qY75CZ0BmW8sWYTl6JbPoJ7m2JpE+AwVKnjwyZ3reZwA mqDSOJahuZSu6ZjOmaOGeZGk2aMZuqBaOUcyuqJAKhCGWIiFOKETKZ0TCo1jSKHOmaA3mqHIuaLi 6aF+WYCgmKLnWY5tyYUlao5sGabz6Z/41aICCqQCGp81SaP8mKPIaZY4WqFDiqHhGJZqaqPF+D11 qqGLKZ1JSoQPaqQVWZGBCo1ECpA5maZ2/8oRtpmoGgqXV2iSImqecGmiaxmiZdqAaOqnA7qpxQmY BXqZcmqmiVqlO1mcjaqdjyqc9UmqHbqh0tmMDeqgCXqdgsqeGkmgYYmqsdmqNaCiYumigFiSYOql bUl8kzimuKiiwqqCcmmf06ioo0msX3mqVzqjdDqYijmquvqqb/qP28qooTqUqrqrNdqQhsqMmsmu zliIENmGUHqlLcmt1GqqCnqvBSGsKiqtS1mAjxaGZOqswzaJySqwz0CmnHqUG9mw/TiK65mb4Bix AVmvwzmKOOmv4xmemtiV9bmP54qGlEixmHmT8eqME3md0xmvWEmkIkuWZcqjJIulGUsQzv9qszWb sZUaiuZpbF+qkmz4rJ5qhGuRrbThq7YCqA4qkUsKpQ86q0c6nUiqIAkrEFX7rAnrrEJLgMiWsH43 pll7s8TmtWAbrAOxtURrF0Y7G0irKZtppNQJt3F7pFe5slYptVdJIFd7tsFatWZrtQYhdcXXllVH uCpqfvzqt2kbGWsrG21rFNdQA5EruXMRtQMBtYMajUyruUvauVi5pHrLt/zat6QrthzIlmCbrMHK ln2XrI6WrFkLuHy7uLQrFZF7DbhLuZVrpJtJlYO6tG+ruXnLtJbLHrGLtXs7u2hLfoT7uobrgahb bMlrurVbvZCbu7eLvbr7ELfQvd4rEnf/i6RK27LwmrdGurTUqbnRSL7Ge7x+m7iKS7oE0WjN67yr 27diy7rv677La722AQ8DAcANM7m3OxAE7BHe2701cAsCwcAeYZVTuZkPOsEUercTTLwQnB6mO7ql a7V7K7Rde7h/a3yHS8J/q7ha67/QIcDw0MIC0cICfCu4m72Sm7sCUcAN4cAKvMAM3MM9DBF3G76W O7d1K8Hwmr5ETLUpDL/7KrvzK3p7G71ee3w3W8Wxq8LP4cIubBBb7DCTq7szrBAK7MML3MBjXMYP Eb7nK51PO5GXC8Fs7Lt0ux5CO7rvi79/m8c225YlPLbSS7/DRr2lm7wkQTRYTBRaXANb/wzALGwr BHzAYXzDN2zDBuHAC1wp8/C935vGUzu1Qey7v+u75Zuy8JrB4YG1Tay8/Lu1Imy1O4i8eny8TqzH JTEuh2wSjKzIMJzLBBHDXkLD2/vIk/zFBGHJ3ZvJB3LMDJzJPmzJDWG5gOq54UvBEvm5dkvHWiu2 YQu4yLu82YxvfOzB2XzFKbzHIqE1w3LLKMHLjLzLudzFv1zDNjzDwkzJB5HAY3wLIoLPO+zMCBHN SlvK6WvE02nNoBvQpyy6g2y203vFB6HNHezB8su/DB2/IOEvb6POIAHPLNzO7uzLTkLPBzzMkWzP ZdzDzMzDCjwi+swlm/zMxYvBSNrGRf8MusJrvCfM0LJLzvhr0alMy3YMyznt0xxhKhfTLxotEjD8 worc1Lvc1JqSvZRMz5IcyZWczNGyw5fsvSyt1QxBvOcrvp2LwZx7lTe9H+Vcx/ubzbQsztu8xCeM wtw81/3rEKWCMUY9JJexJ4m81PD8wkv9y2GMw1VNzMRsxpnMzMdsIC2NzPqczw6B0KYMwZlbwUo7 x6Gr1jq9023txB+szW9NyHVd1IoyEHg9IyyR2nri1wcCD9MSw++sJwUMyfNs2Iet1S392MmcwGh8 0jAtvmF9vlg53EfsxqWsxA69r6ic0wgB2g4N0Z4d1yOhNaWt1wJxE13i0a4dLa5tIK7/HdggPSRf XNvjLcnbq9L7zMMszcMqrc8NrNLPzLtMW77yzbvD28kJEtpWrNNw3dzU+995vMSyXMiKMizpDCKE gt1EwsvePQ+5PEV7MttgPN61PRD9rMm6/djK/DRencZRC829W8oZbMrtK9GxTNQJUc5NvN+cjbOF fNcFbsv7odrXnSkObj5NLTU3Ht5dMs81TBDa+8XGnNhdrdgulM8vrRC9+7Z0C80iPqsgstw4e7WJ qxCa3dCgzd8cTOBEI+NPcQwDAea48icKPiPd/cI3fuODw908PiM+LtKHTbm33dLsfclBstiJ/cP+ /NWe3MnzHdPBjSHbLNGovOUpbsdn/7u/C10UBu7lX14QYl5cPQLD7bLdQPLUsk3VYCzncj7nKb3S dvLYPtLhHCHExw21mDkk/RvUs8sQVgy/dczcox0SBi4VYB7pYn7rkT4U2kIoROLgwA7AwD7pI4Lp mULVJg3JBfHSmMLMCKLMP/wRcDzi9F3fRPLZLS7IC4Hl47zHVbwexxDuNYDr417u4n4VSeIl0iLA JfLdxV7sbS7eBSHVCzHGjt3eWE3qIfHnTX659u0lVb7lyb3tFe3iiS7OeJwe4X7r4y7uu17uRkEf 8VADEx8PE68g7DLsd8QlzyLDmy7P9V44QHLhGn7Sex7ZU/nG/o7fAN/N2g4RKDzoVP8uvxiy8Lqu 6xFP8RVv8QRx8c7Sy8C+8bocK5buyDgc5wiB2/aewF2d5CMB1lCL2ZrC1iIRv6we6wpvEDZ/7lr/ 8ENx8TwP9uxxJw+OIN293bMiL+TNvT8C6sssJC998g9M3ySeTquu4rNOG1vf8AvP97jO9UUR9gZh 8Tz/89xdJy2U9smjw7u9JZsc7XWe1A9t4j2N4s9x8xBPELkuEAyf+URR8Tof+mKfHgjT2sWO5nVy PowD+Xne9owt95Kf4hMNHfRQ+7Wv9Zm/+ZoP8X0fEvRQA78P/Lc/+GJP+BQvEKAPHZ+DMMLO8WWj +lTjz4rdz/AN+7G/H8EP/Npv+9n/3/V9n+tcr/scEfy/3/3ZX/gDIfjGn/zHwfFrDjpAAjU0xNtb XfJmfP0zkv3lPxDcTw/kDhDHaggcWGMgQYMJBSJM2NAhvYYQ6UGMWGOiwXgYMcbjuJFjRochRY4k WdLkSYPzUs5T2bClypY1YKKkWdPmTZw5Sd66VaNnT4M8fQ4VqtPoUaRJlS5l2tSpxIkXo0o8xtDq wqpZFVY9KtHi14T0QHoc+9GsU7QnWbJM2TYhW5lw086lu/Qnz7s+8QKt29fvX8CBl0KVGvUrxWMQ FxYkyNUg1sYnvVK06LWy1IQZNTvcXONszncNQwt2+FJm3NNxTZNmTVroT71BW8+m/13b9lODhhVn pYdQa8PIjmtOzf0wLFiQnTt77ohztMF3z0mvjVkd5kzVt7WnLbrd+3fwsy9GHI95YlbIBRlzbSyc pOHLlSvKnzg2c3PmZe2H9OMH+ujoAIwuIen+qg61tmaKKTwGG3TwQQiNcsedGiiskCaKxgMLrMIW 6u0ghh5TjDHK3ivRsuLCGk+zjpLbiLP9aujPv3dm9GPAGkIrEAEEcqyhR7+wW+k0BReM8Egkk1Ty NgsrpLDJ9w47DsWKEvvtMYJ6Q6y3xMoLibjyNCQuN7FYVM4zNJcbabT+atRxxgEDBDBHIIFMyzqX 3lpyTz779DMtCyd0MiFBjaOPzP8x5UPoosUOyq2qD7mkMkUyVYSquBIzu4+s5PDzT8Yb+5NxQP9u jPMdHn+k00cee0wVreuKRPBPWmu19dYmAw2U0CeNy9A83Tq08kr0BhqPveO+PExM3R6CyMWyNs2P I1H/C+3GUaObEboco0MA1R5Da/VHV2HN81Z001VXyUKddMccg8zZVVAoM1T20l99KxbEEYsTCDMV OeTQy0tT/EjThs4C6VNutRW11BxFlRMBP77tNsBUx7XTXOrW9fhjkGejd8ImzYHX5EEJtVRD+TYM WCuYFz0P0n9dBhhFZi39qjkXX+wZ1GplBNpNUV1tlWJUk9YRY4PK3ThkqKOW+sj/Xg161+R3KTQZ 5QutrlTKijIFi2b2aD6IS8cmO3TDwsC27FnmXnyRH340SohuvLmtAW+63exbRrq7bXVAuo/mm++R Dr+77sX3Vlykwxl3/PHJA68877wNCjxyyxvK3PHLN5e8c8sjL6nz0FHXnHPQG2c99NURdwh12utW fep0e53w5EGf3L1dSgc2j77JtMTqOK76bZlKwpINs+38YPxI9XjoptFyPwK/0frs636nbzdZXX1j Hm/3fHTGa299/fMbZ9990G//XP3ESbddcvjtZ9/81SHHv/72ue5/+7sf/PoXwNINEHe4cpK8arA1 rzmQa75bVsGEl6zKQApLV7FS/8DIU5jiUQZglLJPRhBwsOrVLSP90Z62RNcmFvLjezIMnJsEhADE HQ2HCjygANunv5AAUX4KHGICA+g/Iw4xdukrIEpkd0SS0K9/Sgwi/uxHPyMu0GOCgteFrqarB/bO a1IClpji8xXIwOw8iPpas0ZSsBDubDPxOCEd6di6FbawRtb7m474iDemaetbM7ScnQoHwB9asYnv 62EWoWjAJfaQkYtL4gATWEmaPBGS/oOi6KrIyfx9LpKS1GKtqsark5EsjPTqHYVCCCziFW8r+xJJ mJz1qxOBcFmqQqGqmBO4ePgnhULb3v3atEcagq9bbSJX4HZoNMc9DZKeFKAmz//3RNaZL5sFlOIn Pfk60VETdqBUHf86qcjULdGRrVsnAUu5RXhdrULy2ho9rbYr5zlPbWwTG2Gmkqlcsm1KshThs1Bo wmkBs1TWq1GO+vY3UxWObzQylZz+5sxWHRKUPvShOcXJSG1akondnN1IF3lNkyKypKQ0pwHV19Ip opOd/yPpO/tEwazVs4EjI1muXDkwRCUqqL5iGfRSJNQ4AlWEzDlh0zZSvrpti6EBEl1DkbnDGQ6u RhE9nNMKJ833fZSa/HMkFVd6Vk16NKUhvSQP2SrKSZ5Vkh8FIBYpR0qb2sp3qoTg7hoYL1be81eY 8mfzwNbGgcZysGVcai3BUsf/O3KkqSlcYTC75zfvOa6h4NNe4ba6VfChCqPPBOv6hMjETZoWtZ+M KWsn98gjYo6ImZNdTbsJ07Cu1qzxQ99cZYrXvPKppxKs5xcf6MBcOalZ+CroYqMUvOEJVaBrO9FT 6ZgqM5lOnddCJt64SlUZXquY4CLt+Ep7uZICEa8v1S5603lF2IbyfpS77V1d+tsoivSKtX1ce+sb 3+Cyq10StBDWThZPL1YNTJUi6Ne+VFR/HjVYDJ7PP3cG2R4dzDOQLRXEhGbDUWUrQMS8kcXkBJ1w +dKpKw5wi138Yl4N+GoQRFlxVdnTB+/TXpN6cBtvJmF+Vnd5TTPLdTfMVIpt/+vDbMLWiL31WYzV aJA88hadUJWQV50XxlvmctRuXGAE57SvIalXhQk7n1ou1cJrc3AFdUZhhZnpjjyyLKj+g61jKm1U FYsYxbK15BRfWcWv6nKhDQ0yVXaNZAeOl7xOeUpMsTnCYkszfEa4Y5cN9J+bvu4J6/ijyK7QD8EU mkFKZVVtyYhHMKzoj5hJ5R/paMV20vKhbX3rJEHpxgkx8AOhpGjH2myfwwnYgqf0ZkuTJMNGW86c H0agUAUIW6qG4SBJRaOtVmzKGqsTrr39beH2dK9f7CKOv/zrkgzWJjnLtD4t/WPiTfa6dgT1wkSC bVOhOM9L4/PFrjxiFWO5XP/gJnjBHYRPhyR6jOg2CY9z0tw3bjpYwwsqhkGdsFZVy0bQOaa/v5Vn U5UYTgOydsCPZnCUp/w7uuNVy+fF8O00D9OxlB40P23kGkhC5yT2g859Hh2dW3vnqa7YO3ZOoxzp HFw597kkyMX0kOy86TsnydSpzvSmi2TqDbk61LG+dauXpOsG6frWE1J2p5897WNXedtvouvkjvue OH7QhMcUUCxL1oQgyRjZjy4qpQNdEkaXxIwCL8iQ65zPhBeXz8nleK9z3elXZ3sN9rEPne/DIJiX hOYpn3a/gx7yn1e71kUP+qiPneqQx7rf1U76yLtd9jYRNxhVJm6V1T3ZHgT/6LM8rWFCQ53qPR88 iImPqr9ry2FJL37QXXX1Hq0e9a6Hvekl7/nTS94h0nd96VPvfdOjvfvglz73x2+bAxjkAOuf/QIV XvsERwh6bfOSSIw2cO2THkfMJ3y+31RRBAg6wns8SSA0HpG66RO+7BMJztO+Bhy/ykPA2JtACEzA 0iO9CFw7DTQ/CmSN9Es/kWC/9sude2q5GMu9JNmxxdq9phkX61M8tQs5wQs8f0u1z8q60suyAJy8 BJTA87O818s67CM/C0RAtrM6H+xA6su+DOw+HKy+1lg/EATBhPjAGqDCEdSrwCoUCuKTNaOw4LGJ JAy94vu6j7OYiim6EhM8/+lwPhUbwyX8Qc3bvMy7PKh7QPH7PhzUvu9TQifUwA7kPkFcQA+swiu8 QimUwobAwiz8k73qGkhUOCVhnpyBD5QYvqtjGKVjOsYTOT9rMsAbvIwJuhaMPh7Uwz10CM3jPDsc QrMDv/w7RT7cvlS0vjhsQjLMRVgkDStkPxH8RUZUlx8Yxh+ogWI0OHODOS+8u2Frt6qzOobZFqWD waGTkzT0j2/ZwYFrwiOUxbG7PHCsw1X0wTykRa8rRz6sPFjMOlz8Ol38Qb/4RfVLRF8MRmEsxmE0 CGI8xoLjQo+xRFkSwwWMRk48PMUDsYbKt53LGG1Mxx6UxQlsxcxLCGvQuf+KJMQJ5EAoJMJnlDwO PL8nZL0oXERDVD+TtEJEvJV8zEdj1Ed8bER0sRdnPAnVKzxMBMQAUTqJsaErI8U6cTxTxMiPvLo5 9Lt9sAak3LkHrMDTA0Tva0clrMkNfD2PrMpd7AtfPEkRTMmsRMSt9JOVdMmXbEl+hMkAq0kyPD3l YzoTGzEgqbwdFMm0xEivW0XsmzprsLydy8sauEiPREcFDDu07MNZ/LoiRL3B/It63Ep6JMlDnMda WcmxHEuzxLVtiUaG+bNQ4bM66cxuYzG0uDy+zEukPErS7EvUTE2zTETINMmUfEzWdE0+OUZiJMuW bIiyrMwu87BnexiIucb/UgxOaKIL0VxFpDxNpKRI5FxNriTJruzFQ4zN2STLsEwI2tRNy1SyTwma bXEahxjOvjhKcExN0zzKvhxNg+DLRlxMRaTC9nxNe5xNyTRGfKxN+sxN7DQ07Sy1zHQqz6w1p+BL zTvO8iTN5DxQmHRPx4xOlPTKrIxPCGHJ26RNCcXN/Ly17TS1UmsQArWGAR3Q5EzN49TNBmVNYHzN 1oTQBtnHCd1HCX1J/LxQGe0LDxXPolRNhxjR9WxPLHTPr2REFV1R63xRl9RH+rzNGU1SvzhO5ETQ 9ORL6VK5KXxMr6xSBS3JIBVSIyUJFlVSL62LA9VRAx3R5PSKvKQ0lDvR/wX10Xn8wAZNkuusTRbl xxj9UjtNCic9z4YoSnqwhqk405kEt+d0U9iUx8ZEUTit0MmsT+tE0jv9GJaxFfQsUOM8T9H00+VC U4IzUUKdwsa80ilVEvss0hetzjp91Fp5mwfJC74YCQQtzc3z0PM8zn9SzxEyODdVRPhESV2tR9lc Ejnd0iOlTlSFVOYCD9gACrwwCSa91Fc1zn3oUz2Vubb7ypNcxE7V1QfBDw1ziFG9z2F11GKNSZrT VNdY1tcQiVZNz4RoxTGt0fOkh2g10yjF1WuFzSrM1UJtkJ7RjyLFTQol1XFVF7wzV8HIi4RYVtmA jYYIUw89UBCd1dKMVv8PbSwpzVVPxdeSlM0sBYwz4RmP8FYkrdCB/Ue3CdTASFdlHYqgUNg9/VAD NU8blVhMjQpMxaA0RVTGlEfXNFHtaBE0QZg5slCxJNKSNdn4MFi/2AvZIIqWZdVbaEXTDNF3tbyJ fViIqNn260oGZdM2vVLb8Nd+TRi7IVUXFdejpRVqjVTW6A69eA2VZdieuNFXfVhZbVjRtAjNq1dc hU6N5dSuDVuNwA+5CVppqc+yPNW09RNKvA1lhVqHYNiQmNqHtcO8FE+rPc2osMME5dmNZUxEbY2f 4RkWiZteItzFlRqHa1umVVd0hY19iNq5tVwQHU+IBcK+lNdorcyMVVD/T83Y24iWse2U++il1FXd NtuOdV1ZuZVdy+PcqSVPdk1PzH3ezctCrn1T+KRS2viMNOHWbk0Tsj1eJXXbx20It9082bXLvC1N A31S3IXeObzR2QNcB23T7yhdoDVc/R3caSHf8o2NZE3YkMCL2IVd3H1f9YxZ9YRe3h3UH+3YvoCW /YAWuwFf4gXgC21d5k3fu2Daud28oixP8dRR9n1ezmVOYKRHb4jcdfUL7x1a4c3gaUFdDdbNooBb HW7doswLcLTLWI3ZVRRhIk5hwLiGazCIJE7ij+nRQ/QGKK4BKIZiDobhErLgCubf/y3bGz6JBPji GgBjXANhF17ZhZXd/9nlixv9YfYdYusdYfqtCyRG4oRgYqiZ4haWYiluYW+4hT7W45ad4P0F2hjx 38KNni6miQQIY0YuJXhIiEd+ZJPgC4R1WnQliqKQ2iIeYREezzYeT79gYjp2CDv+mDwWiSmWYkpm 2boA2UH+3uI15P1N5JFY5DC2ZTD+YluGmkg2iF6Gh15WV2Eu4LeNW56YXwbs5OtNYTb+izlWYiVe 4mf2mFTmY4NoYT/24z7mY8mdC+JtkQwG51gO2kKm5VteZHTO5XMW44+R5BoA5neW5F92Z1YOZAE+ 37dNWM1r1TVuV1XE3X/ui2l+ZmkOiVJWFzw+ZZ74455g6BdeCv0oMv9w7l85k55yTmR0PudGTudd Thdgdud5lud3Jma4bdoPTt/L24v59eSVXul2deBQJmhpHuU6roFptouH9otqtmZANt89tue0IORO 6daxjRtN8V5zNoh0ZmRdbuqOVpdgbgh4juRg/uinFWBMxuQP1osDlt8hBuL4BeVljmOnsGM6nuMl hma1Rorzzem/iOKEyOM/3mOh6GM/tuKQQGo1IeeEMd6kZuqE0GWlboinphV6HmlfjmeHqGp41uGn bV5WntvuaGZP3tNN/mqyTouztmma5uyGOOibGOCmDYwo5ulT1mMqbujSrueg7utmQ11C3pSLpuWM DmwxZmd0+WiRjmf/eFZsetZtS2ZZ83XZ9VXjN/5qFD7h487spTjrzRbltE5rm55uozjp2BCMU07o a07YbMbma/ZuujiTCz4osSXcWabtjbbtXRbs3EbsqJ7qxE5skHbn1+XuHH7sqL1eZX5pOO5k5GZu pEBr6l5raDZr0A5t9K3kvkjlnwZkPVbtnebmVpblcRZf/i0yadFg9sbljc5oD2fvWjlsX65q3p5v eX5kSr7v7pjsEAZo6/XnF6dsZKaLgv7sAbfxm9YJyU1fuoDr0ubj0/YJbGZwPG7lGDldcXblQzZc AHbqdRZsDm/kW25vqhZpK69yqT7jBN+LdJWN2N1vsP5hy+ZvAE+K/1IG7Ron5VE+cJTo8m5+64ZY bbjW5qxm8Akn50EWaj2PaA1X6lx26vUebEEv7CXpbaoWiUM38RJ/Z+tmXgLm6vwGaDGH6Zdt6TI/ ioJe84PubOe+8dBWWdKO8OyWc1Uu8u0Ob/8Vb9l2bZ/pYtz+c45malwGcT/ZbcRebN+26jbnbi2/ 78lFZlDm5GbW77kwa8+O5ule82iW7k8fbbd2Crkm8tOW61Jf6DgPb38VXzMp22zf9hte76b2c1nX aMCudUjW9UPnbXVfbCyP7A7u4BeP8VYM63nnZBcv6wLnbGVf9jTvbJx4c9agdiA/dTv/7iBvitgG WVjWdlj2a/KF8v8OJ3dxV2fDPnf3PvH4du+L1/WrdvTR3mSQT27kXmZiN4hDOISkOPljr4GTh26X r+PoTgqAf2s7h+vt1m7UXm1BniPS1TDYDllXl3I/h/jALnfc1g4ASPqkPwndbvoRz/KRxnhDF/Gr vm6WVfnjHmsHZuaXHgmsb4ivZ3mUJ4mwN/mxV3lRhnnpzvGTOPmyD3iB/+5TN/iE1nlvnuij5nmi Fmcmf/hZl/UoJ3RCt42lN4jCHwngNvSNl+r3bveoFuZW/Xqp7WeRf2MgzOy3D/u3B3uUn+aWP3Nk V/OVp4nNx25AtmYfB3Ii32NTx/YlZ3Kilpu9Pt5wJ+wnt32h947/w3cIpT/83gcAeFD6d/59AIjn 3zf84w/+4q8B319+kXD7sbc86E8I6Mf66jd7t8f+7HcIzT/76Td77f/8lq/+Q5hj8k/i7zcJ67/+ 8J8L1P/pUffxnD/4v+hfi+55REZvwF9qwK598AAIAABqECxYQ2BBhAcRChzIUKFCeDUkPgQAD55A jAMXJtxosOChkIdAHtq3L+TJkjVS7ltpskZImDEJzpT50SZJnDhjhrxG85DPniKvXeMJtEbRkTNr 3swpc6RNpk2nUq1K0FtBrB+9cTWotQbWr1bHWo1H0GzBeGrPnlW7tobZuG5vHqhL9i7evHr38u3L NwHggoFrJPhY/5jgYb+Kqyr82BiiRY4LNU7kKPGixswUB2psbHUp1JkmWf5s2fKnTp1Sn4o06tSo z6Q/kxKVSZuoa7ygc65eXLWr1q5Xw3r13TeuQeRz4SJn/pbgAYN27Rqvbv069ryDCXNHXHh7duOe O5KfrDljxomQGzqMLJn93d0/Udo0Sb91btT6DTLNv3smbVGNFJRSR+0kElnyCRjeTcFdNRxxX4kl HINNoQVXcnKhpVxy0UVXQ13TTVchiSWaWFVgiZ0Y3ngEPbZRRpRRlt6MFl30UHnwJYjfTa7ZV1JM LeWnGlT8FbmgfrChRhuAruF2ZGpTKTgkiRSCRaGEYVm5YlpvXf/IHIZhPvfliB9CFyKXaaqJnYpr VveiZO/BOCdl6lmEUGeaxTlei6nlZpSQKN03JGhQ+lnga4gmdZRQQD1p26IH7vfRlIhSaqhvWRJ3 JVgPunlTcxt6OWZTI0J3KojUfboqq62uyJ5HsJKXGUewcrYQfDTGWGd5lxo5X5H4hcajVML2eGSh NSX7n4HLDqsspq0RCeyw4WV55YSbbvqpqM51e2GIZhZUJohnunouuumqiRlBl91460eYsXtRZQb1 eV1vrdaGFFH91hYbQQRSlW+6gCXA1cGdYqslVw2j29xHz5Ur3bjhpjruxKv665O6HXuMHbvtplfZ vO2SLK+dJhL/fC7A/CLFL8dROvXxYSl6813DwonFqbpuLUdXqh5ejLGHH6K5Zr8wx/wx003fJdFE l4lsI8pRR101yff6xqPTHMfWMmuYOo0YdzV356DDCo89lrinmhmuiG2TmHTA+768Nt55Q20yvVP1 DXXIgedt4tf/Dn6X2TVjdVjahwMdNKpGQw530VzSTXfdjmuurrx9X411yO0CTu/em5uupsEpqljz wTqfXm7lQmOcsdCSn7jvxmC/vrubgBf0t+h7S/37yaXzfnx4rHcnGPIfSR575GiqKnuJXn/tstJL f2y73M2X+Pe7pANfL60le3++ceARlnqK50t/pqlFV44q4V4H/3w3zPivLX/36DMma1PmQZB5EJB0 URsZ+OIVEQM25R//uIkDI0gQBxqEghOM4AP9N7bEeUd13VGf6d4Hu7hdTFUZq57dcHe/wjXNdvTr nwZ7FacBCrAGNSQgAbNGtc4Zr07uoooFCxJECgaxBhYcYgZjSLPvtKl9TGzf6yxmwugZbX70y471 Xqa9zcXtaEqcSp8QMg+BEBBWY4yRrTrSkAPeSmsYFGISKxhHIsbxi01LDPs6uL48Mk9z8qPd0Kp4 xRNi8Sb2S1rMtoguEZVQhHa0l0cg6SIACHCNDTkjrjazp8iMzI0SvGAD5/jAIj6SaYM5pcH2WDbB QJGLXpQOdf+oN8Xw2A17VFFkx573NkI+Mo2VXOMkbUjGM9KqVu5Bo42scsQMkvKCGKRjKfG2Hfap LnVlM9vg/kg0L+pSkBWy390OeT1bLrJ/MIymY+ZExmAupIyUhJOuOBlJIDKzns4cpSiNWM9motNV rPMgK5+4RxC2MJAvrNj0YIdC/BXueuNk2i7dZrF+FuSM7nyRO4PZyfZ05F1keaY94ahPOY5UpBT1 p0Ge+J31rbKJBIWoQmknwoSe0zq4A5juVIjLNdG0i5NDp0J+mcNhsnOYZIRnG+UpQ5OCsqQjLeIy mXpSlK6UmkwcKNlaOTZtVlF2bZvlii5nuIee64+MLOEgeyn/q6FScoBifGt7dNQZOLHzI1BNIkid 6tS8TtWfeXTiNfXI0pXuz1xliiX/EFs/7CVyhfdL19Eiyz2w2hGH6cwhDW1oWQHWsK+e1Y5VPWjN 0QZ0eVv1JuVgWbHbPbah/6olZM8qy5pWlrMd2axmcYjZ3X62t2NRKSpZqsqUXrVNMI2sRGNJF9oa J3cPxanHvGlQxZ6Us2zNLHYtq1nfchdFehRtKvFoWmsWdpe1G6H0KLtQf7U2uqvtJvymalsb0ne+ NzTIDTHb3f0yL3Gk9c5gs4rNvL3tvBRL69xSOE72bi++5zUVRa1b391at8Kb7Sx/ubs6q65SuIT9 sHFbKEuZ/0bOTS1j8E5jq01YMhd92pWwfvObQ93OOMManmZKsUq2D6q0w4VFq7kMq7HXkhOmB45e X+ebWd5ud4AV5V0+8oGuKPsPoAL2cEs/LNxsphdyeKHyelPsXnINra9mrLFubWgNaxBwzTLG8P+a kkYwztM3YC5IlPM8lTyDmc969vOdb9JnPuOZ0ATxs0H0fGgpN4XQiq7BnRENaUlPGtEGi3J4AQ0Y QDM60X+OdKc/QulHU5nTgqZ0oc8UZaOVutOgTnWGXzm5FvuPqI2RsDVqkGs2z4PXvM4tWcIYqzoz CNCThrWnkZ3qQFNl0Mt2tZRffexWV2XQ0F70s2Ed6KtSOf8wYN50PhKAacJeU9yMJnWokW3tbFf7 2sl+t7OxLe95x7p2EKborW8rVFmtFYBzBmCvKgKZSQIT4DMsdKCl/e5jwzvde3b4tK8tbWozW9Tn VjS1T61tKaeSO4QGd3C7jdUUWfviGk+2oTPe7FCDOuEmZzjMXW5j56kXqAPRr2SscdR1nvHmOh82 ropKbKRGEkeSrGufDD3viitc3sZuNMQjzm6Gt7riFl+0s60+cY6fWuSY7qC5AfzPsFf65QvHdsqj HXVltzzdSlc4s60+896KsaKYFCYAfs7mNQtk7z8nD12FrSM+cfToB384y929cJlDvfEnfzXcHS33 rKsd5p7/fruxyT5uc/O5MJwmr+Yrz3S3i770qKZ3vOOeeHWTfu4ZDup2xWjRWxP15/wG+uEPT/iD 24rYUI+35Ze+esdf/fKsj7nDJe/4kgcf7cPfcbfH3dJW85F9qX+0sqVe9uYX3+lmR73iVX/SZ9SA /OQvv+vZKeG+Z7TvuT7jmvle58APff7zNPpS70JxxR+f3t0/u/g5X/bt3/JdnMo1HLIxUeaZFqZ9 XY6x1PWN3tUxn9yxnQFiH/fp39qhz/mhnweW3zOEoOvV3c712iWR0d7VXt9pFO4J203s3u4hne9J 3dYJnwVmnw12n8qJ3wFuHMLZYA1aXCo1YLitD/WJnTUB/x8G5mDLZWD/MR749R8OatD5VSH6haD5 pR+ukODtxR/8aZbtDZwM3t9GvEMNmGEM+puO1NXloRu6IVzTYV0FlhzGYR4GNmHXVR7WweH3VV3n iVzodV7Z6Rm3fdoP/l7kqd3pDSL/QSHy3WApYaEkmh8lgqAIpl+FTVgm9hpnsRlB5FpfmKEomuE3 vIMZnqEpVkgFcskq7s4pbZl4veKOhdeW9VMrNk8WWuEl7uIHup5tzZebWdevtdkn8sUo1sA3JOM7 lOI3nKEzFtsGsmI08s4/PeBghReOkRs63aL3TGIHEsQ39iImplmaOZlugWIxGuMyNmMqkiJBiKIz xl/8Nf8PN26OE1VVualSNWqZLU4j8nQgFhZEFfKiJGohfdEXr3GiJ4LhroXiMsIjKpLiMiLjO77D PF4kOhok6tDiNQrUjjWFVmnk4ADkN2bhFVYiCGrkr4HhdvUaKDakMb5jKa6jKdZkRZ6hNZjirr0k OmakSJIIBwkYNgLYR4rXT46kQOYiOCblUoqgU2rhS25WQ65ZQcBkXtSkTSYjRdKkTlJlTs5jVRqE Tx5l8gSXfw1XH5UWWaZLLSlSLj4lSRrEQIqjjfVk/CEEWPqFKWplKSKjMrrjMn6lrtVkT+paVVKl VWhNeDhDDTDmSZ3lPg4XNoXkWmqMFiGSJTZlOFqhB+7/4iX6lsHpWkN+xwoiplj+Txql4kw2Y1+m Yk6iomG+pmF2xFjSWToB0wuu4V0wJm/2FRTdo/KQ1ktVpppgJuZcQ0mCo0leIXN+4Gd6Fl0dJiu5 307m5VgIxCmO4kzC5inCplaOImKComJCUq7gnuGNZ0E45keoZz91HLl1XFYRJXEaxx8QxB/cZw3U p1XgFAu9TAj6xFMqZ0oG6IA2JX95xneE4QrCSq6JoZxtBDvCiilK6DvYyoQOHns0aP15RnTa5lg4 Q2+CaGNO1TSR1wchoWnN517cJ4saRItWxYldTsBgIXIa6Gc6ZUAuJV1yV2OslEAkgPytGWAEqYPm JkH0/yU7fkNFWKSSAsBD9h12aqiu4SUbqlHRmaeHkgWI9iZBsCc6GeWJEleKqmhf1Kd+2qd9nqkh XWYKrVBteGZncuZbvuV+rceP4qXeyaOcaE2FOik8JqlANClV9ilOYmeU/p3eiaZp3iYk3QI7OSp5 zuB6dqljVupH0ENBYGoMDec9jimZ4sWLFoSZjmp+5id+FoThtBYi9ctcpiRzFiSOFiSPIijZ/Kj8 EVzB4eaDducWBmqg1mTfWaSh2oqUFuOiRmoN3IJAOKqyRhKkGp5ViGhjiih70oOmaipBYGuVrQ6K fqpi4GeLgmtT6Kd+npj+fAR0ESidCuRJHmgkceuPAv8GlA5EYdjp/2Dlry4EoZphovbpz6ViMbqf os5mOhkTpC7rLTzrs+beVEjrljKmtdaAtWJqxEqstmrQVfWXt/qFmpYquJ4puZaqyC5YqsIMSsKq XLLrXC4ndL4rKxEGQiSAJQFAvXbogxYEoeJKk5ZiTmJnnzqpzyaqQtwqnTUrRyQsQhit0VYpVVSq pUos1FbsxGZrxW5qPm5smaZpqIqsqYYsi/5BFmmP9QDov+DogN4ou2Ym3aURLcosrNQsexzGePrs RKZRsFpDKVrozzaG7RXrbTZEwjbrGjkqwgouehrEll5q1Gortl4s1rre15qpqH4t154qfoITQ6nq M5T/rIFqZtqqbIYBV0stTxNxxKieakQC7F5OJDPmGlZq5b++Y1h+olde5EcsbeBCKrPubsIma7Iu bF4kbqZGLPFCrfE+rhaGKql2rce6qKlCV+64qQopp6wGJGcK6I5+Fh61bTWKnUAs70dA5Ou25jfg rUWe7yhSJ+1Wp3RSRYvsLkHk7u8WBPD2xcRe6/FmK/KmH7l+rMhSrtaiacDUZ3/252XmKMqua3OG o2+5Z49NZnF9b+WSq/jKJGzmZE3OpIS+ZneGp6LaLv32rgjHr++GcPwqrHHc79ReK8Va7P5mWP/G 8OT6b+WW6tLoVJtuLlLooo724kA+Z3cZJXzqo3xa/+7k4qxNVqREoi+/RuRgYrBr1m46xqZBKKzu irD8lnDv+m794gXx3m+mRq3+vjAMMy/4mqqoBvDkXgMBsymquunm1mgCU2KsZm8Dx6KOveITgSya fqxNZqcF+2VXiuKu6WRXUrGxHutUMOv8ljD9/u4W+wXFgrHUXqzjknFv0bCahusMzzAbP5dx3k8c 6ygDy6klMnAQv+cQY2MCbHINMy/OPqPsrtkp0jIG07JOzqZViibBkrAWz2/g+vIVj3AKrzDVunAL Y7KNuXINU27HomqM5s/d/KdSWi9BUi8q33FVFZdxXRUnn66aHiMSg+egoi8uu+bAvmQ6mmbuZnEj 3//E7r5DwrbjXrQw494E/iqzb4EzGjvvVIDvqmaPy6iQSdIpD9txKnMrBOMjYPxBK6Ox5aJuLGfn KBLmS7ZjB0+xV7ZvFS9yCOsuRt+CKDpqEpPF1OqvPSuuPu/zuPKxT/TvR4gr2L7WcUIzxxi02W6m QeKYd32HQxux1kZuSStxPFrkV0Lx+eoy7Sp1OgbzFg/zI4u0KUo1EsOmXtxzMhdvMq+0Z0k0AUfu V4crH5erjGZROCVljopjHWthcY0u2AEYHwc1J3en6jaxbBp1Uk/lUodlbToy7z5ystKzM8qzPD8j RfMqVTTu8FrsF3M1S78oUcw0G7exWJtxfrKxFhn/xE3ZDS+6akEj9H5tr1BW00Atb8imaanSM2K7 Jl3jtV3yMi/3tVNHdTDLrm0TNiqK9DjLcmIf7yQ77iU7NjqJNYtO9uVOtst8rP+WK0PdsFvqdA+L 5H+NV479dBpfNwCPBQZz5/mqc1PoqXVy8VM3MlXXJFUHthPHsm17sRjjb3ALdykpN1IYsXHP92Vj t6g69xvrTsqSMvZWJj4W5XB5bSfDcuoOtm2fs0VqtCJvdF+/MySb4TzzNnpPdVXLLmLjs/GmdBjD d1dfrscy96hiNnL785ke0mWOBQID8U+61HcFmORCNMhK9E38sTjj5E728sCucxXDrwlX+BmKdO9i /6V5DzY8/vFYuDdje/g+g+snf3LdgK2UY3aIA/Waihkmc3NRgmlQozbXToU453J3M7iOM3WPY/E7 SzhWoreQr/lhA3KGN8UXFy+Tf9Z9cgwBI3dtwDTqxnid6wU18Rh4xLDknu5YYPQFyyNMerCeLjIx c3GQqzlJlzCRpy7AGnacV8VJ/3lXz7eZRnZEz3RxQ/R1czqgC1ZMd+2M0zhesO+iK/rsVsV4Mytu y7OQO7FUR7JBULSpEyfYOPNlS/nlAjur93pP1+K4prGf9wWjS7E6P7gv/7hVBzZhH6OtJ7GbH3mm G/sy3/mLgm3zFjqJyzi3M8hpPzOzf/Bem7lHX//x7wp2hOs2hgs2nBP5tpd7d9lNoXt6bIz6fXs5 vpuOFE+xVehuFdv4rWNlm1M7vc/7vQc8d035x0a2XB+3uEL85jQ6tDt6JOu2rad5pJ/3bfN6et8E Apw8xnvWk4s6qKOquGI2uqc8OmWxvGN4bpN0KkLqmtv8zhsEAtTAzxNE0Mt8P1E8lb/0pwt7v5w2 0VMUI7/7VF/7VCe8kfP2jVM40Dd9b+F5mu55sEu5fRe71pfSkL85zr87dxo5ktd1d548yqN8lg9n hsUMuPPLnXv68449d036SL/jrTM8z9O1Yae32wt9QQy9t0JmiM09NNu3GtOw3vcWrRP5PNe12tf/ ONZnveEDPeJ/KocF2E+C9bDffeT7VtTzfZDzPURaumpP++FnPdwnPh8ZhqfyF5G5PIgXWelPlYSz fpxfveBb+usbfuxvbKBvs5ow/dhsNn+26e73FkZn+uofdtpv+9tzfuJrbJYhO4kQe8yzpaoqGJY/ Pzpdumqf/7yvN8m/fuF3/ooUPva/jmgHuGEsvnVEbql/P8vUNFmRv+kDRI13NQQSNDgQIcKDBd8N JNjQoUGJCBBItHgRY0aNFylSrFGRIMiNI0mWNHkxQYIaKlmuJJiypcuTMw3+qfEHJ0GbN3nS9Pnz 4rUaQiUKJQoUaVKlS5k2dfoU6kmIBak2FOjQ/2rEh1gPWo0KFGRFkR5DfjUrUeXLtC8zro1qE+fO m3B5wpV7Vuk1vXuP4vX7F3BgwYMXKvS6kKHChxIhaiWMsSPZjh/Fkn2cFKbLlJo3r435NOfdmnbj XjZ9GnVq1atHNuba+CrWrFdjU2VNeXLkj7tF3qaZGW1a4W6bkp5rXCdd0b6ZN3f+HDpDxF6pO966 2LfYkJINTo5usTPbzi1hAncqemfoujl1fnf/Hn78pwlfY98qe6rt1JY9Sq4cNj63whNPJuLOiyu0 BNMrbTn5HHwQwgiros0i/Lqybz/etOvNIu3eyyy88dgqECq51GOvPRQlXJHFFp87TCvDEoOOO/8N OfQwwJXI01FEzUCrSyP1jlPRxSKNPAsAAFbkarHZbIvoHQAGklIiJb+yciPvcNtyou4sqwFLpJIM s6nhdkSJJjI3UhPIntqrCUyC2PzOyjmPjG/MPO0EKsmm9Nxzpj4N0rPC2BKiLSEqlYzSIkDj9InN ML8US8n/ANytUTn5FPOiPOXcbCUANssT1EAxUvMPABgccrRONX10sDrTfNXRO98TNCpclcJV1588 lRNLQWFjjNgmwZwy0ytJ+jIkSTnEtMpdOY12UDDLS0BWl0Q1j6Rab1I1vTfZU7G0bC/z1lVYbZVQ V17r/BXMMQclNF554wV2pHbftbfeXqucU1f/+o6VE6I6kVU3TnuVFHTheuflV1N+9+0zMj0RYNje i39tWGJ4ge1z43tdDfZUg1IS1UrhRqQWVo55/dhlK+1S9du5lEyV1pHffThYhR3Wud1qc34U3XWf 03deke/FWGl/Qd55zTCfTtrfUwEmk75gEVJ06KQjlrppdcl8OeGyABiLaCwju1jsr6sFO1mwq45Y 6EbJQxlUz9JtOeyya+rTJplxujnOwb8N/NV/8fU78bdJjnvvx7Mt2ujmkMbXXaUX13xxjzNCOvO5 G40U0CgZldJKRolOlu5o5Wa5cVmtrOjsssCkqFJMKW2b8d7VNLd31oHnWV5RedTx87KBlz1T/7jA ZW9hnGWePPK3YW+98a5dZ5z6yiO8fOk/Yd4c440h/lzqhcUXXfF/a+WY79Vhb3h76+uOvXXaOcy2 I4vhph97CJNfAIWXuOKZDFvYetialIe/4GEpVQganPRwNrTf1U195jvg/bRnPQB2r0jfcBH4pqaR EobPa56zmuKc9r70nQR+ksve6+oXwLFRC4C36w/b2Lab3LHtf22DGw5r2KmQFdFaxhsVA+HHuxyC CUE0a0/06FfB4cUveEK83gC398EOxucbIhQhQcbYossVr2ciKyEaP+a1zbVPjWlknxurNrfHWZB1 D9TiG53YMrV9pFK1A2SzPsg8+3GOi0/k4P/yEMZIARrwfoaMJJwQJ6eZffGOOSwk74hYMgde8T1h rIEYxyhGFvVKfP3qmbs02DE4ug9i9FKl1Tz1J6hVT2jDo9cN/wey0UmsjZXyTsZo50uHSTJtilwl KBtJvGbCjJmZ7GQtq2Simk2QJyDEYC471sTs+RGXeHyQKUVJSjJ6Dy/gY80cT0O5auVGN7bT0rSO 5he79KQ0cEInfEpZznKOEqD7hIo6V8POdm6qLDvcTlieBSnouPMndLmIkAT6HXKO0pRkLONFbFED W3R0n/GIRw1EWhKDVhSG5+tWxnCTG8owRYUo3Ug+ZRrKjWo0jDnd6Ec92tPKlZSkJB3pUGv/GiFL baihRX2LNZUaSonkFKMZ4SlBpnonoh6DIMc4xkgJAtSmfoeh8fzqV5lVVFGeE6oBDagIQfrRtoKU RVwVKVHnulW7enWs7uFPXmvaHy4plZylNEg/zdlTtxrWpy0iala1qtWsdhVJMFxnrJRlGoiecouP PAk8uwPYf35WrRiBK0/hKqF4KGmkABipVocq0q3OFahcTddnuvXNvSXlgqbS7ECdckfBgPKys8pX ZRW525ns1bP/tIhOoTpGt3a0rYmF0GmDWl2sNna1NcBqUEsq21HlDYEMNElwt0g58jrUTxwEDDO9 N8TMluRZG2qqcgcbVY1SlarQNchh16kw/5/J67Rjoi4AjiHgAsfjuhOTLcywZa/wHFF2UMvgbWOm 3jD9oF/OTOYqaRnhZf6ulV+b2IYdR77/so9QwPzZLz3MM0+qVHmsdNn4oEk3FccUMvLskFnPCVD6 rnW/h9WvdFFzwxKTVFYiVW2SHLuw1xY4TlxVLXDMlUC25FbCEV6k62SYKQx/uYjI9KIJw+bePbqt a5rsnJj7lry+jXmSLzMz93R2SPKFGc2rm3NGXCpWzy5XsDjFr0SeW9rUGBl71D3tXBu21YRhF4CK 5tG2pOYZLEPShnlUswABgOEafBnMm1azt0Z9PRpmmm9BhOSpjetIRd6gBjcAwA1g7TtO2v95ZEh0 r6j7uGeNeMfPMmWuj2/a4/0mtqoF1fSjUovkki6spAdWLUmh/CeRtkRWaUnZN0FIMjOz+oqdNgiG U0zEVMK43HZGdMLSnWZVmsvb7W71J9toEFqD+93pQveZYydvNrMbxxzhTllrGujmolW0x2bOuiON 2mAtOsFQ1q6045G3mFB60sdLmbbdjeo4vxdMYH4UuXst3o+re9m5dXektqnyeffR3laitazxDKh1 Z5rhFEZ1cZfVm0vNN7QYFWyx82voyc4vykpWclCd3NglP7thUr6WAq3Fkm1pSybiTLWpqdbJaP0A 7CM3phrPjOixc8/spc4lyrGo9i8mMmL/tZ51rWFF87l7/JAXZPWtN2lrvzsKQJXhK7HRmtEHhRhW i8bcoldL4GMiWcAjBVGSGqwrbY9JJd12HLp9KUsQj4ncxtzgiOv9y7+fPZg0HqLoVRy/I759xauT dZ9oHWtYh6z2pI9bHZ24QRenHuBkgxfgfT74+q41rT81CF2FahEEQzaoCSgpTLhaKuSVRy3cimxJ wC5yT7vnvGaBaK1rP/OZE4TusTa+PJM61jIS/adyhX51l7/8istf/jEBUfb5v7JcnQTUCELkoiP8 /s8nyu/8zM/81I8B188B+Sq2IhC2Wkuo5KriVuICK+5MLA55fET7eAsAAxAvDsVXYAxC/xAQ1hLQ 9jAi/R7QBWtKtlprweivu2BLqDrj/i5Q/wiEAwdENQYQMPLjqxIwBcnP9lJwBdGvAV+QCUOKuyJQ IiywAjVQ+lpL+o4HOEJk/z5wXYTQUKyjppCw/OyNDBmw9pSwCdMw/p6Q/iBrsarPZDpwQD6DJeaw qBTDMMCwos7QDFeQD4lwDNVQEFdETeaqApuvuhbMCg3x/q4wONCkDuuQM5aiAM/CC2UDQ9zMcpAi BZVEAc2wCO+NDPlwrCpxEC1rfZyPutywDd3QCqvQq6SPA7OOFuMQvG6rtjQRNQ6mKpzkxTypyJLi 9uiOGP1Q7tAwCR8juM5Lm07xe96rBv9jCxEZcURkkaRkUUDskBZVxkB8BTqog0JgQw+5yDcuqwhn rQ/VLxTlJP1I0SzoQSLg0bbGK72MyxlvhcusRPEATAY9JcD65GQCTPooD+B+L4Myj+N2j3T8S85W TJZ+j91MrHySZEpOp0+mxHNSrCG7qXzy5cQ+LOUcMk9u78QQcNbG5PZwCPFYTPXqhR7oQSNpLMNq yWm2Kfgm7B4d5IU0ZcCejRFRi9Fki9KMJ0kqTn0GRUTU57u2hepqKOeCqCHVSyU757ZMxyIfYtOm MmeiEntIrcy47sgSxvwW5gxP0hOTUFBkTS1R7tsa5SXlBCYBAB5h8iXlEpEIaIDMbu3/0kYqc/Kh kA5MGI8NBTO1qo8oNRC1kkg4mFJH1EyBWM5O8M3WfK3jOI1lUIchsnIvt7LmHEoyTy7ubK9h5I7m jDDW7m4y8Yzr5LFh5lIu6XK3lGkebcz1HMgv8XGSAvMfD1HSnO3aDvNTEJIxlaTyKI84ETKLkknn oFI1YQneuAmYtiZOpHPOXI3f9sUjfc/vQFMsO/Hd1rIBS/PeaI4tH1JdYLMGYBJM5JFo6pI9Z0nl 9s2btMkUb9Mvdi1xlq61gLLZftMotW0pkQdlrszKQuVkHunmJNPtnqkyeS0zrVIgNFN72KwtdXFB n9J1yo8sWacI42TmLvTlCEI93+Yt/2HzNV8Tf1yO2xpI6+zRPo/ukxhvFbsqMZGMu6aNKZVoQK2u KX3pu5Az12ao69bu1FAphVpuSGkDMx2i77xOz5xyzOLT7YwUc6AUPNXSE5HwNJVwQ5cmSRm0Lg1C Pa0EHu2yTuYSnC7NtnyLPl8U/ADT4QQlBhHvtAA0VFRpVEBGgX5Us7DTiOhn+HpPmUTPJg9olyB0 OrVzgYhUJQGVbExP1FDv8XppQz1FPPkQHU+TJB2VUxdSSeIyScL0Le3SYd7y8TIMc+woN2OvPt0U NRSx/mKQAnXwBt3iOCPR4uywVRHKEouFSWYTt3TxMtYRAcvwDDs0GYWVJF6SWdmzRP8volnf01Wn 1asMkbu6ihprlf+uDi1sMQub8tAGIz8cY1cRdDWQVSLIzzTV1R2BcVlN1VnTM17hlVmn1V5VkQ2j sLswUBKx71Zzlf+e4RkS4BnKNaVOqimgBCJhygRvA12NUAXFEBlZsiTqVV5NVV7F9GLn0mLv1V6j MQqxVVarD7x6ZDw24xlqQGBTNiUE1mMjRAGR1TSPUEudIl5FlGMtQh7R9GV71v5aMRo3MAsLhCVY lmWvRWVd1mflgxhnthiVsAWb4lnFtETRdGof8A7ugCCydmlpIgad7xA7MOtKdi0GtmXP9iVS1mVT tmvd41gv4lhbMGqTAl7T0245Nmf/67VqpbWptNZvufZe69NawYNw0cQlBBb7sI9t5eN9lNVx6xFJ EDaP0M8d3bESd5ZnLfZZr5Zv+3Zrs9Zv3ZS9hPXzcAX7wAO8zLYOjZZg13Zx0wmmTOpxcfEpRpee QM5V3tYi5tZFTwJjLxYjOHf9ANcgQFdr7dN2cTFBw0tsebB108JsVTZppdcgXtcApSUXaXd2KRF2 tVcTIXYJvZcmclZENdZu77Zuf1epjndrayB02dcvNXKZlHdyUWItCKU4P0VgRaVgFaZ/waR/400i WwxVDVIkVWqXWpIjLYxhuqiBb0yB/ZRiPYYmZawgwWT25pdWOBLOcBZ9MzYeefZ8/4f3eLkWcIk3 J29JQpd3JKxOLRYGJgpWgQYWAAp2cY9yfyVHwoSoy8iMKxlUz8whLNUUSYf4zXBOmuD0F3FNzrzN 3DpzNjuWaj34fEXYc90Xi923hFH4HhmpQhm4YRMoQAm26lAmZWvYZWu4hqUXjRv0OoE1NbdsUMzB HACgjoVYiCWUHDGU7SgU5FQNcpgYijmzjx+paje2fOm1YzsXpVB4i4sXeVPUPG9OfJXoMVEWjdVY Zf/EhtmYIM4Y025Sk7RWSeAXPpvzVejYjuv4UfJYUBvY9N5Y1TJIURHYSaGzlgf5SQuZTW52Yxn5 ar/KeCH5c025i1PU5OA4MqukQP9nWJMLtnr3N1rY9jnxEgDY95ofBXRlGSzz2JWVBI9BNDa5eS9l 011hLpDBEueemJczwmrxtnwTuYqNz5hP+EW9uLwKNZ0xqGHS2J81RW3VeG2VJI1DWe2yNlu2WY6g NFnqeJUbJpxZOe90aaLfeJc9LufMld/ImZC7kk11FoRDWHNHmJ7Zd5inNZZkMpYNKFD/NE4CeNfG 5IxvmHqrecMQGovvwEp0+pqxufMaldNAxpv7JY+Hj1BX2lBbqcter/RgqS+fxoIV9Ma6CYsQZmd/ GXhDmpHHyni3uW3PRXrVlnrFWiJWlqyTgnhNuIS12J6TQohT2SLeuntxt6l8K3j/MbZZ5RmRsdaE 2/erCYOgw/p1Vzaap3esldYk3teri/dvt5mLgeKONUKuK4uulSp5q/h3g3mrr5iY/zow4EVpxdqs P5m0B5u0T8KxP1ciuDit+WRM8Bi2DYKOJxsEK7uiWrpi7zarqZgJjdmzTcOs2Va0CbuwRRu1T5qt +5qtn2K2a+Ct6di5odu5fzswfJm6r5sm1nasDTtphbu7aWKtGbt9Hftvc9q3S4K2p5sgpFu9sdtm sdq94zu7q/e7T/u7vRuxR6Krw9uvQzenVVsp2Fuu2Vu+Cxy7DXa+y/qso5mwGxwoTDqLlzuLy/u8 XRSPo1u6L7yoWhXBJcvA88qW/zQaNYRbu7mbsIvmfft7i/17vCM8lDMCup87xtP7dnUre8U3mYO1 d3e8L8/Zx5naj3jvw2GUxwNDbQf7rInbevX7kdOavMPbpOHXrjFiwDOcxgGbe9Eryw0WXRyFjzfT Modc2TYPOjtMJo+S7DhSmv13f0tcgmFJp12Hp+M8SRBaYXh6xDoYTBwanNE8ZBY4ImMMJJ06pioM PnXP31QPgSsYImcslit4fqeczujX5tBIcsUcco/YrjOaaQKd0/p3ZekHmql30oXGb3caTHhai+tc U7hWfY73OTddgCXZwjQHzbcTzPVuqT8a3zJaK//uLpda1+ZRz4XUy20T09dLif+XWYlXDXbW/Mgz 2Yatl+fipIR7unVIuX2lJs5hHdPMGe/0+InE2Un1bpqQrteXbZ95DWD0bdjb/e1C/NhvLdnvs9lt udm3DpcFmlGpvakTh5SxmXdIudxO/dvD3IYS/ZR1mYgtc5bRXZfzbd0lvtohmImZPS9Rr5AavsPr HTA7iIXdON3ZGJRZjutMuJQRuttb3X2zOadLuePAHdeRWZA/M9eDtEVHnoBsjuYzZd7xGYk0jJd8 vn4dyePtPTf1nNOL2KMfBZQ3OXk2fbl7WtVdHlZ0GuWx3tvbzl01c0rHvew4HuflBz8Xuko//uaZ Exjb1MhUFOhvfuKPHunpLfb/DLL14o2qsxLeOa8jrxnmrR2LmdrsERTIlXqBwJ5SCb+Am/N8jJpT SWzx3adRnRh9XsjxlV54qOkyC52W5V6gyCv8Vly8Ady8FdvFfbzI4VjHPd8krI8bWb+mlpEp2tr0 ozzCFzvHe5zMxA/2SYI8RIQLe99oZF8p1jq1o/yEnVx2UX+4ardhe58OiTb4hX9pT9q/yZuYFbvC qV9ChvZbE5e2uP9ljf/2S9/2cV/8jWT/bNEDwz/9PVatH1m8H/v0TwO03t8nJJH9QUT7uhH/AaKG wIEECwIoiDDhwYQMGzp8CDFijYUO79SwePGixTsbOWbkiFGiyJEDvwk8+M0k/0mFK1u6fAlzJcWY DBPUSIATgE2CO23ivMnTIM2hRIsaRfgs6bOjDGdKdMo06sCFUAl6RNhRIMiPEas+lWhS5cywDqtS /Sq1bFqiXmn2vJmAos+gNmfuPLuWaL0a9frmTbt0aY2kg9e2bXj4b0y8Dbdy1RhSa0aIidVCJGsS gEqVNTgjNHtS8cvKohFLnTtV4E7Vbyeuvhu6NMm9fP3api37ZWDBBQlHPQggeGjhE4Mzpmp8OHKz yU8mB76cYvPiUI0Ln25dI8Hs1AFYnAmcuvPn4WOzNIi9uXSBnLlzH3+dePfU0IUSf+9evfj59OW7 Tx3bdNvpl56A401VYHVA6f80HHV3GZcThD5ZB510+pmXll8E0aahbbmt5BthvOXlX3EANjgRhvWZ d1h5CJ6Y4nrrCWUiiqF1dNBW4N0BXo0p/lgihjTCWF5Kmmn2Y0qeBXheiT3GyByRP0oZZHUybjfl lULap6WQXcaIJZZ19TfhQHeNaWZOztGH5YxS7cUhnHAWpOGHJPEm4mC7/dZmmA26CSaMajn1pI1b htljoRd59xGj300ZKJOQRnoelex9c2SKYaX02aGMUXqWV4q6qCKkn5b6ZHjlkQaqqUOi6udUcc16 UFyqpehTXTmttiCsAJJagzfBFiVnbQLdtiGHdko0IkF5NjtUorGuCN916DH/99yrqfonH6JtUmjQ RouGRGq5krJp2rSYdnYSppp5Fha4k54L5X+iDpgdoeCm2ml/9kZqYLWuKnpgd/G9J6tOCqO5q8E3 1QqUmgPL66I3wloskLAw4dYXxwh1bOyyECmlZ8l78okurIAeOqm008bacr8uN6XtwN7G3GLN77Zb ZEn8ytxnp/cKGnPN887cJ7BFG2ouzQoOaqtOs5ZZq6625vqwr/ZlHCzGXLckp4fFduzxsSJHFKJS eJJsFNIuf9r00ta+nLKLT7v9qs1r/vz0loRuty57q3a2qYWeag3kvKWmjPiperN44sqGz9xtlo8r zqBrDZ8068NUvZb15W5e/zws1xqvpCzZfNWWetlnIyXYbrIPFNhRFF97HHxeVn5gdC0XiKCo3fr+ mXrAxx0wwQ7zx996ZIln+LWIYqf479zedyGLo+oeOb4KWbut0gkGX5WtoakJm4OZE7eagMTHZjHp 8Z8uUtirlx1nncZ6+LpAtfvmvwCyrX8EhMkBDlADBBaQZSPhlJIcwqkFSnCCEHkLTi4YMdQgpCe8 GslMMKax+M2mTiDrEP+UtbqB4OZ1aqtdYUSUJwrKECIKVGACz8aqiERQSZzZ1Ax/+MOfsIaDGcQg ES/Ywa4kBIQhHCGy5lSskOXPbCsUWYgKQzssQguIFETgAWt4wzDaMDc5fP+IA324wwhycY0E1OCt hMgrIcIFKHP04EDmV7oQ0u8hHWLdsVCoQrOlcE4FVJuennUyNk7wgALxYiMZ2cgwEgUBNUAAJe20 qR4qcpOvgyMS6RjHn4gSdC7x2h6/NpLbPHGV+xtkFVlYshcKcIuctJMNIflFMeJyKJbs5SUF8kum nPGB7FpSLY8pGyPKEY51BCUGiXI6EUaEkFQcpB+nmML9vXJZAAxgFmmJzNI48pGRfOQXxwgTSqqz kgNZZ1p4iEY1hnOea2mNmTYIl9bIkSZMlCZE4lRNQYYsWfdrpQQNuTY2lvEvAIBkirx4zhvmspyW SYglGdJLtMSEhzJ5XcD/PrTQ3HDwNUSk461MahSvlc6JAh1oCVEIUP2dzYXejCUQ2xJSmhwEojtl pE9r+FOHVqogl7xoRiv5y2AONW8M4SgDb8bQpcpEX3asngQ9GUdnopQpTQQb2TgGRWqecGwUjJ3/ wEnBnKaloZDcaQLPOcZcTpRmDrkoO4F5V8osy3FSAQ1MKsc7y6g1mayJGCjzedLEng2QYSNhFKOY zW0ScERoLYq93ocv7DlpP8trCoGuJx8EVuit1jmgW3eKMOVYKDiXtI4lR1s84202QQqCbWZtm9p6 kS943NPdfyAXtEBdNjq2vSpi57JPUW51gTD9o0D72MrGZpOelvURwfAG/yXGsYpaLjrAQhQoHNPe ciLepY8NqTqcXwKnqNDpJQCCiV3uuopLREOOdtFTX8thTmuSs5y5qrSmp54tiYdN4j7799INqZB/ 050uyBpMXZ3O10vBTRx29eoy0U70u+V9a2i82+Hrtsmu702UL/9231YpL26/qjCK/Xa0JnlLVUAL lYvpNdi/kHSko7ynBJEVyAdHl3VCDmSEdZqv2764VSqGGe7+G8meijbKpi0teYm75AqRx7Xgge+N m5zfFaNKXlJaHvVkdjsa02hw8V0cEJ9pUiMqlrliDfL9VJcQIB95NF+mK9P+rDxLoUvDuXTrlQuN Irb6OVAZfS9eEdDll//x68Iphiql+vVnS7dYaJfWL5glFWjj8uSIcy5gWO88UCKXMLJf3TOf90a3 yDUNygHu29xsFNqHTlnR4QVxAkVMH3VCGtLsJPZ73etlWLeYcrV1MtwmzF+7HW7CKwPupxMH7SAq 17AH5uKqwfrcP7Zapq72IPhw971VUS982JberG+tYdKKNjgdBjEjc0tm7kDaOJQ8tt/mhp/5Zmtr ROMskJKHH4AP78UIq/Z+m+cn9yFz20B8MGQZi79Wl9vVfB2JI9E5zrmGnJwr8WVSi/0XTMmTRBtv uSJNaGRBClnP9nP5PJXmEoiaM5IfLydQ0QmRpLrz5HbtazEJt/Lq2nz/6TNU3WMjW9BkAZLpisxt TIQqUQ97+KeSBHpdhY7XdorddsZ5YCaTHi2qq/3HRRY3kQP6dMmufe231PlAcDleMLrkqGH3ZVE2 Y/bnsWfuhHc5CRfsxwU7Vn9yL7zNgfrWj48z8jz3+kiUynelumQzl+L84C+FdMdHxO+ip/OpXVrn FTa+9I+Hqxh5Dvu7p9OoSOX7UAS/w6MTsyTGZH071+lO39sJskG++NSjLnyqi3y8BBEq1vde1Npr /iWchyfSnzdMtAs/+NNPvmJgTs2CEnKs3id8UMn5fNfzEuVGUSNmBo+ZTBKk947XPO3LnxvVixv8 JsQz/pVvTnHVfD2n/0jvB3pnRDi8h4DJZ1TCllf/VxpVNDaLV3wQqHaQhxA/Z3dAJE/v536aVEwG 6HtHlVHBZ4F/AUVSRCf6t3onuGcOJYDnZ3kzJH/DVBLskoDVV35CR3ouKBoeM3531nY++HiShH6R N4MTZIAO1Hmgd3Tzl4DbZ3JhR4T5R0VTNIRVyHQC2HxGyEVM2IRRGIIKWBD0J3oNWHtaGIEy51hq aH4TJVfIBIKfh3s3+Hmh531F5YBuGBXmUAN+6IduB1186HhwlYQ0GIVmB4Ue+ISKaIZqh4bdR4gt YQ6AaIkCAYiTqIlfCIV0SIYhCC8LOIIlWHSbSBKVWImYiIp/yIqBaP+KawQSV/F/PlSG1ieKCMFR jzh3eviKK+GKqYiKqaiKrdiLMySLkQGBPaRJtJiDOJhGxdiLqxiIwEiN05iJ0DhBHiGLFphG8bck gAd/vIeNmriKCFGOlniOpYE148gQ4oKMyUdMxgSCTOh57seOy9JtQPSLmEiMxHiN06gYckZg9wgZ +GeL8PSNYpiDoUiQaTFKocRJmViOrNiKrviHwmiRRaFcG7lcvegY2piMOHh9Yah7i9iMDckUpFZY pSZD1RiM/IiOGTmRGvlJ3NaQsagV7+h9gbd7zuiBgeeEKEkUFLeSWDWQ/fOL/yiNAwGMFwmTUYFE URmVNSAPVEmVVan/iTg5ENsIj/PHk534hCMpeEIZE89Eceu4kj8kjBS5j2sJk9doFGbJTDghD3Vp lVWJlVjJh+KSkycIL6B4gM04h2TpFicllUWJlkcpMvt4kTL5lExZkUeBlrdSlXIkbPKAAHWpl3up HX55g9jniSLpVHdImC6BGnCmQcqUj2fTlpCplC9JEE3pkPlkl6qBmbdZlb2El5PIl9wohvFYh3/p jKX5EjvGbaSUK55EQHBJkU9JjfzolMGYkcU5apSZAHVpE5mZmxeFmVSpncRJeOC4kDU4jyMJni3R Y4VllDXZkYvplo35mE4JmcPolrVJEg+JGrvZnbqpTprZnecZnqE3/5bCKY4KCaAVpE88llV0oZiL KZ/SaI30CZvQ6Z/FqUHycJ2VWYLAlJvsdJsHWnjg2JODKZIgGhHsmVwZVEfJKUEYaY7D+Jay6Yp5 ORCaeZ8FcUGVeRMIkKHA1J91mZmSaKI2F48CGo5Dip72hFJSyWOHhZSqKJEAaZFNCaHmIA+VuJsw kZqa+RN2aVcl6KXbiaRLB3gjypBgOKYNwZFuVEQJ0UGrWRrWKJHNSZ/zyZRYapebaaMjYUG1iZ04 EaT+iZmWdJulmKblZqa/CZiH+hCpuY4llSZzhDUNKhpyOqdS6qKQWZXCqJebKRJEhJUXZEl0yZ16 2Z+U9J+Miqi1+P+Zv6mLjIqaU5lPyAWnlPoXMvqejYmr8pml9nmXL/GnlYSZCfCdfoeqRQWkqupy 2GeGr6qsLPpGkCqp98Ser4ORU/qgE2mRflqjeemrEtGlgioQH1qbQYqqd3muyrpxZ9eIzqqu0iqQ WrWiPsaa0Ymt8lmRSRmIeXqXeeqpK3GdxDqoXopUBNGAuikbuZALArGwC6uuUlGeD1tBDMqmCzpn bFpAABmbMAqdVjmuVwmyIdsSFXqspAekJIiXmakYDauwDsuwLiuxqpqrImVBiOlMpDapLWqvd/qS UwqheAm0/UoTXqqdJoebRZuyD5gWLquwDFsDTRtOHyVDOSYbVHv/TDOxlhNqJ8qZVY9Kq9tmq4rB mOkIpVD6nB+bpR8LE0ELfMA3qBx6siq7tAMBsy9rMFbbNumCMlbVUaIxNH6Ft5x0EJcKnYM7WGql mtRqWNMaqYu7nPoqnUuJr5borRVKFEDboePqnxuKtAnrtA6bCwDQsE9bdWu1t/0DuI5HEVLanH44 uNOpV/eJouk5UkVpmBSkrwmRtfC5r936r8Bqn3Hro4Nqrr70u0bRtHXbsk+7EDB7WUJjX9yzIlan KpqlZcqBvdYlW+p2HwanWr8yPgXDPN1zcDLiPvkCWun2PtMbKumrW55mbcQDAOZgHKlYvydBv1uG LfJ7orGaWKlZ/51d26KYmq+6ursEoZ9GwbbemYbsF3bHmxD+4A8twbKfC7WiO7qh+y2eVWsTU2Yb DGogXGuOkzuJIjkzwmK4lm0orF98Fb1MJijb0sFBIsLSFnH3FRyAOL8oXInPli6h5qZTuRPWYA0J YA0DQcTK9EbNlLFt6ZixObOKkazCSqjn+qVXCcEDMcFbPMEjAbpM+7kUQmuV8iUs1mybhjSedjc4 DDOT5mxLE2NfQi+blmkxDFVlzGnLxhJqtrpjPBWui7/2K1im6bh0RMRwccQ2ccRxpqIiwZxpMZ1n 24+yQaOFSsW6SbyG2hBd3MUwAbVMG7ot27RpfMOApmR5HMKMo//GAuNffbY4Wma9y1EtZ1y+dGxp sLxkAtc94XNrFrbHwkUh9NuK87sf9NvDrktm5NNxCIqcNVDERnxBSVxgyRm20kmnR+GzkemPUZwW NNqt3mlUHfqtEdzJNSDBAlHOEZG8TyvKzJvBlzMkeAzEmfZsDJdi8tzGM4ZpOPMQNozGMqbKefMz rczGesxpgxOdxNzDsWm4Cy3MHVtmgwVni3wTR1zEiXzRzgxnLMkQY2unRRGlbImO/aOnRVtsHxoR XKzF5pzOCeEDPvC57Ey3ghLKAU2+1yZmfFNhqxw9+GzHBo1r0hZolDPHOLbCRuMmY9zLDhe/2/HQ +Du/gPzQxAz/bDWiKEmooA8JFBldxJEattB5iSMNuzQR1rJJ0iLLrXK7pxJxzui8xQ4B0zXgA8qr vM2bvL9FxuDbvZn1y3SM100NPS/CvzEccMwzcOG7z7KsPbE1PYGVHzRsvsdDbXoLHsmRv/WLzIM7 EfarZdM5cFbtc1wXFKxh0RctzUaMyMdZzdcM0WLL2q+DuXuqn0HbEufc0gLx0rmdEMsr0xTNzlD7 ioE7dxThDjXgDsetUb4I0bk7uWEdERjIdVy4xIfZ1V2N2on8EmfromZdePyqtr3K1ujM0m/dEC89 EDBdwe38tNaQC0S8vKMb3JM4E8VN38VdUS4h1lCcrRHa2hmo/4Fbh3duit3QnNGTSsRdXcgOEbn+ yOC+J67+OhISzMkSPt4FodtyDdNx/cnrPLpHnLx1K99L9w4jPuJsgdwCYd/G3c/4TaVv+dr/iK8O 4VNZd3cjZ0NDHK3PjBMY7dvtqbtwuav9LXrePM4QMeFvfdsZft7o/eG/fcjL6+G8HbNn8w4EUeJV 7hL0jeIDgdwnnuJDUdb8HaFAbsAPMeNaJ3s0vkGKHM2ojcg+kcRf7eKuyZzcrIkSTuFtbeG4HddM PtO/LcrtTbpSPuV2UuWHXgMknuiLThJaXt9bjuInDtJLyd8FHJ0b2xAE6IWUB0ZjtONGjN3OrNEH btE+3tGWTv/mMwmNXMzJ5Z3bGl4QLcveBMGy8F3oy1Lii47oiD4SX77lxw3sku7rYC7Sly651Sjk P5fmO8fplCcQiYxch2zd0eqLu0rmKGnbcG3e5i3X6/zs7C3K/ODMwB0T4j4Q5j5P6H7uEqHuAtHu a0TiWK7rWE7vImHf9f3oKt7lww4TmKqUHGuprw1yNZ51EGV3lrfj0j7qz1zqI9Hi5tiaQ6rkcT3o Mj3o4C7ui9y06P7uEKHuHc9J7w7yCCHy7q5I8q7oh67oAiHvDgHsBOHokQ7p/K7cCw7Fu/ueqt6F sXfmkhfdCkTqFq2cznzg2U3A2z3W4Knkck3r79zeGC/qTsv/8STx8RFW8hFx9ZuU6yyv8ldu7whx 7/uu4mNP7JOcrRzLlphO8CRXEJPX83GIxArf489O1i7JmIx64RSfwRzOD7nAD3/v7n8v+IJfA4S/ 7gRR9VNv8opf+I1v8o+P+IZf+IAf+IY/+Itv7oNf8pJ/+Y+v+Ys/+Rzf+ZIf+ZTf+Y1v+iNv5Sw/ EPGe6C2/9Q2R4i/P5fdu3C8v6WXfsZdY5rqa7BuY5hEV3c4e9US/yHOf3Q0+0q8t8UyP3hZPuuDu 9+K+sJl/+JTv+NkP+ah/+NwP+eLO+KoP/ute9QUB/oyv/YFP/ogP+tc/+esP/+nf7uWf+tvPEK7P 9bm+67zO/xBdLvMAUcNdDYIDBRYcaJDgQoYNHTY0VyPiQnMRJ1KcaLGiRIsPaxz4+BHkAZIhRS4k CVLkyIbWrNV4SfBlTJcebTq8qFEnwY03ff4EGlToUKJFjT7MVSPX0qQL+Skl+LSG1KlRGVJtiJXq U65VrXbdWrXrzbFOrzos6/UrP7ZqxZ59azbu17NYs96VG9bqz3cE+74D3NdvDcALBXtUyNDd4sUH BSZOfBQnz4o5OebsaTMly5KdR5Y0mfIk6IUuTTOsKZkiR4mUL1dWHVv2bNq1GTYluFRp0lz8dHvV q9WjcLplwao9bjcq27ZTmxNn3pb4Xrh087qVmlb7cuV2of/Ldevxr2HChwkPPm/TYGPHCxkzfhxZ tuXVlGF3vOhTZUjPBDn35++k0kxLrbaOeGqNNQVtY7BBBx9siKndvttruuqweyus44oLD8O6PjTL wu5ArNDD7SwMzzu49OrwIcEC+8u8wsy7qbGEFIJvPflmy8gy2BCs7Mf8UCJtv4ZEYwjJzVhyqKaY GrzvQAinpLLKo367MLvrwGMxRfCoU5E64JwyDjnjtlsOLRLH3EpL4dpErsQswTQLgJtiZGi89NKj sSH22rPxoD/hY3BIhnrEr7XMklzJvwA5I3I00JC08tAgL6s0U02NcqbB6Z6Lrjk6v4yzujA9dG4s 5shUVbr/FF3Fq8JVZVXVRFhnNRNUUVl8yk6fDsNzT2B9Wq+gx4xVLKH2eEz0R9d6cvahJSf1j8kj iaR2UyC15bZbhjrtdCFnwCU3U+VibdHbC9UN6txNx4OxIRj7fChQ9m7E8cZCFXUNo/v61ay/zyKd 9DNKjWQ3YYUdJHdchxyuAeKjQqW4YosvxjhjjTfmuGOPPwY5ZIz5GgzPwsoTKl8dV0boQY0U3Aja 1wy9VqX/OnMU22pJW7hnn2ODeNyGw/0WXCrd/Xm4WeNNOrqfX4QaPaCKxffY95B1GVMEAaaZUZRC E/DRzY7kOWmbfvmlhrTVNptdoh0OOmJxJZa7bZ+DndHu/4QDM2xGPYMiNL583dvRQEQxYq3ra3Uu 8maD9RYqbbTVXhtyTYV+OOJwhYbbaKItb8ifGkQXHcJh4QXdW77Jo3dqHAXFuvBCM1OcqP9C289I hFN3aG3fKefdys3Lfdjzugn6HHJ/li+9+dEbPH311qk8baYnez7Z7z2HUtm9+Ja1MuZFh6IW55xN Qt9m9FOXXPKFfg9+SqPlDprzzZH/FvTlR2e+9IX8tw2wtKcpmsDEete7W/Zi0z1j/Sl+nrGZaA62 M9ytj3ftA5774mcb++XveB2km+aOp7fm+Y90BNlfbYLll+k9yEmngUkMZbJBorxOXzT8mu52ljv1 hW137P9znwbRVjkcqqZcmBNhw0ToQeQlz2cATCEKn8cQAMpGeiWzyQ9qoEXZWK8lqJFhGItYoxzJ boNFStLBlGRB0PkOg24kCBHHSBQnehBu+eMc/kaYtP6VkH/7c14Vj/K380zvB4fUIhe5WBQCyRCB M4xhgeY4SfJNMEAOwZm12hjHOLZvcvCjZFGGl0f8IbFunsNcHdlFOub974TO+18A5yU1hyCSIIfc olEeGckneTGUkPsGQ4IpmwQcIAHHdNTAwCYgSrUxiJ+Uoxx/GZT6jVJiyTuiKhfWv+excoqt7GYU JbM61tVyi4lcSCIX+ZPqWcMcqSmQF2cixmmy6xv3vGf/DYKJT4IMMyjITEANjkmSgD5OUhX8IeQq N8RoUk6a9XxIHu/YkPmhMm7346NDUtjKPk6RNnzbpyHNSRR3viQi7hyQIwnkJHpClFv+5Kc+hQmU Y9Z0IQU1Jho1eUlK/u6TLqXm2yJaSiUWzZRB8QZBkuqgE0rRmxttKoO+sUKZ+hORuLyqIn/yzjCa 9HqSVGlpgLqpfOqTnzDd50L86ZGAIvOmAgVJMXOXs4RekJOd1KBDx2qToVmUr/Q7JSmF4g3CKnWp DQLkN8HZzXCKUzL5PKsw14rOW6ozKC6pjPXeKc8ZzhOse50SZIe51rWatZ9lbUhNbepWgtSUh1+j 0jNk/1ulybFtoWwDLV/rl8RUAnZ+ewyhTwpbWKUyyIROZSwKoQrLoqQ1pqKVaS5tuUh0rnMyr3Gn RQh00gLyckC7zC1tULvP0ZZ3tNEtLVtb21aVBJSndVXNM2ogW/nOd0p5tW1+Hxre+3VOohgFLP20 idQaJJW4teEoFJXrUSo+1qwwdQh5f3BPXObynNZ9SEVKasDWHHCzLV1pd8Nbm7I+F58xRa9P3Ore twp0vcosm21mu5D63tehP63tiCmqRyQaL8CkDOGAGWLgAxf4QYKEpQmbKsifOPfBT37yPifMkAoD 5aSb3ewLUXqR6kVSrDp+EGofDN2qVjWtDmmriwXqXv8Wq9lKs6UvjW38xiHeFcwC9i2A53ZHay4R KIctsIFtk+TksjLJxyVKefu5aEafdrSUTSdQZqLheXpXpZ+t9J2l6ujTRjfFD2Hzate8Yje/Wc72 jTOEPLnQ/Y7YfsMzKm+x+TkhD/mwgh60H735Tae+ksFNbjSEF03afE5ZkVX2yEkNOGmJbHjDYJSJ Zz+r6eY6edieNvGw17raNq+ZIaytUn3FTZAZz1m/rc5tj/1L66Fprsd+/nNxDQto2Sy51398iB+D ougUk/naW7SqLX1Cacy2pCYdEbHBvUzto2Sb3+eFuKdTy2YXg3u9FZ+SfGs87hrbWK8Mb+II2S1U o/b/ttYeATS9Y7PRP/ralY1t+L/Ji14ya5HCtxRKTDJb8LD6ctldBrlRZl5i05b4vI0u+sR/wlqL 10bjqJ5vx4POrf4mUcB0e9tExTWU4RqZqb9ecEc5yr99d7rMooVsQ85885zrfCMohecLOfxFuU+9 7EM/a9pP7JHzNh3cqv17axsk7nJHXep2z5TWt77bJsK6g0QRtMpnw3LlRrGPY2fyQ/aO7ROf+dOc Hso7Ra9ZuGc52l/+OeITbXQzB1vbpuV8mkkte26rudsMmjGciwIP1c+mc3vE8xL1DOsnxvImhsa3 UMiL4jKbefmwF3NQRm8aLBecy9FeqSNb2nu1j1ni/7CXrMyJjmbVjrqtob497glvX4/Ag/c1eD9B 3A//+HOfjnMLefBnXUrgb/PyvE4+RCs7zpM46HKu8Yo+SdsummgkMDogBkw4+4swtdq7teu8iLNA FqO98gO8pnMQ+io8h6i/hXg/9+O9+ZPA+3M3P8MoobqmFfyZxXq5yiO7qAI2s5upAzQ6tGI+djoU lGq2duoqSOKwTEvBmVKra8PA8DM7J6O4igM8N+NAwfvAwyPBKzRBEWSIETxC3dI6PrO6ilK8GFwy btIo5kq0JMy75/M8f8s57Fs2mHi7Rjog7YOhLsTBCoSwo8Ond7gnPzyMmSM1wYvC81svgNKWLGw/ +v+jP0U8il27s2pavFEKLHgjISliLMqLOaQzLwoktjwkqZ/LLp87vTs0QvCyPz1MuyYssxmZKsKY Kmv7NoCyqVIjxFEzin6oAV3cPfljREacv/grQS48vtAxPld7qwSoqD1DJXfTM7P5P1fipsyzCQSc uaQjwOW7xqGYpw/zrFLUPjGathS0QNA7r3l5xVgMjGD6i22zvQ60PVycDV7sRRO0RxI8QfkrQaJ4 JWrMLWV0t4AiOR7jv/y7RCi6PH/0CR30vE5ryAr8vss6vYWjOzi0hnmYhxrAyHm4SDxUw6EruhID DHWMEQWaKhphum8jRETEOKHgxX7QRXr8iWGsv33/hL8tvMebFIrlmsF/vCNl9DEmsroN6qgFiw2Q REK0W7vXC8V28rk6nCeMvMipxMiFyMgjhEhsiy6mYSEYYcd2PBk0k8JbnL308wiY3EWZRMubyEcU PMGcpMm33Mmwq0GjBC3ZExr3uij8azcaSrDZQEAmdL4D/DxuhCEGxD6fq8qOzEiO1EirvMpUTC8e hJeRRK2TicVXLCS2orgVCzVvG4qY3MWFkMlFvEJ8zEmcvEkUtAlASqx8U8hJCrxxYbG48YiTuzO0 K8BV9MSQTC+SkjbEnCGpfInG5MjGJIirjMze0028Gya+8UN9Gkk/ZMfzOMkWMsRZlEKzvAnRTMvS /xTBe7RH1tRHLfRFncw3TEwusBur8qu4/9o6oUzFkGQ00qpP74uNAoo7eEpOqkzOqtzI/1xO7hOz awQps6JOzZTOdYTFPEFJv1M6okBLmFRLtiRPRazJ1dRJR/SIsUMumGNPiJI9Z8yzkAsuu3u40lJK vcNGyRgua0iqhCtOjZwJAH3M5GyIAUU8wmy+qDlJwzix6IRFBQK1DtRA0JRQeqRQ8GRLDaVJ9HTS DA0dcCoh11ys2Jyj86tNkqO12riDLyWIO6AkFOPNiNvNbeQ6wlLTAnsJwtLP0lhMyHxM5ZxTPCzT 61zQH53O68yevLkJDcxOKqyBLxVTMfWJtaTQJv/Nxy3USQQYz/FsCJs0xkwMJNcMLy3tthfEzaAA 00FtCEOdo+aEuFEds9/8iZSDUW+AURjtLBmSysfsSI00zhuV1aokUFXM0z8spHbc1VeMl5IUS88c S0Pt1GK1iSUdzZlcVGFEAPlr1hpw1H3MQvKc0rqswSrF0jHyTA98kEL1VE/11jFaw1K1z05MwFNd qnSNoa77quOkURy90chcTuSUwFWEmpGUKZBKx/T40e0BNYwT1m8N028tVFBliJhkUvOEUvSEVEc9 zwvlQhnsR1+zQaA60kwpVm8FVYOlofHjwR2MrKJIVzUd2UBLVTedSlmNCQANUFv1yLNLK8G4zpD/ 4lPr1FUW2lX14sAEINaBJVif5ViieEubDEZ9dFQEQNonZVQqIjSwy9aX9QkwldqpJdRpusbARDqR PTAiK9lAIyx6DdAcnVM6Ddt6VTuZ9UpfjU49iRqUoSXyOyZjJVZCpdtOdRDxJAikbVZqdctfnNQG C8BwgtqiqFqNDVefxSGiI1MeNdU/i7yF6Dp19VpVJduWpVdZhVcdZc58MhnppEDo7NPNZFugkNow 7dmNPVzJgNTVnFZ4OFrXdVhgXFSNwkQFIzvAHVzCndtBDdpQNVPf/Detndw1HVlcU1PjpFPMVd46 tVXNRdHRWkemiV52fE6upJEWuomCFdhPtVuj/2jdRnS/aMVHpN1Qv/2JxFKy5MvdoehZ091YxE1c iFRRKNPa4oXcrZ3c/2SI5MXRy3VZrKRZv8hMPgXEvvBVLMoTTi1c7X2I3YXfocDQDY1dYXTdZXVL Ymw5MzzDp13fcA1aDw4lFmW9iBys4U05r3uIjUyqlq1TWhXQFu5Cv6FO0L1XBR2gBM7eBbZbuf3Z BxYKaW3EpCVf8YTUooVNpuU1SFxfoXDguT3dEO7NTjyKNTWyIiOyeTMylp3V5v3feXVe1Ruv6ZwX VxxdvPHTh/ADMU3j9q3ahUBdw1VdDm3YCk5a86TWSQ2kBUNaDl7iJj7c7v0lfpsNXMvfrpW3Av9j Wf3lYuXcSOT8X3Jsx5P8Q2CV4b7ZzEtmCD/Q5BqgB3q4A3rwA94F4dKd2ti442HcW9YNRtacXdpV z9vdY7191iX+iR0e2FLuXQlU1ys2Xvy1ylp1YRhu5C8+QhmJXjEeY3nhE1oK5RrQ5Gfm5E0G1+4t WMC4g3e4ZsHIZaAwYtYU4jpuS7w9X7r0h2Y1Z2glX1rOYQY2XVHe3i7cZfyl4pL92kZmXpe1UXgd 3D4d42Su5LwhUoII5WZ2Zj/oZINuY58tjGy25rzZZkUNZ/HcW0cM56B4qnIuZ/J91nRWZ49AXYbQ 2PV9XHlTuchdYYxcKnn1YsvVZzwUoPIAaJj/hk6clRGb8GRQRuhOLl3R/QtDbWi39d6IbmULHloM Ts8+0lto7Wj2DWmCfegU5Noiq+J57roXVmnlZWRiTkFKpmT0aJ0XyeSCLuibpodoBmX3/dIXyeZB XWi2fltuZt1IBWKlNeqf0Ohz3uhZXupPneYdfmpdnmqqvjXIDTSvU2mwdeSrhtpZouFf7cqurMxM 3uSzxulO9mRRBuuGxmbUSeujkFRGLVopreuhSGdZ1uu9dggPLtzcHS6SrerAJq7I8waW3l95Beb1 LckramyeDt2FgGbLNmjLBm4+GY+MXeuwfGuf4NDyBEbUHO2gMO2NRmfUtglA7uhdxmJ6M+mU/07p RQ7bWV1irtzVfoZs6QlLaBboLy1rg97kQm3oTt3s87jm48ZZocXC8pxWhrWNc85b6q5ld6ZlQx5s kvVakkbk/h1Q8A7mfR7ve0UZfq5vfxXoUNbpT/5kTybo+bZmDTcZQiKkoF7E5ZYMcyZxdD5t/0bx hiDeE/Y6Qm7xkwZm277tjnbwme5w8ojwsB7r4C5rDN9sMZ2X+c5ZbxVv73XShT1PB+HoFGdymzhh Ajfkqf7lzJXTvTbm3P7Vrv5wZ+byge7ysvbUvgByP71m+Q5z4s5xCO7m1WUQvV7yJodzKi7s1h7s +5VqsaVyFG9s6cUbCW+ITW7mQtVk7eHw+P8G1Z7WHnKSjTtukLyG80d3iFuL7ZKec4+4aq3G7fGG aUuO6S2fcGh+5jT2g3og9XoAjHpw68Bw757u7ARGbkiHdRya9MKO9BeP9TvBcfLGcqBo5oG+g3pI 43oo1FIndTEVdmzG7Nze9OS+9WYHHV6+Xyd3dpv45yyXaT93iFDn3WI/9W9FdVKX6fgW796e9nKH nCjHYik3dxeR4U4v8p8Y9VL3VFMv9b4Ad2z+dg7nXU1/8HX396RZcTkfsn//Fa527KEAd3A3dsIw 9c0m9Xd4+IePEYYuGRom+ItPGONNd1rHeGp3bOwFClT/dWIfVGH/dYj/9ZRv+GUWFk/v+Jf/3xT7 5XiYrxJ5XwhTL/lrJnaI5/lsNvUyB+iDp/mh55Z5vvjSfnMGQfUaIHabn/eEZ/p7H/lvbXd/BXmi x/qsH/ESX/ITp42lZ/qoj/qd/9JvDwyc//WWn6XH1vq2d3vauOv+9vqvB/u6X/qyh3imT/uo1/ml /5vIvvq3F3zBz+vonuWkrg2oB3eCqHepP3WIF3ZUv9dhYZ1XH/zLx3yl1nyNVmrpLvHY+HbGF32G kPzQt3d7D32xZ3uqyvzWH3y8vmuOLu3EV3yxX3yeH3uJZ3yJX3w0Z3vXB36353zp7vyFwGvQ3/3c v/mwh/zm53ndl/yXrungp37C5++8vX7E/z+Kpk/+pQd7qGl6wYh43LdxHK7+84d5rjd+Ez9+7S8K p0/98If83Pf7hAd7lmd29Nd/Zzdtudd+gEBQQyACggJrDESocCHDhvVqPGRYbyLEiQ8fvquXcWJG hBRrZHwHcuG7kiMbokypciXLhuYQvnzZcibNmjZv4sypcyfPnj5/Ag0qdChRlgYTDjyaNCHBpAd1 XvT4EaJCjhpHYsxaUmRIrlxBfi0KNKZMc2Zlik2rdi3btm7fwo0bt2lBpgfvIqyrFylPixUjSr1q EeNWiCKpHj480qTcmmhrlI3ZeDLlypYvY8689qnCunk55+0cOqdfqlEdasxKUSRgw1cRmv9krBmm wrK0z5qdrXs3796+f+c0uNdzQbzDPUNNObgqRYsbQaZOHRu2QsWzJcPMHRky8O7ev4MH/2c8+fFD 6X4mvrB4caejcbYGHHG51b+CYWdFaT1zbtr+bUP2WHgDEliggUP9gVCCCSq0YA0M9sTeUqHRdVRT ou3k13zzVWRaSBc5t5FGYZ3UnWQAanegiiuy2OJK5jG4IHkKArWXXekZh1R7fTVnX4cfgdiVhovJ phtuKD6GHXYuMtmkk7pBCKOCUjIEYXDudXYXZ0rpBZpNUzH3Y1USdcSaVCTyliJ3a65p21lPwhmn nHDJOCONM+JpJU5PEbcjU+tNiNxNG3b/GKZ8YXokZHhkZcfdm9mpOaekk1KKk3kPwihlppg6qGdN fSInHGjsXQhVjxw2V5pHpjHXmm+RMupSbWxWWquttz7YUJRT8lrepTuhlyWWKJVq6lSpLjTYqVQx +12KJy7UX5vS4lqttUxmamV5C+GJaVBK8cWXoO8ZWyiYHLIKoqsmujnriUsKeK28864YY6+54mtn rp7SdKGFoQY67k8g2ndoqoc6G62j0JK1Xbz0Qhzxbtrqmi2NFzcYnJd2kcpnsX0xK5+yPka1LnDa wXrbwgBK3LLLl2mqZ50X76rplTiWip6WRGlYmsh/GdguvEc2uuTLRyNNJ6d5Ophv0/v+/3qzx34K W9RpBAPd7GkEokV0gJHOmrTYYyPIdJS+Ztz0rt4Cy+eEAYvlKsJirpgkpEq++zDZe/OtUgIKJfD3 2vdCLSO3vEZI4Z9bbizUuVrPXXeAbTo6ueV9Y575QoED/mKDaEeN9uFtjyoqXMdGrmLDz9Latd6a w470338jRHvtgttL875OTzl4hG5ndjCTrn+N2+Svx5780bPXMHvgCVi8u71P51slvj4Br3xLbxLN MPLagz/v87Q//8fzzSN+6aabevs0v+Gv1V+878Jff8Tnj68g9Bn3nnvMn1PJfpfJW9gEaEBbcS6B tWse/q5nuE5BUH27u94B2WI814GtgkUahBPnNsc8qO3vTvpaWtq4FcANpkVajHoUClvIwfPdroGc C+C2bHY2w7mwLSzMIQ8nZTsGkkdw/fscAH81Per1MIk8CQgAOw== ------=_NextPart_000_0005_01C71DDF.4CAD3240-- From cha68itm@hanmail.net Tue Dec 12 04:17:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu3lo-0001zr-W1 for ipfix-archive@lists.ietf.org; Tue, 12 Dec 2006 04:17:52 -0500 Received: from [220.73.254.207] (helo=hanmail.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gu3lm-0007CU-9P for ipfix-archive@lists.ietf.org; Tue, 12 Dec 2006 04:17:52 -0500 Message-ID: <4C8A6A88.D2455C93@hanmail.net> Date: Tue, 12 Dec 2006 01:54:53 -0800 From: "jacquiline ramos" MIME-Version: 1.0 To: "Randi" Subject: Eradicate all that you owe with out mailing an other dime Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Abolish everything you are indebted for not even paying an other cent. Stop the harrasing calls. Bring a stop to the mailing of checks! Believe it or not almost all lending orgizations are operating illegally. Astonishing but factual! Go to our web site for detailed information regarding our structure at N O expense or commitment. You have naught to loose and a load to achieve. You can contact us at : 1--3 1 3--2 6 3--2 7 0 6 In depth info or to cease getting or to grasp postal address In the afternoon they all went to a great field outside the city gates where the games were to be held. Accidents are always liable to happen, continued the boy From cydbsatw@chirpan.tv Tue Dec 12 09:23:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu8Xt-00031Y-KW for ipfix-archive@lists.ietf.org; Tue, 12 Dec 2006 09:23:49 -0500 Received: from [84.238.171.183] (helo=host-84-238-171-183.chirpan.tv) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu8Xo-0007LO-FD for ipfix-archive@lists.ietf.org; Tue, 12 Dec 2006 09:23:49 -0500 From: "prints" To: ipfix-archive@lists.ietf.org Subject: Solutions Chefs Date: Tue, 12 Dec 2006 16:23:40 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0000_01C71E09.E298C470" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcceCeKY+tI7roq5S1KoqbmTqlzDNw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.4 (+++) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 ------=_NextPart_000_0000_01C71E09.E298C470 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_01C71E09.E298C470" ------=_NextPart_001_0001_01C71E09.E298C470 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit example many liberal cabinets chosen represent See GNU Free License. ------=_NextPart_001_0001_01C71E09.E298C470 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

example many liberal = cabinets chosen represent See

GNU Free = License.

------=_NextPart_001_0001_01C71E09.E298C470-- ------=_NextPart_000_0000_01C71E09.E298C470 Content-Type: image/gif; name="pic01.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdh8wABAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAA8wABAQcI/gDtCRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJEuG8kihTqlzJsqXLlzBjypxJs6ZNkHBuMiSmE2G6 nkCDCh1KtGe+fCWREjzKVGnBoyyhCpR6UCnVokCvgtRKVetLplOdPrUqFqtOr03DTlVrL21Y qG7ZtkWaVmrcu2DH2qVbNu9euGC9mq3JlezcuXwPH96reGDXxGoZSzbs2HBgsXUhA5Y7+Gbh yHwTT8bc1+lm0GNBl2V7+ircxZYpd/ZcGjVd2G5zl9ZdufFbv3l7w+YMuPhlzrNpflZ8WbZe 39AbnxZuMDhzzaTfQhecXHnt66FZ/mPfvvrx9fOMhbfOjhi98+4ym/41Tb/yY/PUqc+3Tx8t cOL1IVYfd/AVaOCBCCao4IIMNmiQKQ5GKKGEb0xo4YUYZqghQ2Y0qMBBuWwo4ogklmjihqqk SJAqCbFoD4stLJSiigrNuOKMNh7k4kc7kpSjQDgWhOOOPyZHZEM9yrhii0DqqORBAWCUZEgs VjnQlEJeqaWRWb54JY1ehvkimFs2CSSNQ06Z5I9V9ljkl26SaeaYLh4555lxqinmngjZyadZ WIZpZ51zrumkmYQa5OaWaBbapaBlIqqln4tKeqeXeQZa6Z9YaaqopYHiSamlj3Y5KJKXLikm oVaGmmif/2D6qSqc8HkqKqlvfroqqbPeuiueOrIpJ6SStqqosJ7qqaujXKr6aqLKRvosr9Iy GumlsmLLrLGGpmqolaVqmyqgZUILLbPV/vpqr3W2i6up0zpb7rWCxjspsX92y+lEELJUJJHg PjssnXkyGu2ZkJKZ65irDgvwpliq+HCwBaNL64kYbxRqxi51yPHHIIdsYg4il2zyySinrPLK LLfs8sswH3pvR0MidMuxFW2Mas4p5RpxrEG+pC/NvTIJk85P+ojpjcsO7dKpwH6ZcNTsNtnu 1VTTeSOlsTJ8cb4KO3zxqFuXnaWa0TrdEtRsu/truo2Cau27+Lodr772vkv2tv7XgjvzrJse Pbe81GIb9NvnFq4s1PmOW/jgrC7dp+NZ+z0vvU8jniPjBIeLrrnIml3355sfC/Ti1horZOhO Jg540UKrC/nnniP+OL2u3z24xeKeqvrlRate8+uUr0143HHXWzvZutPdPLHJI5r36Lwr/7bV fKaNeezl+i3xnd/DviebX2v99cSk4ys1+oArjHn45q+ufeUGIh0zzyIefv/+/Pfv//8ADKAA B0jAApasBAZM4P2+xaOFiY5gDrQfRSSYEZ9N7kBq00jgTCWzC/IIJb/z2uoSxLh/BaxeB0Nf mpZFtTY9sHwWjNreKic2tH2KgkNh29zQNL2I7bCDg/7K3aN66KgZlvBsSOxggTjnPCV2jm+c shUTL+gqvoWQgy1yn61WgocPci1569KfrnTIwid+kWLsm93SLOer+CVxXeLrjvegSL3sEQ56 QFRj8HCHxamxMVt2DJgYizebStkNYeoaWvN8aDBEEtFr2bIXIA+prT96EEEQ894J12e6ilkv eCcM288aljb3jQt+C4vh+DCGQ5i1kkSDVKAsZ0nLWtryli45By53ycte+tJAFfrl0Ux5qFcm zUeiRNvDBsY/QDpRgyCU3L4iOcBusU9gP/NkmeQBxr6J8oZx3Jc4F0jFH15Pdr37m6yOuKRM 3TCD/duiOe0HxzsSygfSHP9jjbpmOPARcItBwyYay9fEKz7Rje0s4zr/iUUy7tFbfYycJSGa 0IPZroDMcyTdGnlOSfIRkn2THDWrF8B/cbJuA0Ol2Oh3Sk1mU3RpNKYwhSLTohxgpkPxBU53 ytOe+tQmzfipUIdK1KIalZxxrKdIaioRE76UoC+DJ1Pxp7RN2nGjMTuj3IrlNvm9kJS0e6AF 5YnOcaqMnUKEJBzZOTsj6hF7SmRrVj+a1hn2UZ/FyuddTVfGFiJyf5YLaBOrd7gY+k6vB43g VYnHsKmy8qJ1BR5hI4q9ieYrGhUV3yT9Z8jEsdWaj9zb4og4R5lNb65My13pCOvSphFzlGk8 n2D+aejYo0bTtrg9mTNyy9ve+va3wMVpGIJL3OIaiZlUjatZlQbCb3ZyQs4ECTxXUltUWdWi DsJb15y7RqkNsVBhmxpCaetaj4q1hpdcLiY9SMkgbvVydRIBqCi52NCqM111hKtCHUjCsakR reyl6BTFqdSCInZ3fGXadyME2tWisJsE1hyE3Sm/2FKPW8/NWkJrR8gl7rWs8GUSgDeKN4Va Ua+bzSyH1Vsr4D1vkXm0Hn27Kj3embdxIK1kfs/ZoDeRD7yilSfAGqY++J10vDF9X2sT7FcN 47S6MoEyLmNp3Cpb+cpYzrKWt8zlLht1urctiVMptjUpnyi6KjGziHf+bNf/aRVTFYskd7t3 Y/Im0cS34yxkI1vijhZRsnI9cH3bWJAuALacAo6wog/LxjuSeXn8ZDHLAuvgZSr5dHj1I9gw 3TrPpdjN/w11nwkiBYFQw8CWtWgIGYljUM8Xio0CrY3DimMI3yu6gT7ZJY6pPEn+bk1Lbh/E ggVWJg8vpsjdny0+MoYcevnZ0I62tKdN7WqjpBXWzra2bULlNHdkF1mU6pz1vL2eRVOTpiUp UoE8KRqnctzFtuuY7yzot8Yz3WrFalmteV9/6rvROjttM39cR+wi2J6VXfQ+pwvvktLxi8q0 sO4MWlhmBvZJaHYlwiEbUoqKGsUfvXU49d3/zI1nVIQ19vNFa03aVTZN3Quc98qNjDCJw1DJ xfZq1ey8bY31/OdAR5Aggk70ol9oCkYfzEmSznRaUtDgRGuuNmGYbJQ1Or23VTMSH7njSe+K h+2mc9iZjGT/2hjeVx80j1eG7hwjb1trtfe03PrvaS444yb7LKzt7WjKdreK41QlTP/asmOH eL6VznDZZUdx1oETdlyT9Mf0js75STadeU21iS/+8hXn/c7uxWPdc3xV0Y6x5bjme8oYaMU3 TzLYYr98zaEaP8PzvOkQ0TruE4B7kKih98CX5QyCT/ziG//4cvQ8zaq+M8CXGyi6fzS7Unq6 ZIOZI3hnSIEX26lz/o9P3h03mqjdvV1VwzXxt3JhuK65RvIfqeEyj7280Q62Z4pL/M5rL0fF /ef+R6/0+6d/Kcd19qVfC1V3rLdiG4RG6NdmBGhrEiV62bNC+3Z4F1Zu2zdx9bZ9bvRHmnJ9 AEhicMJ1Ivh3oxdqArEGFng3g1RxqJN5m2Zh53dK+Ic0/FaCgXaDjCdSs2ZyLvZwlPNpqKZ2 eyRIgrdgvPZiO3RapkdrLPIOI4WCHDdYpVeAK7d/IaV595d99YV+RCZwJnVz4KVysTdz51OG qQVVSdZSOfdVnrSGyPd8JbIJcViHdniHeJiHeriHQQeCtRZ1YgZ/DTdpQzYRuhd9W9eD/11H iN5Ve9IUPjIYf+x2hR2IXvbXalHVXYn0amwmd/13PTlod1iHiBKCYRUIYkGYijuYdupDdiin YCO3eppoexdIaG1kWKmDWC44OVDHfZmoOkjQeQ41ah3HaESYhZhYKqQIXe+lhNAjayrXhM6C eorIhVaHK5FmaV+IMzbHUlEEe1Tnet32Mn9wZnx4juiYjuq4juzYju54jRHBgRexjAQFdcjC fEQRDg6xdBZRU9FHj5r4iikVfoX3aO+nNUYofYtnPvM3dfl0cazmhyGjPQcpY+FnhaXlcp2I XREZi593d6LHapmWaREIeBvjY331SZI3eZ0UORJ4UCOohicGcP+OR2/2yHmZ6GkheXlCeIFX 1JOrlpKMlZOMNYyEZ5GYR4lIGUga+T6yR4gB9Vqzd2RHpkph+I1tWI8sBId1CJDv+JVgGZZi OZZkWZbuyA9oaQ/8oJZpORBouZYC8ZZqyZZwKZdu2ZZy+ZZ5qZd3yZd96Zd0CZcGAZh6KZiF aZiFGZiC2TKIGZeD6ZZ36ZiSWRCLaZiQOZeTaZmXWZeTiZkEUZmX6ZmgmZmkyZiU2ZmSuZiY yZkHMZqeGZqamRCuGZqvmZqweZq1KZouo5q0aZutmZu0qZmxKZwIMZudyZusqZuf6ZvKyTK8 iZqrWZzP+ZdtGZh/+Zl2+Zi9+ZrIGZeZ2Vmb/IBPhPmdKzOd3Qmcczmd3LmZ7Nme2gmdxhmd 67mc8lmfzomb56marGme9JmbyYmewfme/smc4Amf0Kkyw7mcCVqauMmg6Xmb26mf/RmgDOqa oBmbjFmdh0mXfdmhHOqhe8mX2XmY1emh19maI6qhJEqda5miAGqW5UmiMjqjNFqjNnqjOJqj OrqjgAmjPvqjQBqktBQQADs= ------=_NextPart_000_0000_01C71E09.E298C470-- From ipfix-bounces@ietf.org Tue Dec 12 10:49:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu9sc-0006XV-3T; Tue, 12 Dec 2006 10:49:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu9sa-0006XP-LR for ipfix@ietf.org; Tue, 12 Dec 2006 10:49:16 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu9sY-0000w2-QI for ipfix@ietf.org; Tue, 12 Dec 2006 10:49:16 -0500 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kBCFn6AT003471 for ; Tue, 12 Dec 2006 10:49:06 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kBCFmxkY003454 for ; Tue, 12 Dec 2006 10:48:59 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kBCFmw9v003450; Tue, 12 Dec 2006 10:48:59 -0500 (EST) Received: from [128.237.237.185] (vpn-10-25-4-29.remote.cert.org [10.25.4.29]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.66) with ESMTP id kBCFmwgs001109; Tue, 12 Dec 2006 10:48:58 -0500 Message-ID: <457ECF3F.2040600@cert.org> Date: Tue, 12 Dec 2006 10:48:15 -0500 From: Brian Trammell User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] Template ID as scope for Common Properties References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> <45780A37.8010905@cisco.com> <45782D40.20002@cisco.com> <457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> <457BF952.6060405@cisco.com> In-Reply-To: <457BF952.6060405@cisco.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Johnson wrote: > > The argument is that the Flow is complete without both the Specific > Properties and the Common Properties. So if a Data Record is received > that has a cpID that isn't defined then the Collecting Process knows > that something is missing and will discard the Flow (perhaps after > waiting a short time to see if the definition is simply late). ("Flow is incomplete", right?) > Now, when the TemplateID is used to associate the Common Properties > with Data Records that are defined by the Template, and that definition > is lost before reaching the Collector, then it has no way of knowing > that this vital information is lost and will continue to decode the > Data Records without the Common Properties. I've always been uneasy about scoping random stuff to templates, largely because of a general feeling of ambiguity; this is the most succinct explanation of one of those ambiguities that I've seen on the list... >>> Issue 2: >>> Some collectors will simply write all the Data Records, options and >>> flows, >>> to disk and allow reconciliation later. For current options that use >>> things like the ifIndex, this is fine. Using the TemplateID will now >>> require them to store the ObservationDomainID and TemplateID with every >>> received record. These identifiers are really for use in the Transport >>> Session and are not supposed to be stored externally after decode. >> >> Maybe this issue could be solved by a structured IPFIX file format? > > We can't dictate the output of the Collecting Process just so that a > Collector can use Reducing Redundancy. The Templates and Template IDs > are part of the transport mechanism and I don't think they should form > part of the data that is output by the Collecting Process. Indeed, there is no concept in the file draft (nor are we planning to have one) of requiring or recommending the persistence of identifiers (whether they be part of the framing mechanism as tId, or part of the record encoding as cpId) at a Collecting Process which uses IPFIX files for storage; such recommendations would be out of scope. Now, there _is_ a case which we will most probably address in the file draft before Prague where odId and tId are persistent; the "netcat collector" case where the process listening to the network is merely copying the messages into IPFIX Files. Such a CP could be implemented using nc(1), hence the nickname, but would not be strictly compliant (it would be unable to terminate the association or connection in those cases the protocol requires, because it's not actually interpreting the messages). This is quite a special case (designed for unit testing, or testing during the early stages of development of an IPFIX Device) and should not be used as justification for template IDs as common property scope. >>> Issue 3: >>> When sending information associated with the Template, such as the >>> refresh time for the template, then you would expect to send an option >>> Data Record containing the TemplateID as scope and the refresh time as >>> the data. So there are two issues here: >>> a) Is information sent with a TemplateID as scope associated with the >>> template or with the Data Records associated with the template? >>> >>> b) If these features were used simultaneously then because they would >>> be sending options Data Records with the same scope then they would >>> overwrite each others data. (The way around this is to combine the >>> data, sending a Data Record with the Template ID as scope and the >>> Common Properties AND the refresh time as data). >>> hmmm... yes, were I not already not a fan of scoping common properties to template ID, 3a above would convince me. So, tally up another in the "no common properties scoped to templates" column. Exporting Common Properties via template ID is too ambiguous to be useful, and going to the effort to resolve the ambiguities seems wasteful given that we have a nice shiny new IE (cpId) custom-defined for the reducing-redundancy case. Regards, Brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFfs8/4/8LCZ4pwvYRAh64AJ0YwnqdG3Ykkm+pnsqNIz5hr7JrhACeKn5W we+VBqXGu3GKe4rKgDpF2SY= =GZlm -----END PGP SIGNATURE----- _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 12 10:49:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu9sc-0006XV-3T; Tue, 12 Dec 2006 10:49:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu9sa-0006XP-LR for ipfix@ietf.org; Tue, 12 Dec 2006 10:49:16 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu9sY-0000w2-QI for ipfix@ietf.org; Tue, 12 Dec 2006 10:49:16 -0500 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kBCFn6AT003471 for ; Tue, 12 Dec 2006 10:49:06 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kBCFmxkY003454 for ; Tue, 12 Dec 2006 10:48:59 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kBCFmw9v003450; Tue, 12 Dec 2006 10:48:59 -0500 (EST) Received: from [128.237.237.185] (vpn-10-25-4-29.remote.cert.org [10.25.4.29]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.66) with ESMTP id kBCFmwgs001109; Tue, 12 Dec 2006 10:48:58 -0500 Message-ID: <457ECF3F.2040600@cert.org> Date: Tue, 12 Dec 2006 10:48:15 -0500 From: Brian Trammell User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] Template ID as scope for Common Properties References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> <45780A37.8010905@cisco.com> <45782D40.20002@cisco.com> <457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> <457BF952.6060405@cisco.com> In-Reply-To: <457BF952.6060405@cisco.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Johnson wrote: > > The argument is that the Flow is complete without both the Specific > Properties and the Common Properties. So if a Data Record is received > that has a cpID that isn't defined then the Collecting Process knows > that something is missing and will discard the Flow (perhaps after > waiting a short time to see if the definition is simply late). ("Flow is incomplete", right?) > Now, when the TemplateID is used to associate the Common Properties > with Data Records that are defined by the Template, and that definition > is lost before reaching the Collector, then it has no way of knowing > that this vital information is lost and will continue to decode the > Data Records without the Common Properties. I've always been uneasy about scoping random stuff to templates, largely because of a general feeling of ambiguity; this is the most succinct explanation of one of those ambiguities that I've seen on the list... >>> Issue 2: >>> Some collectors will simply write all the Data Records, options and >>> flows, >>> to disk and allow reconciliation later. For current options that use >>> things like the ifIndex, this is fine. Using the TemplateID will now >>> require them to store the ObservationDomainID and TemplateID with every >>> received record. These identifiers are really for use in the Transport >>> Session and are not supposed to be stored externally after decode. >> >> Maybe this issue could be solved by a structured IPFIX file format? > > We can't dictate the output of the Collecting Process just so that a > Collector can use Reducing Redundancy. The Templates and Template IDs > are part of the transport mechanism and I don't think they should form > part of the data that is output by the Collecting Process. Indeed, there is no concept in the file draft (nor are we planning to have one) of requiring or recommending the persistence of identifiers (whether they be part of the framing mechanism as tId, or part of the record encoding as cpId) at a Collecting Process which uses IPFIX files for storage; such recommendations would be out of scope. Now, there _is_ a case which we will most probably address in the file draft before Prague where odId and tId are persistent; the "netcat collector" case where the process listening to the network is merely copying the messages into IPFIX Files. Such a CP could be implemented using nc(1), hence the nickname, but would not be strictly compliant (it would be unable to terminate the association or connection in those cases the protocol requires, because it's not actually interpreting the messages). This is quite a special case (designed for unit testing, or testing during the early stages of development of an IPFIX Device) and should not be used as justification for template IDs as common property scope. >>> Issue 3: >>> When sending information associated with the Template, such as the >>> refresh time for the template, then you would expect to send an option >>> Data Record containing the TemplateID as scope and the refresh time as >>> the data. So there are two issues here: >>> a) Is information sent with a TemplateID as scope associated with the >>> template or with the Data Records associated with the template? >>> >>> b) If these features were used simultaneously then because they would >>> be sending options Data Records with the same scope then they would >>> overwrite each others data. (The way around this is to combine the >>> data, sending a Data Record with the Template ID as scope and the >>> Common Properties AND the refresh time as data). >>> hmmm... yes, were I not already not a fan of scoping common properties to template ID, 3a above would convince me. So, tally up another in the "no common properties scoped to templates" column. Exporting Common Properties via template ID is too ambiguous to be useful, and going to the effort to resolve the ambiguities seems wasteful given that we have a nice shiny new IE (cpId) custom-defined for the reducing-redundancy case. Regards, Brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFfs8/4/8LCZ4pwvYRAh64AJ0YwnqdG3Ykkm+pnsqNIz5hr7JrhACeKn5W we+VBqXGu3GKe4rKgDpF2SY= =GZlm -----END PGP SIGNATURE----- _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 12 12:52:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuBmz-0006dn-6q; Tue, 12 Dec 2006 12:51:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuBmx-0006de-SK for ipfix@ietf.org; Tue, 12 Dec 2006 12:51:35 -0500 Received: from [2001:638:501:184::3] (helo=mailout1.zim.uni-duisburg-essen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuBmj-0007es-0g for ipfix@ietf.org; Tue, 12 Dec 2006 12:51:35 -0500 Received: from dicky.wi-inf.uni-essen.de ([132.252.52.114]:3547 helo=[192.168.9.201]) by mailout1.zim.uni-duisburg-essen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1GuBlp-0045cG-VJ for ipfix@ietf.org; Tue, 12 Dec 2006 18:50:25 +0100 Message-ID: <457EEBD5.9080400@arnsmann.net> Date: Tue, 12 Dec 2006 18:50:13 +0100 From: Jonas Arnsmann User-Agent: pr0meToYz MUA ;-) MIME-Version: 1.0 To: ipfix@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [IPFIX] IPfix implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi, I am currently implementing an IPfix simulation using the Reliable Server Pooling Framework [1] using the discrete event simulation system Omnet++ [2] During my research on the internet I was unable to find an opensource implementation of the IPfix protocol. Does someone on this list know of such a project? I would like to perform some general IPfix tests with a working "prototype"... Thank you so much in advance! Regards, Jonas Arnsmann Bsc. Network Systems Engineering University of Duisburg-Essen, Germany [1] http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/ [2] http://www.omnetpp.org _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 12 12:52:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuBmz-0006dn-6q; Tue, 12 Dec 2006 12:51:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuBmx-0006de-SK for ipfix@ietf.org; Tue, 12 Dec 2006 12:51:35 -0500 Received: from [2001:638:501:184::3] (helo=mailout1.zim.uni-duisburg-essen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuBmj-0007es-0g for ipfix@ietf.org; Tue, 12 Dec 2006 12:51:35 -0500 Received: from dicky.wi-inf.uni-essen.de ([132.252.52.114]:3547 helo=[192.168.9.201]) by mailout1.zim.uni-duisburg-essen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1GuBlp-0045cG-VJ for ipfix@ietf.org; Tue, 12 Dec 2006 18:50:25 +0100 Message-ID: <457EEBD5.9080400@arnsmann.net> Date: Tue, 12 Dec 2006 18:50:13 +0100 From: Jonas Arnsmann User-Agent: pr0meToYz MUA ;-) MIME-Version: 1.0 To: ipfix@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [IPFIX] IPfix implementation X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi, I am currently implementing an IPfix simulation using the Reliable Server Pooling Framework [1] using the discrete event simulation system Omnet++ [2] During my research on the internet I was unable to find an opensource implementation of the IPfix protocol. Does someone on this list know of such a project? I would like to perform some general IPfix tests with a working "prototype"... Thank you so much in advance! Regards, Jonas Arnsmann Bsc. Network Systems Engineering University of Duisburg-Essen, Germany [1] http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/ [2] http://www.omnetpp.org _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 12 12:58:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuBtl-0002Ba-03; Tue, 12 Dec 2006 12:58:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuBtj-0002BP-Fm for ipfix@ietf.org; Tue, 12 Dec 2006 12:58:35 -0500 Received: from mailhost.auckland.ac.nz ([130.216.190.11] helo=groucho.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuBtg-0001i1-QC for ipfix@ietf.org; Tue, 12 Dec 2006 12:58:35 -0500 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 9983334ACC for ; Wed, 13 Dec 2006 06:58:28 +1300 (NZDT) Received: from groucho.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31737-14 for ; Wed, 13 Dec 2006 06:58:28 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 719AE3414D for ; Wed, 13 Dec 2006 06:58:28 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (localhost.localdomain [127.0.0.1]) by motoko.itss.auckland.ac.nz (8.12.11.20060308/8.12.11) with ESMTP id kBCHwRbo029446 for ; Wed, 13 Dec 2006 06:58:27 +1300 Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.12.11.20060308/8.12.11/Submit) id kBCHwRK5029444 for ipfix@ietf.org; Wed, 13 Dec 2006 06:58:27 +1300 X-Authentication-Warning: motoko.itss.auckland.ac.nz: apache set sender to nevil@auckland.ac.nz using -f Received: from dyn45.caida.org (dyn45.caida.org [192.172.226.45]) by webmail.auckland.ac.nz (Horde MIME library) with HTTP; Wed, 13 Dec 2006 06:58:27 +1300 Message-ID: <20061213065827.lxtaqy2jr9sgc08c@webmail.auckland.ac.nz> Date: Wed, 13 Dec 2006 06:58:27 +1300 From: Nevil Brownlee To: ipfix@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [IPFIX] Last-minute changes proposed for IPFIX Protocol RFC X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi all: After some discussion on the IPFIX list, a small editorial change that would improve the IPFIX Protocol draft has been proposed Since that's now in the RFC Editor queue, we could probably make the change as a comment to the RFC editor. The change is as follows - > throughout the document: > "Template Withdrawal Message" should be replaced by > "Template Withdrawal Set" > "Template Withdraw Message" should be replaced by > "Template Withdrawal Set" If anyone sees any problem with this change, please comment on the IPFIX list. Also, Juergen Quittek, in an email to the list dated 11 Dec 06 proposed three more editorial changes to the Protocol Draft (copied below). Can anyone see any problems with either of these? If we have consensus, one of the Protocol draft Editors will request the RFC Editor to make these changes in the document. Editors of other IPFIX drafts will also need to check that their drafts also used this changed terminology. Cheers, Nevil (IPFIX CO-chair) Juergen's proposed changes: > Now that I have read the concerned section 8 of IPFIX-PROTO again, > I found some more beautifications that seem to be desirable. > > > 1. Section 8, paragraph 11: A Template Withdrawal Message/Set is NOT > a Template Record. > OLD: > A Template Withdraw Message is a Template Record for that Template > ID with a Field Count of 0. The format of the Template Withdrawal > Message is shown in figure T. > NEW: > A Template Withdrawal Set contains a Template Record for that Template > ID with a Field Count of 0. The format of the Template Withdrawal Set > is shown in figure T. > > > 2. Section 8, paragraph 12: not a Template Set is withdrawn, but > Templates themselves are. > OLD: > The Set ID field MUST contain the value 2 for Template Set withdrawal > and the value 3 for Options Template Set withdrawal. Multiple > Template IDs MAY be withdrawn with a single Template Withdrawal > Message: in that case, padding MAY be used. > NEW: > The Set ID field MUST contain the value 2 for a Template Withdrawal > Set and the value 3 for an Option Template Withdrawal Set. Multiple > Template IDs MAY be withdrawn with a single Template Withdrawal > Set: in that case, padding MAY be used. > > > 3. Section 8, paragraph 15: If we replaced Message with Set here, we > would change the protocol. Therefore I'd suggest the following change. > OLD: > The Template Withdraw Message MUST NOT contain new Template or > Options Template Records. > NEW: > An IPFIX Message containing any Template Withdrawal MUST not contain > new Templates or Option Templates and it MUST NOT contain Option > Template Records. ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland, New Zealand ----------------------------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 12 12:58:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuBtl-0002Ba-03; Tue, 12 Dec 2006 12:58:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuBtj-0002BP-Fm for ipfix@ietf.org; Tue, 12 Dec 2006 12:58:35 -0500 Received: from mailhost.auckland.ac.nz ([130.216.190.11] helo=groucho.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuBtg-0001i1-QC for ipfix@ietf.org; Tue, 12 Dec 2006 12:58:35 -0500 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 9983334ACC for ; Wed, 13 Dec 2006 06:58:28 +1300 (NZDT) Received: from groucho.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31737-14 for ; Wed, 13 Dec 2006 06:58:28 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 719AE3414D for ; Wed, 13 Dec 2006 06:58:28 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (localhost.localdomain [127.0.0.1]) by motoko.itss.auckland.ac.nz (8.12.11.20060308/8.12.11) with ESMTP id kBCHwRbo029446 for ; Wed, 13 Dec 2006 06:58:27 +1300 Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.12.11.20060308/8.12.11/Submit) id kBCHwRK5029444 for ipfix@ietf.org; Wed, 13 Dec 2006 06:58:27 +1300 X-Authentication-Warning: motoko.itss.auckland.ac.nz: apache set sender to nevil@auckland.ac.nz using -f Received: from dyn45.caida.org (dyn45.caida.org [192.172.226.45]) by webmail.auckland.ac.nz (Horde MIME library) with HTTP; Wed, 13 Dec 2006 06:58:27 +1300 Message-ID: <20061213065827.lxtaqy2jr9sgc08c@webmail.auckland.ac.nz> Date: Wed, 13 Dec 2006 06:58:27 +1300 From: Nevil Brownlee To: ipfix@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [IPFIX] Last-minute changes proposed for IPFIX Protocol RFC X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi all: After some discussion on the IPFIX list, a small editorial change that would improve the IPFIX Protocol draft has been proposed Since that's now in the RFC Editor queue, we could probably make the change as a comment to the RFC editor. The change is as follows - > throughout the document: > "Template Withdrawal Message" should be replaced by > "Template Withdrawal Set" > "Template Withdraw Message" should be replaced by > "Template Withdrawal Set" If anyone sees any problem with this change, please comment on the IPFIX list. Also, Juergen Quittek, in an email to the list dated 11 Dec 06 proposed three more editorial changes to the Protocol Draft (copied below). Can anyone see any problems with either of these? If we have consensus, one of the Protocol draft Editors will request the RFC Editor to make these changes in the document. Editors of other IPFIX drafts will also need to check that their drafts also used this changed terminology. Cheers, Nevil (IPFIX CO-chair) Juergen's proposed changes: > Now that I have read the concerned section 8 of IPFIX-PROTO again, > I found some more beautifications that seem to be desirable. > > > 1. Section 8, paragraph 11: A Template Withdrawal Message/Set is NOT > a Template Record. > OLD: > A Template Withdraw Message is a Template Record for that Template > ID with a Field Count of 0. The format of the Template Withdrawal > Message is shown in figure T. > NEW: > A Template Withdrawal Set contains a Template Record for that Template > ID with a Field Count of 0. The format of the Template Withdrawal Set > is shown in figure T. > > > 2. Section 8, paragraph 12: not a Template Set is withdrawn, but > Templates themselves are. > OLD: > The Set ID field MUST contain the value 2 for Template Set withdrawal > and the value 3 for Options Template Set withdrawal. Multiple > Template IDs MAY be withdrawn with a single Template Withdrawal > Message: in that case, padding MAY be used. > NEW: > The Set ID field MUST contain the value 2 for a Template Withdrawal > Set and the value 3 for an Option Template Withdrawal Set. Multiple > Template IDs MAY be withdrawn with a single Template Withdrawal > Set: in that case, padding MAY be used. > > > 3. Section 8, paragraph 15: If we replaced Message with Set here, we > would change the protocol. Therefore I'd suggest the following change. > OLD: > The Template Withdraw Message MUST NOT contain new Template or > Options Template Records. > NEW: > An IPFIX Message containing any Template Withdrawal MUST not contain > new Templates or Option Templates and it MUST NOT contain Option > Template Records. ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland, New Zealand ----------------------------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 12 23:46:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuLzV-0003Tj-EH; Tue, 12 Dec 2006 23:45:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuLzU-0003Td-Dg for ipfix@ietf.org; Tue, 12 Dec 2006 23:45:12 -0500 Received: from gws03.hcl.in ([203.105.186.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GuLzR-00089D-6W for ipfix@ietf.org; Tue, 12 Dec 2006 23:45:12 -0500 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 18F9037C010 for ; Wed, 13 Dec 2006 10:14:59 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws03.hcl.in (Postfix) with ESMTP id EF1B937C008for ; Wed, 13 Dec 2006 10:14:58 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.14]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 10:14:58 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Dec 2006 10:14:58 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Sending export packet Thread-Index: AccecXFFhraNqdzSQOGIHN5j9Mnarg== From: "Bhuvaneswari R P - TLS ,Chennai" To: X-OriginalArrivalTime: 13 Dec 2006 04:44:58.0854 (UTC) FILETIME=[718CD060:01C71E71] X-imss-version: 2.045 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-7.0720 TC:1F TRN:52 TV:3.6.1039(14870.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.4 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Subject: [IPFIX] Sending export packet X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1174328549==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1174328549== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71E71.7172CB39" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71E71.7172CB39 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, =20 Need clarification in below quote from RFC 3954: =20 "Two approaches are taken to make sure that Templates get refreshed at the Collector: * Every N number of Export Packets. * On a time basis, so every N number of minutes. " =20 Any specific reason for having two approaches to send export packet? =20 Regards, Bhuvaneswari. DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender= immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C71E71.7172CB39 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All,

 

 Need clarification in below quote from RFC= 3954:

 

“Two approaches are taken to make=
 sure
that Templates get refreshed at the=
 Collector:
    * Every N number of Export=
 Packets.
    * On a time basis, so every N number of=
 minutes. ”

 

Any specific reason for having two approaches to send export packet?

 

Regards,

Bhuvaneswari.

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have
received this email in error please delete it and notify the sender= immediately. Before opening any mail and
attachments please check them for viruses and defect.

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C71E71.7172CB39-- --===============1174328549== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1174328549==-- From ipfix-bounces@ietf.org Tue Dec 12 23:46:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuLzV-0003Tj-EH; Tue, 12 Dec 2006 23:45:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuLzU-0003Td-Dg for ipfix@ietf.org; Tue, 12 Dec 2006 23:45:12 -0500 Received: from gws03.hcl.in ([203.105.186.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GuLzR-00089D-6W for ipfix@ietf.org; Tue, 12 Dec 2006 23:45:12 -0500 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 18F9037C010 for ; Wed, 13 Dec 2006 10:14:59 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws03.hcl.in (Postfix) with ESMTP id EF1B937C008for ; Wed, 13 Dec 2006 10:14:58 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.14]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 10:14:58 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Dec 2006 10:14:58 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Sending export packet Thread-Index: AccecXFFhraNqdzSQOGIHN5j9Mnarg== From: "Bhuvaneswari R P - TLS ,Chennai" To: X-OriginalArrivalTime: 13 Dec 2006 04:44:58.0854 (UTC) FILETIME=[718CD060:01C71E71] X-imss-version: 2.045 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-7.0720 TC:1F TRN:52 TV:3.6.1039(14870.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.4 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Subject: [IPFIX] Sending export packet X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1174328549==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1174328549== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71E71.7172CB39" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71E71.7172CB39 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, =20 Need clarification in below quote from RFC 3954: =20 "Two approaches are taken to make sure that Templates get refreshed at the Collector: * Every N number of Export Packets. * On a time basis, so every N number of minutes. " =20 Any specific reason for having two approaches to send export packet? =20 Regards, Bhuvaneswari. DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender= immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C71E71.7172CB39 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All,

 

 Need clarification in below quote from RFC= 3954:

 

“Two approaches are taken to make=
 sure
that Templates get refreshed at the=
 Collector:
    * Every N number of Export=
 Packets.
    * On a time basis, so every N number of=
 minutes. ”

 

Any specific reason for having two approaches to send export packet?

 

Regards,

Bhuvaneswari.

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have
received this email in error please delete it and notify the sender= immediately. Before opening any mail and
attachments please check them for viruses and defect.

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C71E71.7172CB39-- --===============1174328549== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1174328549==-- From ipfix-bounces@ietf.org Wed Dec 13 05:14:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuR6v-0003Ap-77; Wed, 13 Dec 2006 05:13:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuR6u-00039h-JK for ipfix@ietf.org; Wed, 13 Dec 2006 05:13:12 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuR6q-0000rK-0u for ipfix@ietf.org; Wed, 13 Dec 2006 05:13:12 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id kBDAD4F03268; Wed, 13 Dec 2006 11:13:04 +0100 (MET) 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] IPfix implementation X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 13 Dec 2006 11:13:01 +0100 Message-ID: <70524A4436C03E43A293958B505008B6642CE2@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] IPfix implementation Thread-Index: AcceFn+wRcoUw5xAQmWGTE8RXjHaKQAiGRjQ From: "Schmoll, Carsten" To: "Jonas Arnsmann" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Jonas, you may want to try one of the following software packages: LIBIPFIX http://libipfix.sourceforge.net/ Organisation: Fraunhofer FOKUS Description: C library, distributed under the BSD license. Full support for SCTP, UDP, TCP, IPv4 and IPv6. Runs on Linux, FreeBSD, and Solaris. NTOP http://www.ntop.org/ Organisation: ntop.org Description: distributed under the GPL2 license. Runs on Linux. FIXBUF http://tools.netsa.cert.org/fixbuf/ Organisation: CERT / NetSA Description: C library, distributed under the LGPL license. Includes a Metering/Exporting process (http://tools.netsa.cert.org/yaf/) that can be used for testing purposes. Runs on MacOS. VERMONT http://vermont.berlios.de/ Organisations: Universities of Erlangen-Nuremberg and Tuebingen Description: Runs over Linux and BSD, released under the GPL license Good luck with your simulation and let us know what you found out. (or just post the link to the paper you write afterwards on the results ;) On the respective web pages you'll also find out on how to contact the=20 tool's authors in case of any questions. Hope this helps, Carsten. > -----Original Message----- > From: Jonas Arnsmann [mailto:jonas@arnsmann.net] > Sent: Tuesday, December 12, 2006 6:50 PM > To: ipfix@ietf.org > Subject: [IPFIX] IPfix implementation > > Hi, > > I am currently implementing an IPfix simulation using the Reliable > Server Pooling Framework [1] using the discrete event > simulation system > Omnet++ [2] > During my research on the internet I was unable to find an opensource > implementation of the IPfix protocol. Does someone on this > list know of > such a project? I would like to perform some general IPfix tests with > a working "prototype"... > > Thank you so much in advance! > > Regards, > > Jonas Arnsmann > Bsc. Network Systems Engineering > University of Duisburg-Essen, Germany > > [1] http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/ > [2] http://www.omnetpp.org > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix > >=20 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Dec 13 05:14:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuR6v-0003Ap-77; Wed, 13 Dec 2006 05:13:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuR6u-00039h-JK for ipfix@ietf.org; Wed, 13 Dec 2006 05:13:12 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuR6q-0000rK-0u for ipfix@ietf.org; Wed, 13 Dec 2006 05:13:12 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id kBDAD4F03268; Wed, 13 Dec 2006 11:13:04 +0100 (MET) 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] IPfix implementation X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 13 Dec 2006 11:13:01 +0100 Message-ID: <70524A4436C03E43A293958B505008B6642CE2@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] IPfix implementation Thread-Index: AcceFn+wRcoUw5xAQmWGTE8RXjHaKQAiGRjQ From: "Schmoll, Carsten" To: "Jonas Arnsmann" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Jonas, you may want to try one of the following software packages: LIBIPFIX http://libipfix.sourceforge.net/ Organisation: Fraunhofer FOKUS Description: C library, distributed under the BSD license. Full support for SCTP, UDP, TCP, IPv4 and IPv6. Runs on Linux, FreeBSD, and Solaris. NTOP http://www.ntop.org/ Organisation: ntop.org Description: distributed under the GPL2 license. Runs on Linux. FIXBUF http://tools.netsa.cert.org/fixbuf/ Organisation: CERT / NetSA Description: C library, distributed under the LGPL license. Includes a Metering/Exporting process (http://tools.netsa.cert.org/yaf/) that can be used for testing purposes. Runs on MacOS. VERMONT http://vermont.berlios.de/ Organisations: Universities of Erlangen-Nuremberg and Tuebingen Description: Runs over Linux and BSD, released under the GPL license Good luck with your simulation and let us know what you found out. (or just post the link to the paper you write afterwards on the results ;) On the respective web pages you'll also find out on how to contact the=20 tool's authors in case of any questions. Hope this helps, Carsten. > -----Original Message----- > From: Jonas Arnsmann [mailto:jonas@arnsmann.net] > Sent: Tuesday, December 12, 2006 6:50 PM > To: ipfix@ietf.org > Subject: [IPFIX] IPfix implementation > > Hi, > > I am currently implementing an IPfix simulation using the Reliable > Server Pooling Framework [1] using the discrete event > simulation system > Omnet++ [2] > During my research on the internet I was unable to find an opensource > implementation of the IPfix protocol. Does someone on this > list know of > such a project? I would like to perform some general IPfix tests with > a working "prototype"... > > Thank you so much in advance! > > Regards, > > Jonas Arnsmann > Bsc. Network Systems Engineering > University of Duisburg-Essen, Germany > > [1] http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/ > [2] http://www.omnetpp.org > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix > >=20 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From you@aver.ca Wed Dec 13 05:39:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuRWD-0005vG-K1 for ipfix-archive@lists.ietf.org; Wed, 13 Dec 2006 05:39:21 -0500 Received: from [86.72.169.139] (helo=139.169.72-86.rev.gaoland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuRWA-0007Cb-CO for ipfix-archive@lists.ietf.org; Wed, 13 Dec 2006 05:39:21 -0500 Received: from RTUBytmpAjzl (unknown [175.141.140.63]) by aver.ca with ESMTP id 41939162C129 for ; Wed, 13 Dec 2006 11:41:36 +0100 Message-ID: <000d01c71ea3$317915b0$00000000@kyriad> From: "Macintosh XLicense" To: ipfix-archive@lists.ietf.org Subject: reportFrom filesAPTop Date: Wed, 13 Dec 2006 11:41:06 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C71EAB.933D7DB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.1 (+++) X-Scan-Signature: ea10c7a57c6f5d0512401188e6188235 ------=_NextPart_000_0009_01C71EAB.933D7DB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C71EAB.933D7DB0" ------=_NextPart_001_000A_01C71EAB.933D7DB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Health pets water cooler seen on tv links? Calendar, contests other ways = to get alerts xml! Tools people with newsroom. Overview releases fact = sheets speeches section includes these items? Shareware november = allpeers organize. Pure mac peertopeer pp craftskid mpmedia osclassic. = You securely october amule, emule emulelike edk linux. Broadcast rewritten or associated, press reportfrom! Uses, bittorrent = allows you securely october amule emule! Size mbhome shareware november. Use install run ability, artist title. Court ruled that software can, be = held liable. Be, held, liable copyright their an australian found? Associated press reportfrom, filesaptop missing toddler denies! Two, years, intensive andrew. Prices lottery services careers shopping = dating travel? December higher edonkey fileswith globe fast, easy! America settles = lawsuit brought by last year supreme. Music files recording industry = announced, thursday the. Congress during hearings topics central = location delivered. Rate demand, creating limitless just. Intensive = andrew bram betadirect, kb. Fact sheets, speeches section includes these, items divided into. ------=_NextPart_001_000A_01C71EAB.933D7DB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"Medicaid"
Health pets water cooler seen on tv = links?=20 Calendar, contests other ways to get alerts xml! Tools people with = newsroom.=20 Overview releases fact sheets speeches section includes these items? = Shareware=20 november allpeers organize. Pure mac peertopeer pp craftskid mpmedia = osclassic.=20 You securely october amule, emule emulelike edk linux.
Broadcast rewritten or associated, = press=20 reportfrom! Uses, bittorrent allows you securely october amule emule! = Size=20 mbhome shareware november.
Use install run ability, artist title. = Court ruled=20 that software can, be held liable. Be, held, liable copyright their an=20 australian found?
Associated press reportfrom, filesaptop = missing=20 toddler denies!
Two, years, intensive andrew. Prices = lottery=20 services careers shopping dating travel?
December higher edonkey fileswith globe = fast, easy!=20 America settles lawsuit brought by last year supreme. Music files = recording=20 industry announced, thursday the. Congress during hearings topics = central=20 location delivered. Rate demand, creating limitless just. Intensive = andrew bram=20 betadirect, kb.
Fact sheets, speeches section includes = these, items=20 divided into.
------=_NextPart_001_000A_01C71EAB.933D7DB0-- ------=_NextPart_000_0009_01C71EAB.933D7DB0 Content-Type: image/gif; name="Built Remembers.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c71ea3$317915b0$00000000@kyriad> R0lGODlhXALwAYewAAIAAIkAAAB/AHNxCgAAg3cAjQt0fsvOxMHQtaHF+DEjAF4dAXIgAJ4aDMgq BekRAAA4BSg/ADFNBlZDCoM7DZs1B7c2ANk2AAlXACpuBEplAG1VAI1RAKBsALFtCehfAACLACOC AEF2CVGAA4OGAJ5/A75/AOOMDgCYCxeSAj+RAGGqAHemCqOUA7KtAOigAwDAABHOADu4AFrIAIu4 A6DAAMLDC+jLAADfBingADfTAGPWDoPsAKHqALjrANTZAAIBNSwATkUHQFsAN3MCTp8OQsMATOkB PgMlSiYXQ0cqOWgoQI0UQZMhM8wVQuAVOwdJTSFERj5KO1g4RocyTJc8N7k4Pd80OQtoNCpWS0hR PF1uOX5qAZFiOrFpSeRfNAVzTSFxRzd+QmeLP3x2R6N1NbGHTOx3PgCeSBGrRTGqOFejO46STpKc P7OdM+ulNQDATC2/MUmzR2O2PYm6RqK2OMO3QO7ISwPlRC7jPE3fPGbuPn/mQJPtR8zWS+TkOQgA iBkChDgAelkAhYQAhpYNg7QAdtMIcgAXgyMmiUEof2sfeHYfe5UUe78SedQsiAZKhCNEgkBIjF1O jntJcaZKdcM+c+A3iQBYhSZRjDhhg2VgfI1VhaBoccdmduNagAKGgiVxdDt2il6Oe4aEdKSEdrOE jdaFiAStgxuSd0Kgf2WZfoKWfKaZhrungt+ncQ7OeSm+gDO9d1e6fHW/g6rDi7XHeNG8dQnuiifb gDXdjWHicXXeh6PmdMPfc9jTfQAHtBUAvUADuloAuY4LsqAOzswLw+cIygAUuRwquzsSs2IlzHoi u6AYs7UdzuEuxgQzxiM6wkMxzGwzy4hAwZk1uchGttZEwwdpsRVTwTdZxl1SzoNkzJhbvcpqxd5j xAZ+zSyOvD2Ow1h1x4KHyJxytrp9xtGBsQClvBilyTaawV2Vv4anzpKYusKcsdOgygO5wyrJuke2 tVG/tHu4xp6+uP//55qtpIV1fPsAAA3+A/v8CAwA//8A/wD///j9/yH5BAB5uJkALAAAAABcAvAB Bwj/AGsIHEiwoMGDCBMqXMiwocOHECM2TEBRIMUEFmtgxKiRo8SF80LOqzGSpMmBI0uaTKlynreX NbwRfCkzZs2POHPq3Mmzp8+fD28JFHqraFGgSJMqXcq0qdOeHDdeLOgRaciVKK9iXSmSpFaZNGHC jCnw5tOzaNOqRUrU6ECia+PKnUu37sKpGRHitepV4FWtIlV6DVzwZcmbY+0qXsxYqVG4QhtLnky5 8kSNmCtWrQq0a+CSLAkT/FzWMOKaYc1aVnysxrHWqy1HrnGUduzbuHM3rWgx6kbMZ7X2RTlcsN+Q NFWitqnbLuzX0GE3V/vYtlvb07Nr386Q82+CvJOC/x79mfRo4qWVk03Mfe1r162ht28K+ejj2fPz 67+tuffA8Ey1dJxBfxEGmkg02cSeavv9JJ1A0b0H34MN9gQXQvhVqOGGcX3323dAWTOQiFkBVlxL BQ44UoLrMXibPPIIFGNaEr4Xn3wUcijRbLVFVpuOQAa524f/IWWNiEjWYM08JA7nF3HClTeTWWCx hxuMMKJ1I47xuQahkDhVV9+PYDpFz5ll5sdZiAI1eeSbT6LX1YBxQnkYiy5SluVAMzr1nHwQdjmh hGk25KN92BXa1Jn01NCoo4pGytCRSipJ4pFMoojecaGNZ9ByeU4WY5ZY1rCnUoAGWqONkkJEJm2v tv/K06OQMirrrW0eRKmlSKZ0kpOceiYcd6fKaKypfTroZY1fqjpQjrgO5VZb0erUKKO2XltttXDy uuSbmWJl4K/C7jdjssUCxeqX0SEE7bawwtsTrY+iWS+t8urYZKW59nuSiL6Ke1LADfZZarHJ+iQo joP++S6uByec70NoClSxvdpOrC+llxK0q1/dkjsYlMASe66xWI5q6lLQPvdss/AaTKrGEGVr8bUV Q0qzhhyPGPLHmHJKoLDGtXeqxMimu9ONBLnMtLPVnswnn0rvTBDGBdmrc2PnnGN1Tvu2iWTPbwKc 64GDefZrfimrPPOxSD1dUISpynvyqCp/nRDOFl//3ffWcXXdtUBeF+613g6F7a2/HS9ZtNpr65c3 ugQhHdEvAmEOn5fsNi0dobe6DffKK1ett619o6514AQJTrjriE/KMdmzi102iZrOyWHKMuLNu06/ YB585i5zbiOzO//e++in25yt1jmvdfjhA7kOe+wJJclvz9tXumtodYKp/NQ5DT9Q8JgfM/yWDoO+ Le973k36RGsqWu/NjvJdq1rXWw+74dhDSJJqx6/u7UpxsjpX/HhiPvT9AjrpW9a65JbAhMXoHL+L n+X+ExXwSEpbz8NYxgI3uMG1bnoBzJ6ltjfAgiAwgVRb3keEVwPhOTB4XXpgoDjXtGilDIOmKqHg /4C4QfBMRSodqR+YQJg/JuLrKSg0IQBLWL0UGkR7H2Oh91YYM8rhZHg0tKED1Teol9ltRhgcouHk 4TWDKcQ3VOkIcMrEt/vl747Sq8H0qKhHPZrQirqyXbdqp72JubF8mqshDTNHPPVp7nOb8yEbJyk4 GFGxcAczCIg2o5c0oc5vIzyLFAvXuhPyEZC2E5vPVKlFVD5Ec4kE49we5D5cdc2SlWwjGwmXtFJR hTce2owSdcTEm32Sf30kpTINF0VXGtBjYxOkMxMSRvPVUJGyhJAO6xY1NfaRjYfD5R/T5Zv+IBFX ObOZTvzgh4KwMyF/fB31qNdHeUYqAPg0kgtv5/+tF07ThtdU5PkIgr6A0myBQwRnOHU5Pql4xJz9 4aD9DILPiubTIe1sZw3eudGM+sGiFt1jCUGKzz2SNAAEqWhBVIqQk6qUpUhxKUhrAFOKXrQhB8wV 0Pw5TYLC0iAN9KnVsHRL391SjxckYrI0g5eLECkje5GUTG+qkIpqlJ1YxepUh0jTqepRpgOpaVdR 2lKwitUhZw3rVPOZVoG0VYC0c9PY3vpPWGYzqNYcKi9JOckgphGcxXoqcJzqUKbmxhcxtWhKqXqQ dorVo+yE6Uy/qli1BuAcIVWrZVfK2MWSFSh09axNP8uUS0UztP/EZkDtatediZSru/zm65DlwSL/ eaiTq0HsQHQL2s4uRKNuzWdGBQLcj+ITuGMtXEWjOES6ivWtqJVIdMc6WqVEk4ui7WlBGpjNay6y oFZjZlGR2sY9Si2JwJRjRPMCoMb4QrfwFch7eVLZqoJUoyftqH6Ni9J2Hm65mS0lZS9bT86Slrpl PfBmx1rZyebXvgp2aXYl7NnJHuTBJK2wYi3MYKrmF8MWluxnp7uUWDJyoAalmTItGUTSpTGcmpxj b8rZVMK6F7G8fS+OeasT1LrUsRneqIGFrNySsvS1wS0pPRfM5Ope+KJr3XCQE3JWsCY5yVO28pNn SuEOe9XLN/1whinM0gb71infRbE1AeraXF7P/48K9eOS0yvHvMwRicO0i45rAF8c7yS0LAUyWVVa 3OIGerNH5iopH9xkBG9ZzIMW8YgjreAEj5bSCzbzpDcNYctS+tNYvrKmQe3pUjNY1GWutFoc6F2h fg2Au9wlH1nsxxgLdi8PtfON57tbHe85JzUds0wFPRDkLpijL81nkUP63ywzFrpmhbKHfTvdKof5 2pi+sqO37eRtp5rTqCbtt4fc5HFLWdVPWSRQTZxIFct5jf5zcYGNmER6C9OhjOGxn3nNY2BP+9z5 5W+x3TnWqxJbpYPL8Ck1Te4tW9rbHK52ZyWdaWxr++IOx/i4L55scUv7wMH+N5a7vBYxCpSRrP/W 2P/2qtAhzoOUtf7lYJ06Y6Z+KM9piS+f9/3rfkekvog+blaRLVwhD/fKw+UvZpcLQGhnu9HZdfJz gyzxCFtc2xSHOLodHfKnU7zrGNf6hEe9dTTnlZr5UmYyay24kIAzJCt/I1RnDFU4LmbH880xn39i bZQeOulWxSpxox7Ziy49ANeowTWaTdZ4Injq6G7rxjNedQTUAAGY5/rVsw52Kl8d65/v+NhBLnIm j1oxsRQjeCe2ZD6WEO6wg/td2Dvz2reXLjqX797l6+seA73jARC8cK1K3KQnWauKTTxIF698I5P+ 45uO/Jkn39WKl92ylheI5bP++M1zP+OnDj//94Efam53ndTih3zJCxpGlcP8dSlRY9dE4r8le/CI 6627f+6+57z3niA+93NfZmUkxVFXNVXXkIAJuFZgdn4c1m3k5oDfBmhUhXnj93GmR3KXxlaMdoGf Vl/qp2HnV35Qt2pnBy/2Vz0AJHsvdw5w14K680v410HhcXt3hxD+p3s9wWgdVYBCdl8GJ2j3lYCK JzjXkF8JN2UiWHaSh4EaZmBnpn0qlX0c533gNnIUOIGlp3nRt4Vh52UEcQCdV4La1RMAVEqw13b/ M39bUTQcRGcSVWeS0We8t2O79xRXpV9CZnQGgVx+qHiAWD2JF4hEmIINknkEgYiXl3lUyHdR/9gg BxCJZUgXauc6aPNyV+GC4sUVnnJ/6JUZ9YZzc8FrO2cQpIiHg/dOgjd4e9hRHOWKgkeERKh4i+c1 shgkjZiLlzcQjbiDJDYdkngANSCMwziJivF6n8GGWuE1LPgkMVgkMkd3sRFf/XaKTmGAqmhs2Uhw +3UNxiYQiSeLs4iL2pd9lneOi5iOvqeEFSKM7liM8GiMaCFE50ESbTcSzPhy5+GC5DEs0PhQuSaK uLd7/td/EtFuEJGN27hfBPGKrqh4GaWAg0gQExmIHKKIu7iLmLeR6LiOQKchkUiMwxiM8ohMchYY LoeJ/MiM9miPh8MSkWNbRyRjuZV3O/d/EP+RchLxjaq4hw65isQVjoAYjhJJkQooJFTIiOXYi1bk jiJZkqKUTPPHj16xksdhOC1YT50Sk7W1f82hd9Y4QwlpgD75kMU3dD4ZkUdJlEOZJueIjuaYjkyJ PU9JjE8JlU3xRy+IjyNziZjIFX3RiTriZ1/Eagj5EEHIjanoUa1Ii4N4ixZJlBW5Gs5QmRHBiBu5 lIg4l18Tkk6Jl1GpTJ3igl3BkuWylSRjNd2lbhgFlEaXh8XXh36QgLNJi+BIkbZpkZPhDDXAm7xJ EJapEB3ZkRkZl4DkmSEJmlBkf3+hIgJDf4/TnAHUfgvBD9b5ij25X7BZloPnjbdJiJJ5lJT/YZm+ 2ZuV+Zu92RCZyYtJyZk8YZ388BHwmRvvqJxMQU/MyI/0p0fLmIx/eY8pxFo0BJ8EWqA1MJ9Hp1EI mlVpmY0Fap0DEZ64aRAPGp8OMZ888Zu/WaEPWhBKaY6KyKEQuhMYGhElyhAnmhaSaJ/3OVsqMZUt 2YywVxL5iDZcqTF4JaLzuaDbCJ/FxYcMeaAdKpngeRA6aqHVOaI4EZwCsaFHiqTaV5zlmI46ihOI mKIXqqQoqqUsqiNsmDaZuBKk6ZLzRzAG4obwsnqrJ6RQKhBY2phByopB6Afw+ZgVKZ66aaAD8aZJ cZ7mmZ7kWZl8mogaKaUIMKgQ8aHz6Z4I/4GoBeGoXaodb0ZFLKGJ+kia+QmjkHOj+fJTKcamFMql ZJmKsJh0Blen4ziLdvqoXLoW6JmegGqezgCfTHoQSamRmQep6tmI8PmWD6GrbtqqkZofZ/gXpAmd LxknmUhPAYOmOLqmwdqmbKqnG4WhdEqgr5mddQqO10CtoSqsrIqtezqiHBquevqqf8qbtIquHTqc BMGnJYqh5bqI8eqt0yqu0ZqiwDqsuvFHIkU0NNqC1mMiBMOpsYOlIvpOPlquPxmt4/qgk+mwSdqh EiuiD/ug5+mnwAmqsHqvJcqUVQqq9Vqh9GqdljevHjuy3rqv/JobonmsL8ifmDiz+ompBf9ho86E sPIKoexEqwgqpIJnbPOZeNvardIqsQkhrkpLrjuLpCM7EOUpq9HKpEsLrinbtPhKoJintWx6qL06 rUjbtO+qpCzbsrdBSgWyrPqIjyp5qc9JINOks047otfKD7Oqpd84tnPLDxH7rXq7o1oqthzLsSV6 t/FJnh1rmbQKqyc6qIi6skrqtfEpuZJLpRDauEyLsmVrtmcLs/ZYHv5Zpix4IOCTs636tD1rnYbr owuptxdrtYPrsbEruE87uIaLrr6ZsfMZnJh7tEjbqFy6qJfXq5X7tSd7uYGbuST7u5w7H4MzswJC GMc6poEJPiZiutJau4brB6vLusALpcv/+63Zi7zgm7lha74Pi54ZG6vr6qTl67uxa6TBm7z8cLz1 S7wO27vMG67Nqx8wJ7B7uZ/UMy76KRgFi0py+7BNuq692U6PC66Oe7rk67qES7bo25sMDLXlqa6q y7v0m7SwC7n1e45fC7iTm78fHL/9CyTzhJI3q4y+8qXOCZNxK8F7e54+a7ccDL+Da8HwK8JgG8SC W8E+HKhNSrUj6r4Wiq9++71ZC6Fba7LRKrlLbMJVrLxju8IcIlJVaYlXKUXWCxgHDEgJPLU7fLVO bMVMLL7Lq7kXrLLnGpwZK6gQ+qooK7/zasKvi632G8UUe7V7+8ebixB/8Ac1YMhaLBee//u5BYyS fFknpfsU3yAQ31DJGlLGPay8dgvCemqvnLzGf0zECrzHdZy7tXq7bMzDgByftcuhV+rD+hq++ZrC EWHItozIA1HIiTwX+iimoKGJMUm6zpoUk2zJA2HMkaKhr1qrDBEPzrwdixu1Rhyrc4GhIKqOuLqe ilHIt2zLAoHLh7zLGVoQ6FprADwYheOfaQuYkmzJxXzMNTDJyayhTQq1HSsQz5zPz1wDd5Ad4qqx R6zM5ZwWHzulhcqLGVkX4OzNuhzOiOzN4hwRgcrMr0qVBWGpxkonQvOMS2HM7xzP0ZK75FwQ8TAQ Jc3P8XAHKo3SJ10ZHLrBfoq7dkG82f93CwgQGRyZ0Iyx0AXx0Nz8zREtEQIN0zfrkmwHg6LxOCXD FMgM0pTcKvScuPdc0iV9B1R90lTdzy09GbIsqyLdGBhKFIwoFB/KqGmBy7rMzQ0dzof800HtEAKd rgA9NPj4vOtsozTsFMX8znzd1IUy1IhbA1eNz/yMz1ot2PmsHepbz/esGHF502Rt05u5zd8M0Wjd 0OB8Gz5dLdKswfQctf1Y1J0SyQb7E3z91PF82lDNpK+K1YRt1bBt1Smd0vxs1e3BzJJx0+ko2UOx nma9FptNED+91pbB0GgtK8ostUcMqIFdIpDciYLpE9hyEB79DjVg3e+g2vIM1Qax1c//3M+IbduF XdUqvdWTiNOFipk3jZEK3dbEDdFA7dDyvdOWncu38tVEHdVzHdq+QsOakhPO00TR8w3vYN1PXcnW TeDbLS/63NK0ndVaXdXObN7nXRTrjZns+dtP8dCVDdTdLNwfHhvdTNxp0tkb3NigLdriIp3hgxOh tDUVQ+DXbeDZfcwKXskLXi3ePeFYvc8tLdtQeShHsZmSbXkZEheYndlpfcvurdbxvc3GzdCrrdyw KtIxvd/1mLZjDOAi9DfG1NfYjeMIXuA5jiv7jNiGDdssPeGCHd4leR9knXltceRy4eQ97dCY/eRN vhgjztZt7efNoc0PEdNeXc9x/dUJ/5HUQAE993MvjvIN9DDJZF7MNd7XNMPm5R3ezizbPU7bxngh b0EQF0LnaqHWS37qUg7oqj4Xxw3iHh7omZnTEHHiKd7cirE6d2RH133MCY7jBf7r8izjE/Pdbp7p PM7ps03h03QfQ9HsPULqaCHl7/3naf3nuWznrN7kPn3ZuOGusg7X9ryxB7HYA/0UdoTrfFPgkd4o BR7PNb7r2W3g8MLm+PzdEw7kya7Pbf7pom4fiALtZ/3qHc7WSs7hHG4XTH7ta53ZkyHr2vztC0Hr tJ6uUh0XXW5M+2MvwJ7dYm7gHf/rOo7mm27YiE3bQN7myt5TPhIvLN8j7a3wx33wPP8d4pTt4Qx/ G8TJmWa9zMApxxuL6GqxOhfTRAKh7mfyDpEu5pbM8TXe7kVv5jwu8rXdz4dN2LN98udtHQYx57GC 5NYe85U93O99814v8x1O9ozx2FGa4ew90hOtsVbO2HTxRPSCL/SA9OzeKEqP49ct6U8v72aO8iZt 7yOf7w+unNTS7CyP8PY99o5v6vZNF8F9592ulIuo3pYf8dS8+VXe+UGPNdMtQtei7jqD3SC99Lv+ 94Hv4+CN7BG+77ad8ss+LYmS+Iyv8JTf+PKN7ZI/33aO9nNB4wZ+zQ/voQqR3/q9vosh+n5jMXg/ EHd/904t4zSeL1S97/Ve3jyuz7H/L/vONC2gfh2379ZhT+3CTfAk3vvYTvOLAfIDMfxLefm5qOFz bBBXntwW3+gZnz+kj/EzDhA13r0TWMMgQYQDDS5k2NDhQ4gRJU6kWJFhvHg1MhrEWOPOHYwh493x +HHhRospVa5k2dJlw1sMb82MabDmS5wO/zT8s7NGT4M+f+7sCTSo0JxJh/5kWhSpUpcIBSYUiADB QqsGr2qtsXXrRGfODIqtEZas2LBQodKrQc+t27Zt4b5tS7Cg1INT8+pV29dvRJEaF5IEOTLkR8Md /y5mDLEoU5wzF9a82XilUcgMHw99SvSp5ZROg4JOSZXhQIII3mXt2vXrVdZgy6Yd/7uQLEPapB+y hSvXIFuG9N65JfiWLeq9p6cq1N18peKOKEEKHlk4JEfn2Vv6NPqZJU3toUd3Jn909PnwEYF6T/9Q 4XvYrV9/dd1aIlqzs2/XNps/Pe/eIKLrLYWEe+8g5E5jrj0GT7oIOsFIuo4jlBq0kCfM0LvwL+4y 87ApxzLccET3krNrNdVSTA2r+uKrKLfbzsrPv//mWmguHE/s7cTlFrSLLxLDq3DI6DSCTrEgG+SO KA2TVAqp9RZiUsrNQHTSSaqkQs0u1arKirXXUvIPLf72G5G3uH67cSDgiNuyIDh/XO5K7VC6LqPo ihSMzvY8M69JPl0SrTuhCI1SxP9ARzStIatSi+9L++iTbUbcaiurwQDb/A24hYbj9C7kFkQQzkQp OkCpO7HDbsIKSyVtyQ5dfbLQzGBl0in2ZHVOTrwQ9KpRrKyCLbaVzprt0twsHLA3To8zTrjjRFVw VF0hOtWgA7J9KU8jL6Ku1WoXeyxKzsJ9qdDyPjSXQTkbOhFF2FCUT1hJxUyLTNuCNC5NNNPcNFot e6R2XYayNVjbGq5lCU+G92QYXIIXumbia2qYWNB0I7aoyvW6+xNRjUE7ULktfwTTK/ty6o9OTVv+ d7hRf+Rx2nbDvfbmUxHe1k48Q47o4oqBVunWo3L1maJbPesY5KMb4zXBOFUzmdj/pif6lC41AQyQ 1E4TqjninG9OWOdtv626IaArtlgto8/W7LxB1XXbsgTfNY3LuVfSemu5NI3zQB6Z+7rag8MOO+/F gr5YYrVDU7pKxEPkTOnIdXta8Cz3qrfyhq7GelOvu150ZrCx1dZgbDlXimKDKG587aFBbJtzplWn +z1eY7Y9pTZt3Dr0dkc+mux8iic7qeLzSTJ55V9SPGiJW99ud+qxDPWuTpOrvqIB3XsTe2nXZT75 sZPPWS3ySRzfeddrSF7tidNfaPzi56effoiYZ0j++8mX3/362a95AFzf/gJokP/9b3vhKVnJYja4 BbYEd6Dimvj6h8AAKgx5B7SM/wId4kGWKM5i5FNcAi9IwP5x0ID8O2AKlWfCARIQg/dbYQ0FmL0K RtBpOMQhBHWYkwmGTH/YMh4BzwcVEP4liTdcXeveZ7H4tZCFKpQhRQpYRSx+UIoBTN8QMWjDGdYQ auH7IUXmccZ5WMSBefFhGd3IxIIlzHx+WWJf6phFl8CvYu9j3RQb4sE7znCLcNRi8wrYRSr+kYMw 9GEb31gDNEKyIot6ZCUlUscTChCQXkRkDAsJQybS8JNbhKEXoRhGiXXyIQoMJAq5OMj8vVKVeCwk GGVoNx5akiFpROMZF5LGibzJkbrUISYzeUxR+i+RmuQkLEWpyCEi84qwu4YLDf+ZSFYuE5oARKUr D/lKblbRlLUkZPpCNydi/vKXwDQIO9P5TosYU5bdFKcUBalNFAqym368JCn1mU+0wc+a9CQkLVdZ P2UO0IU3ROgLF4m/bZazeMDDXg4t6ct2StKd8ORoLD0Z0XpeMInTPGgMZ4nFO/ITlUlc3BMpdlJb GpScDVUoPvEH0RWaEpQHIV/glPPOSEISmL3saFE92s+aXlOkyyQpOVcKS5nCcadLVBsJnThPpxL0 qN4s6EK+8Q36gbWpOZWoSesXMMyRsYwYlaQ6jfpWkJY0lEyl6zjjelKVbjWLMPWo0PhK0FZOEaoN +YY3xWpXkO5UIMkD3Lss+sj/oBK1rdRLAFxxskR+jrSu8rShSlM62L8W8nV5pWVgSZlUiBQ2n4Ud a0yD6SOLDtONGN3oAitbgwTk9raWRapZ9ylL3zYzjJjtpFL/GdXfAlerWUWpYJmrV4AatLBfZd5X D+tbsqrkezIDn2y3x0vwClV1uzXIbc1bXt5a8YSeXW8yafpRZgr2iji96zMDmU2zPtO1ctVkfKtr kOv217+KxeI7eooX7j72jUMdqu10i1sIVza36KVwekvaTNTm9KEYPu4oPZlJV0KXq11lLn4Ri9yy JlW/+qOuiTeZ3xUieE7ejSBthVrbs0l4wjuGMG53+2ALB7khup0w4qZr3a/W/wDJpLmeYy3LThy3 B0lqkXCFiaxj8vZYyOnlcZa13DTrElbJSVayyACXPbVu+S9EchBUsIxe8j74vD5WM2/fXF4gV021 Xt0zmfe8GLTyhcZ1Tgq3KPSX8845wjzusZcJrcsuN5rOeQ7Zn8sc5iRb2i/BqyifOqbDOx1pT0nJ cpXNq2Mfx7nKj37nna/84yIfbbqX5jOZb4eg711pSoBSHZJ6thFD54TIeCb2QiK9Y0ezuoyrNjad K5xqWZe51l7NThB1DaUlUY9bImkYxFrC7CIjG86NVrSyIT3nWKea2T7LNK01/chPf3p74ApMYEbt EkcrOs+qNvcjV31qY/M73f8aU23Bl0xMWllpdlUbkqpOkqqG1KMG9aB4RLCc6IGnG9XPVvY/PN4c j/8jSMOWc7PXrWcAj/nd8CbaeOYN8W9BqFUUl7jFX41nUzt70aZOdlFD/nOg1yDkIP+4ZYYukVdP GOhFL+/PGXJ0g0Bd6ExP0qw7uplYubzX1Dn0qnhmEInXnOYQyfmbS86QUt8Zrktf+tRFrhupryTu Dpn7kIecALYXPbdBjzrVpV73foMGV5DJuu3q3TOHUahCYgd7xe0+aVgzGu2L/kXlKx/kuQP+L5qn COctMnC3i7yyP5cw0JXud9S/PfC6mdK4dMK5hnG964lfPNgnPnaTXznCJh//98Zr8IvfAx/46c08 1Y1ufJV4viLgxvvHqxzy0pO+76p3+9ORv3rGcEzhtTtbt0O9KrM1fuIMcTyFwx3pyTM6Ab+orOUv P3zLFr/t1ne6RNhO/4XMf/p5BzzU+R7pozu1oWu++vu71MM+1oMbj1kKbeM6eusWmqu58Ru/sGu2 L+M5OYsz3GI/4dvAhbi8tUM+/su/+4uIvCPBtzvB/eM/6sM/FSw26Psxtxu9j/M4GqQ+A2xBBMy+ yUmahWuaVgnChssIsXO8ipNAC3S2YSM33Rs++DOIJ4w/ETw6KjzAivC/GrTC+pu+iRg6LES725K6 0/uHvbNBL7RCLtxB5xAN/8LbHZgDNiOZkIUIu/JDOkk7tfPTOQ/8PT0EQaOSPxRcQb6DiBKsPhZM w0C0vyzUQWgrQ9FDtiokw+arvkRERDVsDD/JRO7rPpl7uDbrCMYrP8bDuSUEOHUbMg4srw70wxDU QSxMwREkxEI8QxWMO8+jRahDt7qLREfMQfy7RMsAGcjpNVbxFvAjwrGrQCS8uy8jRSDTMfcjNveL xj+cQtWLxJQoQKajRRM0vlssuvuLvBiEthgcx0GkREsExmBsvZeDw1R5mI3AvcYbxYDLvUYsNh97 P/hbPz6MQp+zxkRUvkp8RXSkO2+8vl9MyN2bweezQdwKwHNUxw3ZRMOzk/84lD3buz0JrEOcszsZ lLQPXD99hEInbEWDvEZwNEBZhMVtXEQcZMmG+EaRa8m3O7stdLob7LEtlEielIiv87aIm8dlBMNS mzyi3MAJE76S7MC3AkREjMWT1L9InD9bjMhAfMFEC72gG8Pd2klf7El1hEc9gQgjHMr0u8fIy7No zC3L40O3rEZXpMmYtEr6G8QcJMi57L+UnDtxI0DSa0hJ3D+FFEiwDLwpYwwMJEWGWEpWZMXCDBl9 A0N1873HrEwLocxxc0YIa8sPfEvLbBpw0zJU67nPLE3d4DkmRDYsez8oNE23IbndOznXnE3teEZi 08BJgz8Q9EfaNJdwO8X/yexN4XSOjbs41PzA3RzOo/Ey0lRO51yMJYQ2fHzOyik36rxORIOzjGtO 7OxO70wneTAIeQjPj/xO8xwRpjzPIBnP8GxP9XxPC3nCtuRN+NSO8KwB9sTP+txP7WDN4KNP/iSN +3RP8dzP/MTPAQ3QpJhGP0xPBRVQhhjPhThQ9SRQ/UTQ+3zQlljFxaRGDQUN9szQCDVQERVPC/3Q ipjPhlhKFG0MCS3QCX3RCtXPEM1PGW3RiNBNpmxQAMVRv2hPCp1RCRVRGS1RH0XO4OvMxSTJC3EH dzAIJ41S5xzQIP3OEC1Q9zzRI30If+RML+1R0HhSJ4XShnhS2hzSC01T/yu9UCAd0itV0y1lUiVN Un0E08Yw0zElUzHNUzP9zDa90fMsUQJ1UxuN0xVtzRWlRjv9iz2tATzFU4fIU9dEU/gE0hhN00E1 VIfgzP/s1PaQUkdliD7VU0eV1Ik4nn6z1PdMUAqtUTfV1M5MT8d00DANVTFdCEg1VVE91cIpHFiF qyvNUCPN0l8lyWlEUlpVCl6CCCnNVSjt01F9Vok4nIQpVgsrVFWlVCPVVN18y2R9CV8Cr43i0ygt V2gtVXSF1IZAmIMxndQZG2t9JyoVVjaN0G211vl0TKhgq2XF1VsNVVwF2DHN1X/FmTgynLE5onjV JUrF0nld2CWlU0RV1v9+bSe2KldpRVeN3dOBfdQ+PR14NRyR1SCIfaMEHdFLhdNf7VZOZQwGE6pm TdddvVVQNVeARZ0jUhh2jaOSraQ2xVRA7dl+XNSUwLFeQiN3YCeMDVhnLVV1dQedTdiFEJuclVqh 9VkTddh71RVf8IXnDNejbQik9dearVmnPVsxPQCoPR3UcQh2NdirlVcaDZeu9Vq7NQivVc6X7Vco A1U9/demBVxHfdtqrdbjAdl3jdtHstSgdZWubYi7xdvetLHJaiePtdmMbVRzldJeTR2xsVrPJVnF LaNXNZe6rYHTtdvHRV3h5NuHmIdRfdSAFVhbfQiDbVeE/Vx4LdzRhc//x01dvP1d1p3cXQqvG4Nd Mt3YspVWmuXdwsXZhN1Zw0XV3vVO4R1e1P1d4c3b2YwkcT2jJ02jaB3fs01egVXbqXXXqY1aslFY c3vT6v2LvI3c081e+5Vc19yovh1YUT1XPtVY81XbJ93ZttVZhAVdVgNUVY3fpFDd4b1e4L1f05Qs dwJfmSXX5v3bXc2Zjz0c0R1Z51U2YlVZBnYJCL7f+s3eFJ7gcF2npH1Wjq1d8oVhKD2YASbcw21f 0a2zBbbRrS1hiljdB2aI1RViCZ5gsYWkGF7a5DVVXV1fkFXY9lVf3VUzH0ZQNm1cIK4IB55f7t1e 1uVe4r1Y/+VfUgVc/zMe03Zd190N2d2l3iAjUq2F0S1eiS623zsWYyOWFfiNoGhtYtkl2yhVWwJ+ 29x130cj0kzF4h+uY4lwYOwV4yGW5Cv505PdHYxtWqft2GbtWMQ14BBe17ZN5DclVBNtZEcmYi+W 4LoV4lYOF0VG5abJ4NpF28vN5Omd4nfFWTgmZXqN5VRmibv9YldOXUpOEm09ZRJGHP712zI14zN2 UvZdY1AWWRFmZGDW0mAO4lVu5QjG30D5WSzG0O1x4k2m4UhN32rWGcJNXFK+VMYd523mYoggZj3e Y2SmUgwdVFk+GgxWXo7d3P8NWVBWZw8O5S1LZn2W53meCEjGX3v+4v9wttBWZejKWdpmJlUAnl2D LujQld7Vm9cateiGrmf6Vd2HPub1dNUsJudyBlgNZtrxjdaqhdtd3mEe1mZ77WfF9QafrgFviIj5 ldx7BudwntsJJecq5RxO7tjyhelzZeOIiOJeTmRlvup5DmqgDmqtfohhDl6JxmcnOVBFtteXhuGY jeknZmOSrWpCO5LwjIdLvmRH5mqgpueFAN47TpR4xlKkriSzZd6KYF+eNUx3XGA6flAAAIDG4Oqu NgitXux6DmPtVem/kGy1sOR6/aGBptm0XgnENTfE+7WkplEthqvFTm3GXgjMTo/WhgjVbonHXoig lmzVxuy6ve3sve3/1X7t1zYI3gbu1a4BzP5tlzjRP9Ul2W1U2nzDIZEHjIBuua6zxVaI6t4QzH5Z hjBuivhprXZs4u7t4W7txc5b2x7u8E5v1kZv4V5v9fZt9m6Je23YN/pjM+2HfqiB/DZNdySS/gZK y5Js1Kjudyhu3Q5v8o5t9U7v4Bbu2P5edzJwBUdwzPZpC3dsnzbw7WZs7u5w9DbuBGdw9ubulBBp YeXpCNpvg8DvFVdxWWkwnwE2OIxDGfdE6mZsu9DwENfx8ebwHkfw9g7xFs6oNJLwII/vrf5pyPaG EHdvD38I+HaIHU9tKEfyEs9SYtXppPiBHzAILjeX/N5v/A5zFr+S/2Ud8qCik5ZziNjztYtMPIcj EbZ15w2xbgCQCgE/bycf8R+f8j1vp8XmV+PV8CN3CLuWcgCI7A/3cdg+8ChviAan8ipPCjnG6pzg 8i//8hrIdE0PFBYPc/0O9VB3cRKp2Lb63sq1kM+Im4ebMjk8zAcZEdx1Y5xujwJfbYK4bj1vbwrn dRH/8yPnpUA/Wu+dB0L/dYmwcF+PcglH8l33dfeGdEmXdqUY6aV2CUzvcm3f9k3v8k0vlTF3CFAv 81J3K7BNc7ZiENdLmgc5kp/8NcR7cwuJWqlFZFtfb+TI8ztvcmBHdn9/9kDXKPECdPHud4ZQdu9m 8h83+Cd/9A1H9P8Fj3aoeFEUlwhu93Jv//aLz/ggEfOF8HgyB/UN0V+Sb7A097Rdoz02X/k2a4/z oVpqdmszs/Mcv/NcZ3Qg53Fgp3I/B/L0hjJe7/mHv+uhX3B+f/b3Lvigj+9jh3Y+0XaIgPpvpxMV D3eGGPdRtxBij7KB36U+Yfe38QmM6Ik84TbSdvN7Cw/CnnXolXnGeBPePpFmb/b1nvbgFnLePqPW ZifVNvaFd/TV9u5ob/C6l3TC7/XBZ/qFj/gk4Xip7/Spx/jI73gy129SH3dSZ5AWhrIhX6eub45V 75BBiYdYcUc4n/EZV3sPfvmbNp3QrrYJupuaIfGcYDCikmzvzaj/VMcJ2g+S3m8QTO/2qYf6jPd2 4k8SF8d8j/94rT91gRd4fp2sdBc8rFuKBfSMsQeK/471ixxL50DVXmVn6EXoHTKRn5KW3wdX3Yek YT/eU+f6lkh/C5H/9tD04xf+je92+x8RMR/zkAeIfjVqCOxncCDChAoXMmzocOG8gRHnRaxRcSJF hBgtPuzoceGfkDVEDvxTsqRJkfEGrvyzcmWNeDBlxpxZk6VMmB93PjxwYKBPnzWEIhT60+jRozyX enz3rsZTqFKdQn0K4OpVpjszXszIsSJHiRe1PsxK9ixTs2jXevzhduAPuDXiznUb9y1eunfZ8h1Y kCBCgYAJ/h3c/5fsRq5hJUJUDPawQ5MnUUpOiTJmTMkjMSN8+bJmTs6Qmf4EmtQ00KGlg6pOPfrh 09hTB8p+3XEiY4peNX7V/dg28ODCeb6tm5AuXLzDIQsmTPggdMEFmy9X2BUs7q8WMTpePFxz5cmb wcsMaVmzZ8w0dd5sX92oa9OlHc5nXZ02ftqynUaNOtw3Y70BKBaB9xl4IHDI1SBPXAz+II+DciE3 YXIKIpiQdIE1Jx11F/Km3WIAdofbbgaCtxmK55kXj3mZqcfZZyzhlFBo982nWlDwxZeafR5ShVBt /Pn3X4Aa/aaYh0kqiVZxFdq1oDxyKdRkXVQu6deGHHZoUIf3+f/W1YdebbTdmMuRdOJIImm2GYsm leeSZzrJmZ577AWnFI84ErWajgzdOFxs/QmZ0JBEcscVooiSeWUN++zDKKRzJYfQg3e5FaVekj75 ZKRYcgndYAcBVtiBJV4XFomHguidbWqqmGJKla14mUud0XSTnKDZudyfru2Zo0JJ1XehU1iZpVYN WRmr1rIAINSss1hJdNU80Dp7aETNDqTtttJ26y20OzmqkKPlNlTuuI2im+5C6w607rjwsosQuurC 2y67jj7orrp0pSuPvj/o62STP9Z2X4bOZfgpqQgmul2RIR656G+jqZkmZbFiXBmLHZvnpno51Rha jDYG21qPwqL/1udQB1KVVbHROvuszDR3a3OyMyfkbc5eZVUmWD9XW/PNRedsM7Liupvvo+Q2rS6+ DDEN9blPS2011Vc/7SjA+zzYtcBbe+1WwAEbZ5x/Bh9IKpejhmqYh2NFPOJ1Y1VssWUopjjeSWd+ 7KbIONFJo4zvFdWyyqu1nGeOjSP4zlX8VXU00jofa/nMSed8OUZJl3h0tkRTTrnmoytUer30ih31 u1jPq/rVDr3uNO1Vp8v1wGHrHra+YFNt6V5DSv4jwtOxHRjcSo45oG4J2f15cLKm+bF4JbE4nk5w ijbyjHPyqvLhiPe4+OLC9lodslEhqyzmRl++kLHdcvWzdgDS/88+zqTrvPP+/Gtt9dRql7XWxY51 BayaAPE1rq71i2z7YKC9HuW73B3nB+9ADlWCVB1ROUdhWrqSmLIDtPoxrzpnGk/e9paZGoWEZDZ5 EYxEw6uiOG5leFLK+E6DoNKtT2bx+xbPwoU/s4QOO6riFreKxsMkPsRcsCOgAOc1Oyg6jV9UPOAV aRevR3ENQr3DXbl210BKzSVQChHSwTaIPLcxqnnNgxiSFlW/iEXvMghZE/VQcj2X1GokNqmRrdhT MpO1ZmWo4ZH5gHWhJfoPf5Xz3+kyh5XOASBVcBxaiRyJM0ZqJXUBTMgnBwjKptVrillMoChH2bot NmhcvBsbuv/ukju9WOqMZyQegozXwSWl6o1uDJAvQyQcjYWnRa4yZsc8ppBblUyQg7uTDXHIpz2J D3F68hAnb/Y+JbYvkkD0WSXJFEzNbZObDCmdR7aYtdl90pQDVCcCZec6rKmya6xk0MBiac+xXapK b3GKBdPWHyAVSjhb8kukEuVGRdlNjr35DnguJr2/tbAlb5JRM9eD0V0BB0/XVJyvCrmQYS2ym9tk liQ32b/RSSsjRCTQ/MIJSZZ282joRCfU4Em1263ulKokoDvdKcqgStCeYnQluqIUSwfmpUpVCdR+ ltS2ToklO0UyovOqCqboXUwheLxjV6knspnQiZkIqs+fwHf/SKKczKM7/CEQ82fT/bFvWTS9lvyE GRZy0tWHmANXElFnxcGKzYmpVKC55PXT/y2WdfbE51K9+EAGQa2VjyrOD35Rg1/8cyrEwyVVffSO u10yqxAxkpn+Nj2vxsoybeIjaGAYyNjK8D2N+9VH+YTI0CZUhEgi7ZKEylvIRAlCA2GQg77WIExd CrkOSi5cfnHBzf5Cs5PTj6CGayD/zGNQUBHRVsUEMTq2SqKqJaYx4aSSF5oVRoM8EFvdihTFoZWk 2k0SOJkIKeHe9zDFpSym5sJczFYqQm+J0maDp1lBQRW0/X3NZ2MTkQx2Nze52Q2JLnQe8bRWtW3K FY1IJriz/64VKeTT7Wl6Nb4He+nCLH4xcBAcYOQuaEF2uQtlL6Xcu2jWLZytrnUFOlAY20Zy3+1u 85ySmA8ZyaoHOiZJYFW9WY0Vo+5N0o3YirK20pCGiiQymMMcZuMa18bHlbGNDSxjClX3gpnd7DsW /FT8pFHMZzEjfpBMkdHuWW5WzTBwhzm9Yp4wvWv6THsJd6GU+al8OPJyQlZs50lTOlIQujSmAlwc 59b4awK2yy+i9GMfS0Wzco5qQSvdlCBR+EviPLJWw4sgPK5pMuaNcozIGmIlne9Xut2yfByt6mET 20MyRvCDJsXcS28qx8jlLHUzG2cgV5dQqS52R4Rn5NFK5P8pXOFzHBMT6DrSSsp9a4gLl1nbRa84 vpCmL7yxLe95xxjBCIFuXm68F0pdqrqZzaypB1JtPGeQ3rBB9ZAnHBU9YxWO4/WQrM5L0fAwZD3v XVLKbsgaHJZv4+QzOMhDvhRMYzrNxq2UgKHE7BtTt+XSRUi1pTI5B4d8UNomKLe/3ecfOXlJGy63 CmtNZGqaOMW+oubHRa70pTOEzPY++YElVKlmJzdTLn/KwJnekIGm7bpd9yWFgTnuJ1MGrMX+cnyy fEhrilTrbtd6mTENvE1rCrl0/zGQqYt10F4b5GYcXsGHhBElW4TwDx3uiVKoah2p+NHASuTbIw/3 klMKQsv/tRBmn7tZmFM37wWPPINlvm2ZV6XCer7w2Dul+HnbN97mkzyj/FADP8he9rB/TXEVsma4 MLu4BTYOZfMu/Jff3rOB/6x+RG/40Rq5+J3auCIZb8OzXKP6NbiG83li+9nTvvvbz/5Z0Pz0hNi9 0/m2S5k33/mYOx/hC/k8duOfH/BDaljz9aj9tYL96lvf+vRnCO0pRPchxPe9nT8coD8MBAKSxbH9 15qhXF1kWpotRN79n5DBn/IZzH541/89X9qFT6QxBf8NBP9h3/V1IABy30AEIAGyoNYlYA0coAIq IAwyRe45IJScmYRISvqh4PsxxN9hIOkR1BD64JVw3G2B/yBP7J//NeEJPiEK1t7srSD9ySANxqAV 1mBHjN9/CZw8hFoD6qC9GeEPzsacAd7BqI0ZkuERTlMhnc8SnmD/NaH/0d8ATuEK2p4LLl0CyuAC /uEMMuBxWVfLfWEOntkYsuEt0ZlA0RkjXld+9J0iwtdaUR9ClKATmqAPDqAUbl8AfqLI+eEV9iEC WuEVesSlwVzAiZp1peJxTeLWzRwkNt+cKd/8weKwzaEcKoQJ9p8dfiIoqmDteWIBFhspIkQNLmAM jqIWPsSlVZchQuMXSmMP4iIRFkoGodpTqSHXWaOqjWBC9CIJsuEeBiMLcmIxzhsgKuMMwmAf7sQX suIhSv9jK3ojoTBi180fN8IfLdqjmO0fCQIkOG7iFHYiHkphC6bjsJGiHyYjFmbhQ44ctalfBR6b Pw4hnm2jGQ7ZzHHkRf4jJpZgOALk/3GiCgojASaEQhJbQ7ajQrBjIH7ENGJawIUaIV4k8vGjPl6j Tn4kmNWhLjKhOEKh8w2jUX7fMKakvGWhO7ajQ2IhMh6jXG1etZkahFDbTfrkbHikZ2GXBj6iVv4k L8qhQArlUljLTG0OzwCRJNkVWkbSDwUWVtSeXflBuBSkWm7OVKblTKGUWkqLENVUQojiXy6jKSLg VSygsdSgWtzCLfyCY94C57GfwIUlEdIGAiDALW6bd9H/nGX2Vy8G5S6G41lkE03ljybBz0qhpuj4 Je1lxWvKjAvqoUoJJs3cVE2lptGoVEO8oz9kxQGahSl+Sx8C5zL+5cxU22PGnHU1Z1biJEJoZg1k ZlRoJgKgERCK3mcSmUCO41Ben0hqBV/5pTmppkPglF+S59HYJQAEY87Q5knK3uWUk3meU1umFF+Z Z9IIJ1QmZgIaZynmZc60ZPxEJlVGJmUKXIJ+5DtcZ6BQp3TGhoN+3s1t54ORpFAO5FBq4lmuFFyR p2l6U0OkZ26mFPfZ3lW4p0rOp4na54jepzZ5qIzmZ1QeTXA6yzvGIPv857Lw6FVIpmQqKGRq1nIq aGVa/6Z1ZqZ0TudTXGeSLuJWWuiFcuglgidRjiNZ7KeJyqV92tVe3iZgwZX+HCVytudRvo9u8mUj AeZ9sqlb4tRxKqBx+udxJqaNopSPOmYN6Omerl/nqZ+FKqmg9oeTVkWECg8kSilokiWHMuETYp91 dqiIomlfxRV6ruZuxuikmulBwmZB3qH+xNWLnmeYtuheiulCaKF6yqm20Kmd3kKBJkQFDmkFhuWS Vmd1Tmd0OsWhbqUkKmqnACV4kuSjQqF0ZqZHaGlctmgPmY6IuuimQlKKAiN7UiEVsuBJreWzqiaL ZqqzzlVvuuNv4qiN0qAfvs+N+oNksk+Qrh+fthywOv8osm5jkw6qdgLrTzoqURIrpCbpvJZFpT6S +7TPpZJqfZ7mwFZrQtJmOWmrmoKpqNKotAasuALnuPLocWLsxWKsY+KPgTpmdbVroAqqrippvQqJ ZjZo4BUhvmrXHJplQNIhpEbnkhqsXKUmSsXPXXrrqVbqh8YPe9bl9unsX3Wpw3aL/+Us0b4pa8ak jsYPjzblgD6ttMCql+ppkC6nqYmsViqprkpFpE5noRpqg8pfy74YzBbrCALkkgpqzb5dAc4mQg7H hlJpcDBkMuKtuT7kcObMxy4E1ioqsnqt2Iqtgw4EdTZohJ7tPz6qowpryRru20beHn5q5dpGd44m cAT/aJwio2Gy43DWYMcCwMf+7d9uJ+EabkJEKrIqbi0yHbH+XyaOZJWCZ9h67b9SLkLC53L4ImnG bl+Uot4eI0N+LucOhOkaKEIor5QOLs1G6qAcK6/mLshh4rCiIIbWLVBS7+QWn0FWR2iubR3erdN6 rrh2ruciL9eWbtYCKdf6pPPi7r+SbINCyDu4YsiFJJZ2YFlaqTiS5LEyLlk0qvXabfCuI1QKr0vW KPIur/Kub9aGHCDdR80GsAXLAwLk3itWb0BeogGDH7/qa/+R7PwKcEfEriYCL19ApAL7A5m58Cmm qgO36+n2aZ++67xdHHC4LfVG53SSGeGiGbY1KpaO/68PiqT4zmzYqq4JL8TL+uITfzBaaKEVOl0M QsjxtqT6JgSQNvAW23CxIVpnDIe/tq3k6ioGp/GCZHAOJuIQq60iQvHL+nDJ4m4TNwQR1+7+Qkbf yoM7xt2CQCT6dvEN07D6RrC8Wdwz2caTTq7XCrEDhmGxZajmTiIlL0QAF+4d43HmCqsUT/FhiqIL kxwWE6bo7qn7fnEXE3IYe88EM3Lhsq7zYvBxaWYaC/G8ZW9ofqbbIu4mc7J3QrF32oZUItgoJ6Ax py/6FjIYM/P7GpzFLUfbOm/kIq51WnGNZXMuX+8eL4Qb42L3kmE+ssUupzAUGjEfX7Ef3+ABpiIy L/8zF4PxKr/rMw/brViZNFuzPr9iBkeJdFZjNn/zpPluBztjjQl09mVyOHegTv7qR2SiaF7payxg yUUJDF8xRjcj4KLy+qIyyGnUGJMxHVcw/kKJLVskQFNaCn+yGN4bQjsf6+Jidu0kOYfn+A4k+Sqg 0zmgC2u0Q/Bp+9YzscUJSJNxD1tzPyMiLnfhSzeu/37wDSLiLytd10EVy8bhSmeugWCxRR/XMY9y UyvEKr+dDou0PicpyWUwGx80Dhbf0wHyVMtbENriLfLFLldyjLXxOiNzmY2yNS5ydRzr4NryQSe1 XqdiWINcNXahNQpd9qlNP1o1WoCjHLM0cQX0Oq//s0vHNVnMq2DfIGEvdmKHnAbf4GhLHsWtXvF9 JV1jLqNatn+NIZlps8pxdmd/7WaL3wYn4mkbnAbTtiJSnAUCiVd2ZF1THzpXx1KT32zbdl8ga3Pv NmKn9OQxNRu2CIfpDfkdItNlY4N141WL2fjpIHc7d1/otjYzdva9dXATWmvdG1uLYW8TGQfK4r0m aqUxNSmbN+6pHG9HNf3NN2pjd/WoN3PjslxfpteRXj9S2n+PtxHawJjhr/gJOH9DiqvwzR9EiWRQ 3kHvdoJb24LPtEPDWEVXNBtKuIonhA1IeH9B8gZfeJill3hQ3k4vN71xnQZmV4kTWVRTd/a1eIsP /4SKu7iQD/mLK7WMU5ox6Y0r9mBpBzS2DY99X2B4T9psA7nzrfiK1wCSs/h9WeSST5r0lASE5I1s m7ZUWzhvBSE2auSYe8iQczmRG3mc3/FXmQSHk4Rup5+HI0Z3MIrNEXfyNfidD8Q3IPphuHide3mX FzmjHzq+qgiHI3Ybx7dSR/dDLNRVpV5wcKZkc+WdfwOpJ3oNmLqpr0WRg7lCIPmRS7qF+oIvoNBI nLk86HmMV3ht//ami4gclYlo4WOq9fhUJzqpI0Sqs8Wq17mrO0Skm3AC1EACTHu0M+6sz/rG3Por /vh0/zlPPI+iuFiS1NlMw7qio3qpn/tZQDpCCP+5lzs6l3c540Y7vUt7QlT7dl57Q+g5t196bed6 eTcGqjiUQ3l6kcniOMP6sZ/6qaM6wyf7TkQ6u7/7o1P8u0P7tA8EvlN7vst6Dei77tF2JMddv8M3 Q4iQ2IHXLxELgw0Zsf/ywjO8zCO6w5PFxL86ixt5s7dsvWu8vVc70GsltoM8tps8lJf0fm83r3e6 3GiVdxg8hDF4fY+5sTe81R87xM88Uxx5vLv7l8M7vtL7xms8tYs9vl/k0H+8rBd9Q1A4cwM8Y4d1 w1XVJUE9cEi2ucd81WN9umt9RzA64DN74F/84Espx/c82SNExp+9P6b92rP9h5M8lO/6IWq6aZ3/ Vmk9jLlTFdZbfUKke+cvxZxTvNeDfbwT+cWLmSELtYeMvb1Le9kzvj3q+9qrfdOtudI7hIcjdIY1 2as9lN1vfnAsPPEbu/EfP0+4e+pzPZgrP87bWQRjLesLx+KL/c9zPOzXu+zzBTXPW+0rhC/UQz3U wPiP/8iz93TDN+/7/qn0/tMLP6TsvfF/vvz7vUc0u9dL/PKDPZgZskcDxC2BNW7VMHgQYUKFCxku TPAwAcKIEQ1OfHiQYkONBhHU6OgRQUiOG0mWNHmypC+DKg+yNFhPXj2YB+XVkFfz5k2DOXXarOlT 4TyhQg0OrUG06LyjSxEqRfkUKsOOIkFGtXoV/2tWrQq/dTXY1evBbzXGkjVr0kYNG2nTLmTbdq1a tlvpkix4l+DBggTv7q1rEmLgixgtFr4aEvFHxQg//nWcsobLlgnr1agc0+ZCnj1/7tTZ+ajToUpJ j05a9KBTpo+zTm3M+DVr2bNZgyVb9vZYsLrN4ka5Nq7Bt8KBK2xLe+tAhHv76vWLnHDGGhcnTh+s UHpJ169dc0wcG7psleNdyqz8EuZMnDRpct7pOSdqo6hD16+vOuH88CanMgYpkqr9BBywpN0Q2s03 qIozTi645DLoDxsiJPAqgZ7Ly6/m8AovI+qqq4g660Q8qTvvAKyqRAodY2k8yiwzbyfzZqqBn/8a a8zMJhv5OUjHHWlE6keEblyKH9GYmg8/FWHz6KATF0NMySgJ1C0srr46C63gGhTuQeH+UOvLML+U 0qQNm+NroA0HHIxND0GcjjD+GguQO++qYpJMrHzZc8/I+JTxJctewkwefn4qNCdDeaQxs5p23NEo H4kssihIS1vq0jxNTChAO0/UFNS6ELySSq9GfQquBVN9UMI/XHU1VI36Yg4vCw2iNS/kpOsQzop8 xahX7bijitiRoOw01qdY9PM8QS3L6TKYDO3p0fdwUjShIlWDlMd5KPVWKB2V8hFcg3y0UUjoUuxv WGSTfRcq3hai8qwESwJuLrUQgmvMCL+UEF7/hiw0M0Ncb9UV2F8/VDjOjeZs0k5j8Zz4zoAbapFP P509r7L0Knun0PYMnZYzSYUkalwjH3WqWpYZDddlSWVW9z8oa06MU3ct3nle3HzODcuTjpsrruMg rOFVf5EeE940c8VQuedovVA2XkF0E07BSJyzvyUXo5hnjfrsc6UXm30HJrSj3VEekBnFFqFCdTQ3 tR9RPtdcb1HTtshq8VbR5ooB/PS/sA1PqFTewlrcXqETGtpLCbVEemc1CXb61lk5tK5DNjnnNbuF jh3c2K4pJh08wzN2yReZXnznxdhlemfad0Cu1tEae1qUUiKR0jvvR3sM/m0ehxyQdE+7fjL1/8MV euYZg6CHXkrFERfLseHiGhNgWC22Va+nlcsVfL7W/DD0rH9tSDGuOx1d55GcZ4i81wP1iad6sL0d 0c9M5l014NpWt/pmlKH0rXjZCs92Cic//5wObPOrwfSkN0ELVs82VbJNVorWQchFaC1M49n4EnKm zEHtadCByOfe5KvrkIhJD7tT+26GMwkmZFk1QBvsbGc2m8yEHzPiB+z656iQpYtRecOU3ohyI3KV K4lRnBndZkNDiMGmTt+54QSpFz0LRg+MXUQI9ZDDOOs9xoPFSVq/RPiu8qXpQk4joQpHRBEPoS9h 7DtWzjw1MZuZbosKIZsOZ9cxHUJLfzqqCf/I5GYjd7hjeMbTFqaCNK5zoatbVDTX8aL4GK75sXRW /OT8vHgQCkrPi9PrIhnDk8Gg1aVo+/JSQtqYrAw5B0PhI5+tqFa1Ff5yV+vTyB4b+Ed22VBi8dvi DptlGdsVsm0gc9sj5eGOm7ijBo985EZQdilvioY0q6mBH8YJuIft8Wt0auANWXlBVqoSjO4MJEOG sxDvzQ+Omota+Mo3GzteY4UiAl36RNckG37SSSmap0bqwUO0ocd1DU1kjyhaUYteFKMZ1Sgn6wJI g6KIXWBT5rtKycVTntKk8CzpQlkqq/Hdkp+8HBhyrnGNGtT0IDatzi8b5rAYxpCBTsIT/BT/ulDX MTN2sGvoQ0HmDka+Q5vZzOY2sSnVpgApnAHE6hIN4gdykrOrAjImKGsWyisabqXyvGAFKZhKtqa1 pSraXV2kZr5cMudgvdSKTXNaU50mAKeCMcxT3mciYr6vRCN1ntpsx9izdawy2ISqNqMqVWxWtapN 4WpotkpJ/IDVq1/dz+BiI9R04syj8IrnWk2JypSqFKVwjet+QAOaCt21YLncpV0fw1ffAtQiAmWY nESZWAhCjHDNk6CMlHpUQZmHh9mEXWZtR1WDZFaz+llIN8PZVbB6l0DoDOlQP0VaxeZptWr9Iiph 69a2zpZA8cERXRUSNfvqVq9X4atB/Iod/4Di9K8vdFixFDI6TnlNfsq9IaA4pkODqK2ylHXwZSm7 TavWDUj0yap9yokQ0X4XOYU1aOCWdNadoTQh7ySjKtfaVtnClzbynSt9cws+zfX2twrxbWCEyZ8C l7hiouvOeZ03O9g5mJAvOXI9nBpd6T4SqtfF7IUZYiQkJSVJ4/TDIQ4R1tHS0MAoipgDFcLlWMG1 pGZesUndKUYU78zMV4mzVtbznvlmBXNompoce5vTm97UpjgFtF/3u18YHnTEfywcnUjc0qM21GxG NgiXKd3lxnKZwgepaqXnnJrRoEzDCQFtDbgcWhAfpNJ0iTP8HnizAy+k01jhdJdRTWuGxP+Zy7A1 ZZzDSGky+jqMrC2zrTUya9bE+inIJjWna82QQ+FoxieZs1+4PJA5m3nW2L52l7O9bGZPutJ+5fJ+ 4xzocn9bWMmLWPuO+aQgz5O5kIbR6zBtOy7z0MIVxiamN03s/GC4u6L+aqlPnRBlW8XMxi2t4LQI a3/L2dYH18gzci3GtfJ6er6u9SHcrOqIP1wrEi8JsjuNa5DL+DMQdzhfzFyQatea2tse9rJ1bOaa jvvmh7Cpzf9M6Z1/nCTjXedH113MdwcSRq7bWETv7dRlO/Xe7zC2mS28cTPPg8uk0XaqwV1prxab 1sbuusiXPTpmI2DVXEb7t9dOaW+7fez/H1d2ycNed65vPdfozrU7Kw29vsv87c1++8PpHndwH57m Yqf54K0ud7gjZO6p/vbkuT5suKPb5YcQSKU3r3kL0d3kBq/7zCHf5ZyXe+z8Lb3DKd2Rsw++7acb L5GLDN3XSVSpZu4hpp9+72ximvdTRXzigX55bneZnGRfvPEXP/IuH5NJald7SKSfcG2LfvQyD73o V098watZzRVctt9prcq+U9zt2h+99xtSePUjfuvwP77gVw/47pNe/V2uif1vvX7nmLzabiHOMq/0 tm/4Yu0acE7cTC8Bfc7cdA7nuE8CQULtPGL6Wi/9aI1YtuNrHO08doixDqKhog7qDgGq/+6N39yB 6sTu/Q6vBZuv/fzv+kwi4UyH+g5h7aJv/m4QBptvBtmv/7rvB02O/OKJesCvy+Ap73xtCY9w/rhP 5NwP6AaP+eTPBwnvCXsw7qbw/X6C/1ZOCwkC75ZtpqTwCgsw3BTw5wBszhrwpsYN0Crv/g7P9XCQ 5nKw7ICK0cjMqJKOqSRKh1TwEKgq6rTtsuYsqoYwCxXxDDfCAH+QJCoQDatPB/EQCA/w+Cgv8oRw EUcP/TKO06In/LhoDJuQ/FLPBUGO/oAQACnv+zpxCxsR7KwwFeOj2yyvCnEx82Kt8AJv+GBwDX3L 5hpwGG8x0LSQF+0QDy9w/faw4eKKqf+SLFDOQxAla9lOcBCbThAVYhtfkBG/EAxfMBI1ENw+Qtum 4hxTcQIhkfTmMPQAjwg/cYJCr60qbu+acB797R1V8RcZkQofMfuKTyBXMQiXbyAJsh0NEPs0zxdX sRV/ERgXD6cikOsArPkEjeT00Q7zsAI7ciOvqKgcbWMI6Wx+r8tK8LoM0du2MSVhEQDP8CXD0CCb LSPBEDGsLx0zUCTY0RufsCYx0SA98R7tDtxKqQjlcQnz0ScDchZpsRHtbx9pkihj0h3XTxzBMSYP 7u4erx/lDhn9Lef4atvCsr8aMOdeESJlbhnrjnnWBb7m7ahAUIekjtO2iS73rS6psPH/Gg8W9TIM JY8Lt5L1Wq/tWo8Kc7AODQ8eK08O+ZITBZP8OI4F/e0TV6wVH1L+uDIW9xItgTIot20rG3Mzu47x ehDdFhI0wRAiYTA1u63T2DDczjIOdU71KJIxHe/5zm7tbpAHfyrRFOyG1MZ+mqmHekiyjqzqjozm sIvKjo0fq4jh+iiZAqbTVuudXGuV1mulWAzGujNPfOvPjjE8E8LQwNPQCAu5QGkDEwo4twiymsnB 8G26JmuqKMw4n+6y9kP5aKOw3K0Dr0YilCTWUskojRI7w+ikgs07F1RKAg3ACs3PBu0YHRTQrGI9 bbAtGWhBG+sgeig+hU/Tqq4EKS3T/xj0x9SJ6BKiczxHwGTjNF3rtcTPCA/UxUzURlXkQSd0PAUt QsuyNWaIwD6K9uCrOIt0spzK6SosyvJzyppzQTV00TZiResoStzMOi1ulRSUzW6US6FD0HSUR8NU 9f5sTKNilBat4YRqQx8MyaLLQ7ELsyjMukS0Sw/sTN9kp9RHfQKKQjpO/NiqtWT0veqUUPuMR8cz PAXtABb1AB4UUc3UNzfwp4TOOz00Po8MU+ezsaqqupJ0TqWsUAGjV15ooBaGQAg0pUzJOgOVVUPV VeniSxOVTP1qUcUTIQ4VUkOJwIjJRjP1wRyKQy9ruqrRsuKUOW90P3clAbhMaz6nTf+q1AjTCkFX jDud0xGf81q10v8CaT+9VFZxddBq9QDIdFzPEyvOKWdSqzsbSzk9lF3pstK2iQQ17VVlMkBfKNaC K3QI6jG276T+VBQ5js1ezOPCEVtj8FpX03AUEiH7VQZpjUJrgFEblb9qalwd4zsQqj1nq10vFckO DxtNUsqq7roIlezsiHNorjBC5DpCRECQLUu7D0GF7S820V4Ttim7NVkYVkB1ziKPcVzL1beCNmjJ 1JOekVA5FFjn8sh8Dz9X8DYfL2pt9jM5UwIvEyhf1C81kVmX7SEuMyKYbVmnFmsHUyqZMNXcKxS1 tjT1jmyxMNtAM/Lc1ikd0/Bmsmr/B9PuNHML6bYhUZMWXZHZ8I7LGvUAZs1wGbVtydbbRpNrt09n d8bJ3PXSTBDc7C0bB9EkmXMG/fH+OrcvOREmBVIVmc/tvpbWxnZsvXZ1pyP+TPUbp1B08bbi0K+1 ipDmAtby6K8mwTEo1VFhAbJuSZMVlxJ4f5L4tvUVrdJ413FvVzP0zpLSGlXbJrLLDFdik3F5Gzf+ vrJx2S9yA8ZS29VDZ233MhcheVJ2eTcLPXMhs/YgVfP6ICLOVrfS6PcQKELbeKxXYjd9sdAKdXdm kdCCkFcWpbJhhdd3hRdvP7cv41Zh2feAO3MmozAweRYg3XBRC7dwN9hnL/ZwNbIz/6MSeh+Yb+fJ SB1q+JSTcC/zef8xIV/4Ft93dBG4IIGwde2XWfV36vLXV3r4bEWzISHX2NqJgEt4El14gp2yhUGO gTGYdEPTbanWc2eXdk94hrFy/dxw3Kj3EEK4VjtYYtMyMK1wMQFzeQ82ONv0fC0VeB0YCrH1C9nR bGv4jWNYZcENf8d2h/MYfzmnj/2XBpn3F7G0gQ0YeauYgukY/8rYe++YLw0YfhP4Ycm4HdEQiSVy 3Lp42UJ4jOMMhLU3cJnyjf1RiKFxaTexBTOwlAGYe0lZJqFyKdvXeb1WgvdXdVNxMMyMj39Xi0cZ KKOVgavShln5e682fm02K5XXjv+f0pHheIErGXxdOW9/8v3GVdu8+IsPwoNr+Yrt2JgPmOwwdYuU +W1RsTRxETPT+ZKnOJzVue4CSmxNDnWNz0MmU4pLV2q9km1Jk22TcZ/zWZ/3+W5jWDAf+TOJTSFP 2RUj2G/XGXCvOBdZuRi3GXG5+W4fOiDPWZbnECGKNCGUs16lJHzpQln5N1jsCGVRoqRH2qVZ6hqI dlEPT3FrVo1xdiNAukNVeLasoQZ8mmdaWiuyY6X3NI+wZhxfWqm7dKabGpuvV2JnumBlTY3Zdafd tKV82hqAOiG4OlaE2ip2isfaBGXLGlj4NKKXWq1NVHFf9GKnWuVyWqTZdC5ZSqv/D4Krt1qvf3qk 81SwUlYiVLplA6pF11pK7qAG7gCxEduwWaNoiTaqUZhymRart+iu+Vqrt/qnNVuz65WwhQt04oRl BQqlG5tAFNsgFHuxE3u1TZsuQPitDSK2JYicf7W2OXR+8hqzO3u3DcKru/SkxZpFXbaorwatXXs/ GDuxDwK1UZu1kVsr3lq6Z3uxQvpdizOQOnuv9Tqvtfu3b5SseYq4zxp9xntE5gesrfUqFlu5E8K5 nRu6o1u2F2pyd/qjbRvOUi2zN/uuvXqrzey707spHeNkxdqFVpawFyZ9BuuGnW8SrdadFfo5bzHC IVwOhVq1M3y5Mxy+49uwyfdj/42UafP7vw+Bu/Gavy/7Zl305BolKk42OoCpWQV7RYm6hVQzW2VX kIt3ND26mXdciVGiuZ87tRGCvYfcw5faV++broPaxJdNq925xPm2hUc5oPc2E7lMHuBuywW6oDmT j7cOfzOwy8L2fllXh/M5gt0XyF3yhP/Xhnk8/2hNTI6GITSctYecsZu7vZPcpZ2MjX+1Qz8WXkyu xH1b23x6+3g7eY/XzZlYyymty7v8bId35XqZ0nI50zf9+P44/+rWgm85md3cgg9azkc98LyHjRbi vVXbyJH8yIncO3/hF2qg1v18IVL4qtm0tqnTFUvcGgAcs7lsr+vvgiv5Jymd0v9PnYJjEHVR1ya6 lpenvdPNvHV5fMW9mdlbmXi/nNt70pkP4VWWhnLa6A/6nMPfe7nzPLU7nKVo3SBuHd5DxQcOwgfq nWeAtWMF3arDi7xiMMpNPNumnNaC/cn5Os4xk8IJGtxuQssp3TWfGTV9eIcrvswfnoR12NMlPqkn +dt1/M3juGlNENxlzlUqLWnK3c6Zm8PZ3b2JfLXdfYvgndbn3dZtnkLwvQbw/d53/t51/i/iIR4M QuiH/il0usknm0IQLYK2zeB9G6+BmtihnLMTXoYnfPQc/hD2T/8iXf/g+C8/ztq7/NlVd3VVl5d1 GE5M+abZ/NG5HZIdji4fDAX/TRBzf7zLTl7c40yEmObcvUfdNby1Zb3dW+rWEaLWax7nB6Tnf77e f94ggL4uil7oiR4r3HXQAd2chiw2Sr7uDh3hrV6CHR0oJ33Zlh3bzXnrz97iG17T87dr0T5/MV3i Q93jt72ZHXjuYUfbeKjNIUTbVn3l67zIXb7DXZ29DX/eE/8gEv/ww0PneV4hgB7ytaLoD6Lyrz8q lNZXNR95RmyGHJPgn9zg42zKf9tzQU9uC/D0DVLrJ9orJz7aKX72tdzsLb6eu1YvZZmZN7PCAaJG jUMECQocWPCQwIQGDzpEWPBdjXcMBVJMOBFiQ40KOR76U+OPyJAhRwr8c0fk/52Dd1a6fFljZUyZ Amk+vIkzp86dPHsK/FUD6E+HQn0a7enDR42kS5U+ZCowqdOjOOPFq2E1q1aBVo++kyhxItivGama 9YmgRtqHadvWsAb3bVy4c609tPs2r0C8Z/s6lHcQMOAa8goT9tszgcAECQozdtyY8eODkmtUVmwZ M+LNnBd23Bn2a1iLFkWHJs1z5B+DIE+6FtkaJMqRLWM6hNkSt22bnXub/QUceNCgRYX7PqoUavKo yaX2vtrVYVfoZsGWJWv9eF8E3A+uFeiW7l65cfWOt0s3vXafhQ0THuz+8GDEgg8fnqw4f2bJjvcz 9i+ZZusNqNNGOp0mlkMIiv+V3U6yrfbRSbHBJmFKFNpW00w0uZRhbQR+uJNxIgpnHIgOObVcU1I5 1xyKS/k1HVcHXYUVZ9aNZiJaannH3Vo9IoAeXweVJ55DQhaZI06GzfcXk2ctGZiTjsmjGGCN9ReZ ZVpWlmSXPd1I2ljYXacgjg49KCFJsrlGUpqqoXSbhrnxVhtvXh4n4k9A7UlUUR8y1VxULwJ6kIsu ngVdjDVipWh1ZN6p03fgtUVpd3INSR56eSEJaU7tfeqkQPH1BSqU7lGJ32NUohrgYpl1CmtZqIU2 ZkajjWkmmyWtOaGavNoGG211ZvgQhzXZGStiwR0klJ8k5hgooC0OOlWKL1L/FR1XNNKobbbJHueW j5EGmSlf4tWFV3mQtvfee4KNSt+ngYl6an5XWoYqqov9J+C3nd6KWoKlMUhrrrGxeTCawfLamkwb Hrsbh8b6y9mefA4XnMVJBtoUc8tNey2i2jKqFXWLcktxZ5SqFa64QN5EbpFz7UXuuvO9K6p8oZKq E7v9zadZgPqlDCnAAWNnmq1K66Samq+15mtKHpaE4ZzDYhgx1kRTRWJxeW4MlaAqolhtx4OKjS3K Mnq7KGK3vL01eA5xNw9O6tF8F83ppgxlzvbRJx+97sqbc3z57Rx3jgWPZStZsjpOJuQPKhxsm5bv eiFID3s4LOfIJn7UssyK/26iciB3DLJzZ4tMco0xmuz2LQLJLjvF89R9e+64z0OpppzWdel5QnaK +N9+vYtzu4HDF2WrXIKeJOO5Pk7rrKKdCTX2mWf/oNQkWc3STBCPrzX0PXU9Op9+rqc62oWaXahy 72Mr49rSwe5X7QfVrv+dCNRdg9z9L4C36w4A90aeBPpOU+O5jJaSZCr7FM8oN6MX8ph3swxK0Hwg Oo1pEOQ46X2wVgi7UJsOdpDsWUhqKxQfsXKjoThxMHQlYlaXWLSisM0vZGFrn08StS3qBLFRZqFd DfjHv07t7kfdoRvvbrcpvTBweOmyi36u+B8vVfA49WnXqfxWny7+ZYYfAv/Y9W4VQuuBKWBNy94J cyKblbwJJVcj1m5Y8jky3sRi6sPYnVhktmgJ6lCoO4oQt5IoRtVvM0acXSO79D8BSlIgBeRdAKWY QOGZBy5X3JK9tKi8zmDwgl/MIAZDqUftIE1WjXtIdl55xrBMziQSgtrkaklLFjpsTuHDY/k24w6i 1RBsOvTYtIppuqkYhW2KRCQzi/i2aDryiP4jYAEP8sS24G5TVeQmpjY1NIcE7YGpvEnfBKe8+Ixy SRMsJ1UWVKaByRONjBPYTd6UwlmmMCRyvJwLd+nLifklmO4oqECCWQOC3iljGgPb/FaEE2UaM4f0 O5naiOi2I0rTkf3LERT/dbcj3kXSkpL6ppHQ9cAs2kul/SpnKR9SquUFznjuHFCDrneQpDGIlbRC 4RvnSLXMAYs2LwSo+PJIFYQmlKAKVehCL+Yl1bXPUC2SlopW90Mh3s91jITb/rwaKwEOkFK4S8s1 AYip9OzNGpjhkgMF1FJ34oyd6TQVfL5Y086YaZU4FVNOk9agjDDMaQ8xYVBpY0KbSCxiUzuLQZ2K 0IIaVCAHyCtVUne691XLhzCKzrZGRiDa6a+jIBqpaQkYUmyi1Ugn1YtKKeNWfpHTsn4rHPPQ6UXc 0rYvHsTRB5UGOVeGiSwMaxrm0IS5FFpIc56rE/g4o9THOvWgByDoASpb/9nd6qRsT7kqtULGnPCm 7bOue+ZRojlaJM7uTk/c0Uh3R0Cz5s5uJhXn0D7pybjqkZ103aB/51pb7W4GlgIL7l59i5qF0VKo u9IVYT+3oTo6xBsC8QaFdSJZ6WY4ssGs7mRrkF0Bn2hsO5Ef/A4lUbOUzDdgNeJGH5mj/5n1kpSc 7yWhaJZwZjGlD9GvSyUILws2SWftFHFOXkmwnCaonpDzICuphjA3oTBhJlEsDI+axwvXQMsYZqpk HeLhhIJ4zCE2MsdSbFVAno1s4FXxjNTGyPWKdqPVXAtJ5ytf+FKlrftaqdBeZVl2RWmMMzXeFo3M W1yt8TqKBm6CT9grKP8T9kz7LB+dcEJhC2+5wpzm8kGbKmYxb9ig2B0zondorUESqofXSlGKKQa3 WFPTq6Qt7RMrWVZsWnObPuFXOD3J4/3s1mdERiWQ53Vqr9zopkoO2NHCdE+g2rJXc1xY1RzGWN5c ONNbtrCmvX2Qxx50qZ9OaGU7XNDrXtfUpy5bDgGJQ2PuEHS05ih62VvASF5ypPHV3Wp7DVeWukqc tGWSz8JIytwWOdllEqErf3sTJNfKjcf1lS0rjpPG/rLTnO52x7XM4VCH+9PXTfeXKctwjo041Tw8 kcrpLc3+1dpEYw2gE7MJwO/wmidu3RfBWfrrmo5KXni1rbEZzpO+Lnv/cQgWYXALa21aRllXFD8K uL/d7W0/5ORLzTC5u77ucSOdomsu5Nhc3eoZqpfOkIJij3Ds3l0DEO596eTAKaPdhBtd0IJbONKV vOylORzaS4ZncqW+YOQ6+Czf5vamuQxyh0T36582+blBXOZ2X9VQrX61vFM587aj1iEine/c5w5w YP/8VUHPq8EH3fdi0/TvoGmlggBfvTP+1dlSptCCcVn1voCb44/H+tZxEtlwo1vkYyex8wOp2WLS nkD51vVHB/jvf+dEx3ENmt0DvXcg31W30/eJxNNYeOAamGn4TJOkK70Zbmd621eXvKiVv3Wuczjz 7Sbbu13eQyhWfgRi/1aRhH01R3p1J1tCs2MOJGIGN3TLE2QDmHQ4sUqRgyvNBkf5dDkX5xuatmkh eHXzN3IjJ13kxnWYx3/J9jGq1nktx10UCC4+gnpuZ3oftWeXMU74JVtGRjjuEiU/KINJhzQZuDSA t1NPt4EmkXhr8oFZ521a13iexnzR5XVex3y0x2ar1l1oN4TasTs7Z0kfhVba12t9tmMAkoYP+FK3 9YVe8VfrVz1LxmhUwYQMdhzG53g8MVmgJnahlnwfpoVtJi0fg3bS94aIEYbwpWcPYYY7oWP+cRNr KGBbVHSJqGxIeIHDxXRnEXUEMn9U+HEhiIKV13WUl4UD+G6E9BSshv+JKqNaNkZJpLdzCrglPodf SCdGfveKwsVTjAZPOMVBWraHHid/9nd/X8ZUp5h8MqhDLZh2MdiLiohaNiaGs4gYPch6DjiNf5ct cGZ+tXKBfTUrZDR8IriHjteHYiduo5aKFEgo8uZ/nteNVAFSZJiAj5hjKdVzPlaPAoY/4FiBTxd4 zDY95iOFnaZ1kqdhyudlGzaNVOU+/8gZsnhjF+lvvuFruUiRp5YVM7I2AhmOsORXBwk9WEeMpAiC JXh/9ldQ1+AO1yCTMlkDNImJ0NiRYGiNdKdrGqmNOYloQ3QyXCWStScm42iSCNlxB3GON+GH08WM CXUNB2GTQEkgizb/fduUkdlnlV15E0HULSC5SMqWRoC1Wyk5giuJfMn4kjHplsE0k1Mpl17pGyBU Twx3elqJg/pIl//oTENpMvgzYElZUyjpcXx4hWI2k0pFlVXZl4N5lI/zd2WIg49pmYrUTG+GmeZ1 mTXgC5/JkJUXkzAJkzU5lzXZmQNGePI0gFpJY6nZlVoVlq0jmJfpCwJxm56pm8hnUDY5laYpEHLp mLBJhE2ne8SJnEh3SN4ClpzplZ+Zm7gpnQ8xk6ZZncEZnNU5nMkpXOcHcXnlDwIRntwJmx9JMtyC SG/mnBR5m9AJmqDpme15mzT5m6jZmKhJn/hJnhGHYKWhdJYVnv4g/6ACup/gYKDaYaDgsBMJWk5s 81lANJQOwaDsCZ/QuZvxeRDzmZ34WZ8dap/1uZ8NB1hotFMAOp41cKI+kaAKKqETKoMu2hswehMy CjpAlEg1kKDmmZkPQaOvaKEYmptBGp+f6Zv5OZfCmZ8h6ov+yaS2504DiqIHkaJGIaM9On1W6hdY iqMHOkM3yqMH+kxqo6WJaKHy+aO46QvXkJtFaqRUCZynGaJyuHuxVE4BCqV2ahYrehB6+oVjmqdc mhN+2ikyqqPqKZhsI6gU+J7ueRPvGZ8dGpf6uaFxCaJxWpDpF1jr8Q0C8Q2d2htQGqVZCqiJemqk qqKAihOm2iUTWv8y6GmjD1GbqjqA8ommtRqkRHqk2Cmp17md+1mQZmRPx7GpD+Gpm0GgDzGlR6Gn sipizKoTWuqsIMKq90NeYlmtLcqiPfmGPxqduimk0pmmG+oQ9Amip1mpvkqOT5apndGpw+qp7VoD xUoV40mgoCqqCkqjK5qtAgGjgqqv2fqv+7ql/6qsAfulVYqqLsqg+oqtB5uoDNuwfJqq/xoPObqs oxqw++qidfOvfHlq35qht+qev1mVHlquJ6uk8ySZZampB/GumwqzfkGvUnqsfQGxe5qxOKuxqDqx BjuwN/uzQBuoGQuwOcuvCYuxRjuwOkuwC6q0SjujFJuxFWugWUH/tEWroBybszzJcCALrg4BmiT7 pr75pvYJnMnyAwKRtmmrXXuVfrsnrO76rpzKqcM6r6GKojNrsxJ7tFirsw3rtDs7tFjLonzbs4C7 tH37t4v7s4yrsEkrsAfruA+LtFxqtWDauIrbt1A0ofMgsR6rXYsKpLQKtt1apNbJodcZK2urtqxL W3x1l0rIGTEbr8Uqry57FnearHsrsAhbuJUbuAXrt4x7uIDru5qLvMebuMpbvItLqv0KqDTyuCwq vVw6oTDquQbqmkjXnkPKrd56q+dKsm3aq17Ctqz7A677uvEkcdpxuy8Lr7Vrt0dRr+LZGcyrudAb uYg7uBKrv8Fr/7w8e73Ai7z5a71X+6wCfMD7O7gNmy2syqDcMsDgoLVEW2NcK2Lf2r0ZOp0YWrJJ qp0e2inni77py7avG3jUI6x06xDwSru1a6y7+6e9q8AKmgD/m8AMHLT+S8ANHMA0/Ls7O7zOu8BQ K7k/LLwOHB05WsBLm70UvMNAC7qWtcFmWqaMmqZiW7JuWr7mu7ZfXANfnL5tG3FH6BtzK69zG68s 7C/4u7Q3zKWKAa08y7STK8QATMRAXMDTe8QTPMN9TMc5DLjbEsFUC8QVvLn+5poYLGDda6ZAGrK6 Sa4feq7+YsIOAcZjLGIEJrvsuhPuysZtXMPilKCMwaCYMccMjP/DidvER5zHgHzHTezHrEylo0zL PIHDS1y1V6G8E2yRcDfFVOzIFxqyZyqu1imcY7u6mCzGJxzGbXuXAyK3dguzLzy/ohy5EwrH4JAf KyrHYwq9rMzDsSzIfTvE0xvEQyzOSfuleMzHtUzOXPHOyau9iLw7XNqIyabB3Qq+OKHFN4GkaNu6 rXu+zwybcou71Yy7KZOvGZtFFhy4BIvAexzI2OqzUVy5TYvR7GzOGt2zGv28DNvQhNuxilvBAXt6 2Mi9tQq2xOzPSeqmAq3JBX0QY6zJjznNoLzGdHvN32KlECsgRty/GT3O/DvUhiu0HZ2guGPEvmu4 Q+3Kp7qwdIz/znz7xHDns/dYflh8xTvBpsn8LZdc0yVMni5Mu9Ws02S0g8GmekOol47IyEhnpWV4 kbNIhnQ9fVXstT2hnURz0zOttmFs050Jyre70/HrTs5DTs/jj/5iCzVgC4/dG4soi8HcrBW9l3ad fcD8mnndwSJ2wiYMxoHtzJaJ2C0svz09Q23F2N0HOpEt2bHtF7yGejSWz1eK2btW13nJ2SkLKyU8 0zdNnO2q0Ki90+V0XzrYg5RINJEtELC9GTyJ1xds2XnVo7UN128td9Xt270x2H8t2AZN2MR63DBc U37mKs7D3I59E9AN2ZJtFCm93Rk5eph427Y93abX3ZByyaMd/9j7ac3ym1cBd3d8tt6dItvwDdmz Tdv0rdK6bd8Ojo+0+OD73SVi/cyhHaIBLmILyHq32NgI/tyw7dzO7RN3HYuaTd1x3ZrYTZm7bU0W zt/h/d/dTdxG5mu3mF8h7iWxDd8+buJnsb1wjY1hmIj6/Zo7yd0yvh6iXeNMvlutMlt3N+WOneAj vuBBrhO1mI8rXuT1LWB+WoM3doN5CeWrK9qlfebn7X08xo3sneUlfhA/ruA3QdeZbc+VDVLwDD1Y urG6PeF1veaDnrJ/xtpbU+KPDd2KXuc8oZcpfTtLfYMJmMSg4+f43JO0XWNgTuidfpmfxGdUHjcm ruBX3uiZXv/klanqOMaIuJzUDF3Ricvli+jptU6eDLjYPH4nJJ7gP77gO6FneC531jfsER3rPh3r 2HuN8v13LjZNtg7tfvFnPvfa7v3cvz7nW+7ltz3pMb7pUt3nyR7I+u3gp1ZvGhV60c7kqxy0pHyg qMzOT820fJrUQmu0jL7DOotWSz1681XVkh7MfrrK+jvSA8/Rdv7iSHdvz+4QMKbuMj7LG028/y7u VzvOIH3vtgDRTszvSb64T9y0UyzwkJvHGH/REX/Lbxhzz55Ec/bw677AdjzxJN8T9G7zMU/PRfzc CSrZNx/p2rvpWgnwK/rzByryx17yOV/H6xzzbvyF6OXwC3//b+n+8sg5y73cw5Qbz1Otx0vr3BOs 4L48sJvN1EBPywx69Dr8wweK8kuL9U8drSImWg+RXlNPTVXf3SYPy4ir9fzL9Xv/3jy/0ZBbz5o9 d50L8FfN5zXP9iJdxAZr8R3dvNPo7LI2941E9XjfmXqPxDIP7jOPr7aMw5Gv1I5YjU/MuKi/+K4e +hebzpA/0R7dyjIoc3e/P+s1a1+l+UrK+a/s+Yy/9Y3f9aOP9CHv7ZQk6WNf9lD8+cB/wFtKvFEd tXCP9AoP9fbm8rl/+7ufsnz79nxf/RR9x9/v+xF9O/VQDyoNQHy8/mYP/PD8+NFv1JIb94iG+eql UTrxYtwf/6JIffAAAU4guBo1BhIsOLDgQoYNFS58mFCgRIQGJ1JkGDGixIX1DtaoV29eyHkla8zD WPKhyosNXWJ86fIgwpkZW3K0WBHnw40xff4EGlTo0J+3Fho9egupUqYvmTZVSlTqVKpVrV7FmlXr Vq4/P9qceTOsxptexZ6lObbiRrJqQdbLCU5kQbgoF6JcqbDkvIF2farVGZNtWcBp3eakuLZsV8Zd kRaMWmMpZMmQIze83FjzZs6dPX9u3BPiV4djRwf+ixYsWMKqWQ8MCdfjxNhvZZ+kaFIvTLOmgQ5G Hbenb8SJeYNG7pTyZMqVoz6vbHl5curVrV/HLlR0du4NQ/+CpBh7L1y6cxnu9Wuy+3r2nI0+lhz5 /dHo8aXbh99e/37+7En3z+622QQaiSSRxDsJJQX3uks9AB+E0KX3nsrvsQmley7DzCLksEMPpdru Q86+O01AkApEiTzcGEwwQb+se0dEGS2T70L6mnMuKYbmm7FHHyMM8ceuanvIPBLn+s5BkxbELsYa 3okRSieF3G8++eyrL6mmsMSPSi+/BDNMn74jL8WTyBypoCVXxA3GhaB8csopxbRuSwqvhG/D+i7L j04//wQ0QNvII7S8Aw1syC4F26wuSkfhfDLSQK/bEkMb87wyvkon5bRTT7e6rSMSwTvxzPJIXfLF 6xx9U9L/KD91DzrMNOUxz+YyhTVXXXeNqTbvwIut0FLPa7E7VqWcU1Jet1rqzuVqrNE5Dftctlpr /wxWWLqAra1bFtmDVEqGnEzWwwQSKOjc7prFk90ud5w1y2vnpVdIQkcNlcx7gd2P3ILIfTXOciFE d6GCzy2YUhxvZS5HTTGjtl6JJ/ZQRUO3lW3Ut/qFE9JxP/4Q4RoOHjld7Caz8sZMU9ZRT4pfhpm9 jPllKNSaO+o30mPLHRhAdH8uGeGEq2P5KSz5pFFHh2Nmuumhsj31KhWh1nZjq/V71V9kxfWY4JIb OhjoOqGS99Ibc7TRabXXFvVmXy3W6sia8YXb2GQDdlXZ/wfDVlfkoEce+rM7J7QwOuigspVt/vzx p4bGG1d8vZlxxrluorr19WqN+Qs3znE7lpFvwEUnOks7K8TPSpcjv47xghiH/HXWq6sa7qml5lZf E6HuD3SBO+6ZP7GDVnd0g6kjPOn7pmv34dmte9zx2BeK/vnPMsa+UI3JlOrIqYMlVd8Huf63VXOB Lt5kvgNHfuFpbz3beuhfjx3yx2G/f3r546687dytttxP5IYx8G0LQl0rn5BExj71UWplXXrf6Va3 P81Ez3X2k17+HEdBUAkIfNwD4OQC6BKbibBbBhzfo/L2peIJjYGCe5fL+CSrCXKQK/jLn/1gRz/X bTBucv8boZ+eUZAh1qCITzMgECenuc0FhXvaQyGHfOcvEQWub+gj3noqlTILoc6Gn9kh9fQnRh/+ kFS2+VQRh/iMNQoFe7+6WtTwVRXvceuMMhJXFVuIPr+l72SGk5bqcCSrL4KmhxvEn+xkd8ExOjFq F4uiENfIRoZQckwo/CDV6hi+qeTLdoUMys9c+DVS/o09F9KQykDpGQzWD5EZFCMOGzmm3aHxjG8M kxoneUQj0hKTnIRkJIMIFMytUipYFFq6FqjFQHJRWvIyplYOqcHqYZB6LjlkJ+VYt8xRqY2WnGQv aWkzAj5yX78aZjS5ckXAqQ+L7Slc4WgVMXVmZZoXlN7/IhnZkDAK0ESi0h2/uumjcFKSjUcEJwnj SMBMnkp36aznOpWZML+ZrEoVwlVEb8jDaV6Tnzy85iwp97b+ldBQEH3QLhOqRiPyknI0GxQIR/pB jVZHlCQrJX8ICc2aSlOR1cQhQ3K4Q5F6x4O3ux3GIknQXhrUpeIk4RLROFBbtg2lPbWKH3GKVWtV T6hf7Wg+7ynSJkb1nPla6oe+SUQiHtSgCrUYEB3KzaOu0hcLuatNDeZHrurKgmLNYCvFGlSvCnBj 55zbEhEro4O21JJtDSdUK5ctcg7QocC0oS/umtcaaFavx+srr0RKVEQmkp/ZLOPNDltLAKqWnD1i qWOh/6pLuGoyipjDZQEpqNm8enaznQ0tV/v51Y9Wk6OvvOT3vmfURyqVoJF9rFsb+9LshQ+tMwNh 1eTn298WhLfB7Sk+6cdRRnrVmvqEY1wTK746evBHsW1qS9sq2cTOFIq3vddV1dZbznoWuOCNaA91 +NNWWrCRw2WoXCGJXcy+Vq2NjS4Sscu7QU31sBzk7n/xytvvAjiaAxYwYEtLxjBqML2rTWpMrSvQ O3ootgWNL32fCMfmWhigu33Jb/vLWQ+vkqgFDiss9Vfi1LZYoBTWXgHRKiKEtnEhKn0JSbm54tv6 b7f+BW6GsdxjULryvANG7j7LiNqA5td7MjWqbplM2/+3ytewJ1xthTn5z+1mmcfe7W6HufzFjqJW qPikJpiZW9ISVte5wtJvexA6WwhHGbcXe9scD73dPHN3sxzW8J75/MochjSfnx4xcgFa5iTe15xp ffCTn/xUhcZRt2WddJ2zPGstd/bOmt4foD9t4kAXebzrZaJS1YtbOr93tmz1p5ntWM6oGpl1HNZz bzV8a1zLz8s+JKwsQbpr/VE2mG5jL9Wq+lxWu/GNJG3tQBNNMUvb2s6XrrYxxyrm+vn5o8yFM83c C0ykOttT27PshePqYFlH+91bjjcF/wrqfWpb12Oc8WTTXdIbr5tO2duXcq1cSCzz192+TXhQ3FGQ kTP/7Ronr8E1/HHy+3k0qPdObsatWmh9S3pZZ34izl/KcWm75LvUDnkN3FFykg89Zjs8+TVSDtYw E9neqj20TDeJTotjq710WzYoe25rHnc36A0ZudGFvhCizwvlLE/6Qlj+ksIKmawz3xwUlT11a6EZ roP+4qX9C3Lvfj0mQy952MdOr7QrXekrF6vKlY7twILa1/Wd6sBVLPmXsfas47YrwjPtd7C/BPBl X9bZUZ7y+x0e5eXdduPdKGcpz7nfVZ9UuCMNe8X1l/NAEXvYAw96ayXd90sv/OEV6XaPOjKAdXUu ZmG2vdZy1eu3/zvJhf75ei1e9EsnvcpXznJBq/5y/+5NMt0v3DSCQz/kYp++7nn/qbRjP+W/J73L f8z4TrI36661ufn1zzTBp3/w12o/63O/xjE8tIuJovIlOmMwfdu/BoQZeqCHGoBAwJO+CrTAXDG8 9xs9lzC87TPAREJAYhK4/rEluqE9B0RBH4lACJRACYxAd6AHCkS//9uVAlS7ggg+AfS9lXu6rKAs 3tGWE0zBnvqGGihCI0RCWGHBCGyIFYRBJjS69dOV0RNAHLTC9wO+xeuMV5MyuxtCXPuGI0TCMDRC MZyUFYTANHTBhYjBoWvDotsPb6gBOQSNDMRCHcRBLVQ7PWyMJasrqfrCeCvCMBTDIyTDM2TBl0hE KP+MQgpsD2+gQzosCElsDDsMwJjQww3cDEDUOH8LxB4jQ0JkCEMsCFIMEzQsiDRcxDV0wheUQu6A xIWgxEq0wSssPODDPk30jIdSsE+sNkIcxDI0xVIUxVNcxURcwxZkQyZMxu6AxGecw0mUxFnMCuuj wvbLQvfDRak4gILoxvpjNl9MOFE8xEEMxlE8xFNkRWRkxlR0wSVUQ1icRjmExlikxmq0wrPTQC28 RQ2sigP4xm8UR3EMRmAsxYMcw4YwQxVkwnhUxndEQ1RcwYe8jkikR1mcw4tkjA3MQI7kx2scCoAE yBoYyW4sSYEcyC80R4MMxYQ8x4VUwVScSJlExib/ZIiZrMiMnMRopMRYpMU7vENN5ENd/ImS9EaT JMmkTMlPTEdhNMSXJMcfich4dEhWhMiHrEnqeEZ6hEae1Ml7tAob9L3r08FLLMqRPMqFMMm1XErF qUKiBI1CTEKWHENStEuGtMlVVEacnElmbMfkmMfAZAiwrEZ+zMeP1EdtjAmRREuGYEuRbMuYyUEq VMzPOMcyXIhQtEvNJEaY9JBF9EtVxEqJnEpntMiejMbU7IoqzMUC7Ec+dAmkNErIJEm2rM3InJiy 1MaxpI5yNMOXxMyCbEqpbMGGXMJ3LE7kpEjs2MqtlEbnVE2u0MVMtEaGgE2fEMiArE3GvE3czE0O /9zHyrRMzMxMczxI4AxOqTzO4pRId5xINYTH5QSN08RIlyDMq8jEPcTD6wMKtNROxmzMtURJ76xB XAxAxBRPzbjMuizHuazL8hxODkFF+cTJZmxI5MxK64DOSNzJzsBG8EzMolRLpWyI7ATQASVQWHHN beRA0WNNBf1NB33KlSTGGu0R0VRFqsxRNlxGHmXO5lRNDr3PwgTKhrDD/iRRAE1SAfXPFJ1CyrRE w8zHPOSM33zKzERHhTTPGdFLRaTJddxRmdSq+YzODtVIz+hI93tRoWjSJnXMxiRRJ2W/yVxRaxzL 66zSgkxIBxXGGvVMCDHOHr3K9/SJiewbZQJMnv8UUp/8jN/LT6LIztukzRNVShSVU07xyDRVU1uk 0s6QS828TGAsxj6VEYf0y5g41ZuMwASAQBfiq8/gSkUt0zoMT25EUdpMykm1zUv1lFvcz2s0zDXl ipUM1fNsyQZd0A/py9Lcy+OsSfhc1WSqyIvsyh9BSe68VknlVfbj1Bs0UuukTjzNCnJsSZecUXOl kglVVVOFzzUUGibso5yazyGNEMhESm2NU0mF022lE3EN0VrExhX11KhE1vI02D/tkFONz6yMyJsc GXi9qXdiHXvdTses2HvlV0y1xCwMV94U2MbgTCxFx3NNQvLES+XEUIe1yVQ81BeKnHsNSNsU0Fz7 tdSM/RLYBNZgPcw8/NBhHdVhdEqEjdCY/Ev3XEZ4pIdzSVpEXSb5yVY4jVmb7ZSAvUSyDMrdBNkH HUUbJdbgHFpldVikdcfkfM+kHR7jsaiJ7U5vzFV9NUqp7VdxDcoj3UaczVpRbVAGLddkvVGj9dH1 XFgXFKVSqqjZ+c+Ync1IhVsx+Uhw1U8DBUm6hVEa3cySvUvirEpnndDNTcT0IZlXfdlJHdElrdnF FRIpfVzHVdNgldurmFFTpMvO5NtSbdYMDdTQXEJkQlvriVQmVUvFNV1AScxH5dkrxMIEvVuXREhR BRPQHFSkDc2XiFeXVRwlZdvZzNfqCAgAOw== ------=_NextPart_000_0009_01C71EAB.933D7DB0-- From ipfix-bounces@ietf.org Wed Dec 13 05:44:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuRas-0001FO-PR; Wed, 13 Dec 2006 05:44:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuRar-0001FD-La for ipfix@ietf.org; Wed, 13 Dec 2006 05:44:09 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuRap-0008Nn-9H for ipfix@ietf.org; Wed, 13 Dec 2006 05:44:09 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Dec 2006 11:44:07 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBDAi6Xv015438; Wed, 13 Dec 2006 11:44:06 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBDAi6AJ008705; Wed, 13 Dec 2006 11:44:06 +0100 (MET) Received: from [10.61.81.22] (ams3-vpn-dhcp4375.cisco.com [10.61.81.22]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA21259; Wed, 13 Dec 2006 10:44:05 GMT Message-ID: <457FD957.9040102@cisco.com> Date: Wed, 13 Dec 2006 10:43:35 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: "Bhuvaneswari R P - TLS ,Chennai" Subject: Re: [IPFIX] Sending export packet References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1421; t=1166006646; x=1166870646; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20Sending=20export=20packet |Sender:=20; bh=Hsr5754Cb13bmMoiM871r1qLnpZBFn0TQpwOJ8so0oo=; b=H499XZ2lvA2G0ArjGXi+4Ylz5Sg0sxcaW3mBYi7shbBhvsVjsXw3fdDoX7tgJiseLyIbrvLY /1n0P7YfohQ8WcfjIJKGIiMwaaF1ES5r7hXUF1bLK51xJfDwI+SUI2xV; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Bhuvaneswari, > Need clarification in below quote from RFC 3954: > > > > “Two approaches are taken to make sure > > that Templates get refreshed at the Collector: > > * Every N number of Export Packets. > > * On a time basis, so every N number of minutes. ” > > > > Any specific reason for having two approaches to send export packet? This is only needed when you're exporting over an unreliable transport. You need to refresh the template regularly, else it will time out on the collector and be expired. Thus the requirement for time based refresh. However, it's possible that the template was lost in transmission or the collector was configured with a shorter timeout than the exporter. So exporting the template every N packets gives you greater assurance that your data isn't simply being discarded by the collector because it doesn't have the necessary template. This is especially important as your export rate grows. N represents the number of export packets that you care to have discarded for this reason - though there's no guarantee, because the N'th packet carrying the template could be lost itself. The worst case would be to send the template in every message - but that's terribly inefficient;at that point you would be better to consider a reliable export transport. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Dec 13 05:44:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuRas-0001FO-PR; Wed, 13 Dec 2006 05:44:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuRar-0001FD-La for ipfix@ietf.org; Wed, 13 Dec 2006 05:44:09 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuRap-0008Nn-9H for ipfix@ietf.org; Wed, 13 Dec 2006 05:44:09 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Dec 2006 11:44:07 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBDAi6Xv015438; Wed, 13 Dec 2006 11:44:06 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBDAi6AJ008705; Wed, 13 Dec 2006 11:44:06 +0100 (MET) Received: from [10.61.81.22] (ams3-vpn-dhcp4375.cisco.com [10.61.81.22]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA21259; Wed, 13 Dec 2006 10:44:05 GMT Message-ID: <457FD957.9040102@cisco.com> Date: Wed, 13 Dec 2006 10:43:35 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: "Bhuvaneswari R P - TLS ,Chennai" Subject: Re: [IPFIX] Sending export packet References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1421; t=1166006646; x=1166870646; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20Sending=20export=20packet |Sender:=20; bh=Hsr5754Cb13bmMoiM871r1qLnpZBFn0TQpwOJ8so0oo=; b=H499XZ2lvA2G0ArjGXi+4Ylz5Sg0sxcaW3mBYi7shbBhvsVjsXw3fdDoX7tgJiseLyIbrvLY /1n0P7YfohQ8WcfjIJKGIiMwaaF1ES5r7hXUF1bLK51xJfDwI+SUI2xV; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Bhuvaneswari, > Need clarification in below quote from RFC 3954: > > > > “Two approaches are taken to make sure > > that Templates get refreshed at the Collector: > > * Every N number of Export Packets. > > * On a time basis, so every N number of minutes. ” > > > > Any specific reason for having two approaches to send export packet? This is only needed when you're exporting over an unreliable transport. You need to refresh the template regularly, else it will time out on the collector and be expired. Thus the requirement for time based refresh. However, it's possible that the template was lost in transmission or the collector was configured with a shorter timeout than the exporter. So exporting the template every N packets gives you greater assurance that your data isn't simply being discarded by the collector because it doesn't have the necessary template. This is especially important as your export rate grows. N represents the number of export packets that you care to have discarded for this reason - though there's no guarantee, because the N'th packet carrying the template could be lost itself. The worst case would be to send the template in every message - but that's terribly inefficient;at that point you would be better to consider a reliable export transport. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Dec 13 20:14:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GufA5-00010T-MC; Wed, 13 Dec 2006 20:13:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GufA4-00010O-7G for ipfix@ietf.org; Wed, 13 Dec 2006 20:13:24 -0500 Received: from groucho.itss.auckland.ac.nz ([130.216.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GufA2-0003wS-Jx for ipfix@ietf.org; Wed, 13 Dec 2006 20:13:24 -0500 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 8F26735066 for ; Thu, 14 Dec 2006 14:13:17 +1300 (NZDT) Received: from groucho.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06664-14 for ; Thu, 14 Dec 2006 14:13:17 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 70DE034EE1 for ; Thu, 14 Dec 2006 14:13:17 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (localhost.localdomain [127.0.0.1]) by motoko.itss.auckland.ac.nz (8.12.11.20060308/8.12.11) with ESMTP id kBE1DG4v011111 for ; Thu, 14 Dec 2006 14:13:16 +1300 Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.12.11.20060308/8.12.11/Submit) id kBE1DFFd011109 for ipfix@ietf.org; Thu, 14 Dec 2006 14:13:15 +1300 X-Authentication-Warning: motoko.itss.auckland.ac.nz: apache set sender to nevil@auckland.ac.nz using -f Received: from dyn45.caida.org (dyn45.caida.org [192.172.226.45]) by webmail.auckland.ac.nz (Horde MIME library) with HTTP; Thu, 14 Dec 2006 14:13:15 +1300 Message-ID: <20061214141315.ntakjv7gzj4kgs4w@webmail.auckland.ac.nz> Date: Thu, 14 Dec 2006 14:13:15 +1300 From: Nevil Brownlee To: ipfix@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [IPFIX] Shutdown of *OLD* IPFIX mailing list X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi all: Several people have reported getting lots of spam via the old IPFIX list; the new list (i.e. this one) is working well, so I'd like to shut down the old one. When that happens (in a few days), the other IPFIX aliases that it provided, e.g. ipfix-protocol@net.doit.wisc.edu, will no longer be supported, so people who used them, i.e. editors of the AS, Architecture, Protocol and Info Model drafts may need to cc emails to their fellow editors. If anyone has problems with this change, please email me. Cheers, Nevil (IPFIX co-chair) ----------------------------------------------------------------------- Nevil Brownlee Computer Scien it ce Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland, New Zealand ----------------------------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Dec 13 20:14:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GufA5-00010T-MC; Wed, 13 Dec 2006 20:13:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GufA4-00010O-7G for ipfix@ietf.org; Wed, 13 Dec 2006 20:13:24 -0500 Received: from groucho.itss.auckland.ac.nz ([130.216.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GufA2-0003wS-Jx for ipfix@ietf.org; Wed, 13 Dec 2006 20:13:24 -0500 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 8F26735066 for ; Thu, 14 Dec 2006 14:13:17 +1300 (NZDT) Received: from groucho.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06664-14 for ; Thu, 14 Dec 2006 14:13:17 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 70DE034EE1 for ; Thu, 14 Dec 2006 14:13:17 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (localhost.localdomain [127.0.0.1]) by motoko.itss.auckland.ac.nz (8.12.11.20060308/8.12.11) with ESMTP id kBE1DG4v011111 for ; Thu, 14 Dec 2006 14:13:16 +1300 Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.12.11.20060308/8.12.11/Submit) id kBE1DFFd011109 for ipfix@ietf.org; Thu, 14 Dec 2006 14:13:15 +1300 X-Authentication-Warning: motoko.itss.auckland.ac.nz: apache set sender to nevil@auckland.ac.nz using -f Received: from dyn45.caida.org (dyn45.caida.org [192.172.226.45]) by webmail.auckland.ac.nz (Horde MIME library) with HTTP; Thu, 14 Dec 2006 14:13:15 +1300 Message-ID: <20061214141315.ntakjv7gzj4kgs4w@webmail.auckland.ac.nz> Date: Thu, 14 Dec 2006 14:13:15 +1300 From: Nevil Brownlee To: ipfix@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [IPFIX] Shutdown of *OLD* IPFIX mailing list X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi all: Several people have reported getting lots of spam via the old IPFIX list; the new list (i.e. this one) is working well, so I'd like to shut down the old one. When that happens (in a few days), the other IPFIX aliases that it provided, e.g. ipfix-protocol@net.doit.wisc.edu, will no longer be supported, so people who used them, i.e. editors of the AS, Architecture, Protocol and Info Model drafts may need to cc emails to their fellow editors. If anyone has problems with this change, please email me. Cheers, Nevil (IPFIX co-chair) ----------------------------------------------------------------------- Nevil Brownlee Computer Scien it ce Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland, New Zealand ----------------------------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Dec 13 23:25:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gui84-00035K-AQ; Wed, 13 Dec 2006 23:23:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gui82-00035E-R8 for ipfix@ietf.org; Wed, 13 Dec 2006 23:23:30 -0500 Received: from gws03.hcl.in ([203.105.186.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gui81-0006bb-0B for ipfix@ietf.org; Wed, 13 Dec 2006 23:23:30 -0500 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 98F6F37C015; Thu, 14 Dec 2006 09:53:25 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws03.hcl.in (Postfix) with ESMTPid 8353937C019; Thu, 14 Dec 2006 09:53:25 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.14]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 09:53:25 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Sending export packet Date: Thu, 14 Dec 2006 09:53:24 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Sending export packet Thread-Index: Acceo54gC7iF6JklTI+lcaNlwGypigAk9i4w From: "Bhuvaneswari R P - TLS ,Chennai" To: "Paul Aitken" X-OriginalArrivalTime: 14 Dec 2006 04:23:25.0323 (UTC) FILETIME=[98F565B0:01C71F37] X-imss-version: 2.045 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-8.6277 TC:1F TRN:53 TV:3.6.1039(14872.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org My question was why don't we go ahead with just one approach. Time based or packet based ? why do we need to implement both approaches. -----Original Message----- From: Paul Aitken [mailto:paitken@cisco.com]=20 Sent: Wednesday, December 13, 2006 4:14 PM To: Bhuvaneswari R P - TLS ,Chennai Cc: ipfix@ietf.org Subject: Re: [IPFIX] Sending export packet Bhuvaneswari, > Need clarification in below quote from RFC 3954: >=20 > =20 >=20 > "Two approaches are taken to make sure >=20 > that Templates get refreshed at the Collector: >=20 > * Every N number of Export Packets. >=20 > * On a time basis, so every N number of minutes. " >=20 > =20 >=20 > Any specific reason for having two approaches to send export packet? This is only needed when you're exporting over an unreliable transport. You need to refresh the template regularly, else it will time out on the collector and be expired. Thus the requirement for time based refresh. However, it's possible that the template was lost in transmission or the collector was configured with a shorter timeout than the exporter. So exporting the template every N packets gives you greater assurance=20 that your data isn't simply being discarded by the collector because it=20 doesn't have the necessary template. This is especially important as=20 your export rate grows. N represents the number of export packets that you care to have=20 discarded for this reason - though there's no guarantee, because the=20 N'th packet carrying the template could be lost itself. The worst case would be to send the template in every message - but=20 that's terribly inefficient;at that point you would be better to=20 consider a reliable export transport. --=20 Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender= immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Dec 13 23:25:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gui84-00035K-AQ; Wed, 13 Dec 2006 23:23:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gui82-00035E-R8 for ipfix@ietf.org; Wed, 13 Dec 2006 23:23:30 -0500 Received: from gws03.hcl.in ([203.105.186.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gui81-0006bb-0B for ipfix@ietf.org; Wed, 13 Dec 2006 23:23:30 -0500 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 98F6F37C015; Thu, 14 Dec 2006 09:53:25 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws03.hcl.in (Postfix) with ESMTPid 8353937C019; Thu, 14 Dec 2006 09:53:25 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.14]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 09:53:25 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Sending export packet Date: Thu, 14 Dec 2006 09:53:24 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Sending export packet Thread-Index: Acceo54gC7iF6JklTI+lcaNlwGypigAk9i4w From: "Bhuvaneswari R P - TLS ,Chennai" To: "Paul Aitken" X-OriginalArrivalTime: 14 Dec 2006 04:23:25.0323 (UTC) FILETIME=[98F565B0:01C71F37] X-imss-version: 2.045 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-8.6277 TC:1F TRN:53 TV:3.6.1039(14872.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org My question was why don't we go ahead with just one approach. Time based or packet based ? why do we need to implement both approaches. -----Original Message----- From: Paul Aitken [mailto:paitken@cisco.com]=20 Sent: Wednesday, December 13, 2006 4:14 PM To: Bhuvaneswari R P - TLS ,Chennai Cc: ipfix@ietf.org Subject: Re: [IPFIX] Sending export packet Bhuvaneswari, > Need clarification in below quote from RFC 3954: >=20 > =20 >=20 > "Two approaches are taken to make sure >=20 > that Templates get refreshed at the Collector: >=20 > * Every N number of Export Packets. >=20 > * On a time basis, so every N number of minutes. " >=20 > =20 >=20 > Any specific reason for having two approaches to send export packet? This is only needed when you're exporting over an unreliable transport. You need to refresh the template regularly, else it will time out on the collector and be expired. Thus the requirement for time based refresh. However, it's possible that the template was lost in transmission or the collector was configured with a shorter timeout than the exporter. So exporting the template every N packets gives you greater assurance=20 that your data isn't simply being discarded by the collector because it=20 doesn't have the necessary template. This is especially important as=20 your export rate grows. N represents the number of export packets that you care to have=20 discarded for this reason - though there's no guarantee, because the=20 N'th packet carrying the template could be lost itself. The worst case would be to send the template in every message - but=20 that's terribly inefficient;at that point you would be better to=20 consider a reliable export transport. --=20 Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender= immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 14 03:20:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gulof-0007e8-E4; Thu, 14 Dec 2006 03:19:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guloe-0007e3-ER for ipfix@ietf.org; Thu, 14 Dec 2006 03:19:44 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guloc-0004nw-R5 for ipfix@ietf.org; Thu, 14 Dec 2006 03:19:44 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 0900B2004BF8; Thu, 14 Dec 2006 09:20:15 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cRjjZQxdPwc; Thu, 14 Dec 2006 09:20:14 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id DA87D2000296; Thu, 14 Dec 2006 09:20:14 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [IPFIX] Sending export packet Date: Thu, 14 Dec 2006 09:19:39 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD6968C805C@mx1.office> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Sending export packet Thread-Index: Acceo54gC7iF6JklTI+lcaNlwGypigAk9i4wAAgf6RA= From: "Thomas Dietz" To: "Bhuvaneswari R P - TLS ,Chennai" , "Paul Aitken" X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1060215968==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1060215968== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000E_01C71F60.FB097150" This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C71F60.FB097150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bhuvaneswari, As an exporter you just need to implement one of the two approaches. We have those two approaches because it may be convenient for one expoter to do it time based an for the other one to do it based on the number of packets. If you have a rather low volume of flows to export the packet approach is better. But if you export a high number of flows the time based approach may be more feasable. As a generic collector you must be prepared for both. (If you just build a special collector knowing to receive only flows with one approach you just need to implement that.) Best Regards, Thomas -- Thomas Dietz Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany > -----Original Message----- > From: Bhuvaneswari R P - TLS ,Chennai [mailto:Bhuvaneswarirp@hcl.in] > Sent: Thursday, December 14, 2006 5:23 AM > To: Paul Aitken > Cc: ipfix@ietf.org > Subject: RE: [IPFIX] Sending export packet > > > My question was why don't we go ahead with just one approach. > Time based > or packet based ? why do we need to implement both approaches. > > -----Original Message----- > From: Paul Aitken [mailto:paitken@cisco.com] > Sent: Wednesday, December 13, 2006 4:14 PM > To: Bhuvaneswari R P - TLS ,Chennai > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] Sending export packet > > Bhuvaneswari, > > > Need clarification in below quote from RFC 3954: > > > > > > > > "Two approaches are taken to make sure > > > > that Templates get refreshed at the Collector: > > > > * Every N number of Export Packets. > > > > * On a time basis, so every N number of minutes. " > > > > > > > > Any specific reason for having two approaches to send export packet? > > This is only needed when you're exporting over an unreliable > transport. > > You need to refresh the template regularly, else it will time > out on the > > collector and be expired. Thus the requirement for time based refresh. > > However, it's possible that the template was lost in > transmission or the > > collector was configured with a shorter timeout than the exporter. > > So exporting the template every N packets gives you greater assurance > that your data isn't simply being discarded by the collector > because it > doesn't have the necessary template. This is especially important as > your export rate grows. > > N represents the number of export packets that you care to have > discarded for this reason - though there's no guarantee, because the > N'th packet carrying the template could be lost itself. > > The worst case would be to send the template in every message - but > that's terribly inefficient;at that point you would be better to > consider a reliable export transport. > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > > DISCLAIMER: > -------------------------------------------------------------- > --------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are > confidential and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or > its affiliates. Any views or opinions presented in > this email are solely those of the author and may not > necessarily reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author > of this e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the > sender immediately. Before opening any mail and > attachments please check them for viruses and defect. > > -------------------------------------------------------------- > --------------------------------------------------------- > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix > ------=_NextPart_000_000E_01C71F60.FB097150 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3 MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4 vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/ jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u 9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMjE0MDgx OTM5WjAjBgkqhkiG9w0BCQQxFgQUXGT9446LYHFRAS4viSRorniteOMwZwYJKoZIhvcNAQkPMVow WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBAEv8MM/sxXm2p7TPfkcPAfcG KXgaAmaCy8S8iJFPLfuOzC/24LUAIhFl2CTO7M/6y174kv7xKSh+Gp/ryUTrv12paD5TwJXmtCag 8ThikT4TtThiVsAwfKywyo2rMNoOX89atGKjTsqS0+jLZ67b8+ZdE5rg6J2GGCuP7SWOkZFh9o9q nMIVtuty5SSNJJqXWx5x9wuz3DV5a4tcT6fZDhfEIcyYFstlx+dHCIiLztA6YNHoFuXJxbMBTqld PxLwhWby/6+2Ry4R1U0vbyJk8YB5UBvIFzbchiGEAJai7eZlC6oxwguy8OaU9purU2RUk9OUEtlQ PgT1W1stx9sxftAAAAAAAAA= ------=_NextPart_000_000E_01C71F60.FB097150-- --===============1060215968== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1060215968==-- From ipfix-bounces@ietf.org Thu Dec 14 03:20:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gulof-0007e8-E4; Thu, 14 Dec 2006 03:19:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guloe-0007e3-ER for ipfix@ietf.org; Thu, 14 Dec 2006 03:19:44 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guloc-0004nw-R5 for ipfix@ietf.org; Thu, 14 Dec 2006 03:19:44 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 0900B2004BF8; Thu, 14 Dec 2006 09:20:15 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cRjjZQxdPwc; Thu, 14 Dec 2006 09:20:14 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id DA87D2000296; Thu, 14 Dec 2006 09:20:14 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [IPFIX] Sending export packet Date: Thu, 14 Dec 2006 09:19:39 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD6968C805C@mx1.office> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Sending export packet Thread-Index: Acceo54gC7iF6JklTI+lcaNlwGypigAk9i4wAAgf6RA= From: "Thomas Dietz" To: "Bhuvaneswari R P - TLS ,Chennai" , "Paul Aitken" X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1060215968==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1060215968== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000E_01C71F60.FB097150" This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C71F60.FB097150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bhuvaneswari, As an exporter you just need to implement one of the two approaches. We have those two approaches because it may be convenient for one expoter to do it time based an for the other one to do it based on the number of packets. If you have a rather low volume of flows to export the packet approach is better. But if you export a high number of flows the time based approach may be more feasable. As a generic collector you must be prepared for both. (If you just build a special collector knowing to receive only flows with one approach you just need to implement that.) Best Regards, Thomas -- Thomas Dietz Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany > -----Original Message----- > From: Bhuvaneswari R P - TLS ,Chennai [mailto:Bhuvaneswarirp@hcl.in] > Sent: Thursday, December 14, 2006 5:23 AM > To: Paul Aitken > Cc: ipfix@ietf.org > Subject: RE: [IPFIX] Sending export packet > > > My question was why don't we go ahead with just one approach. > Time based > or packet based ? why do we need to implement both approaches. > > -----Original Message----- > From: Paul Aitken [mailto:paitken@cisco.com] > Sent: Wednesday, December 13, 2006 4:14 PM > To: Bhuvaneswari R P - TLS ,Chennai > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] Sending export packet > > Bhuvaneswari, > > > Need clarification in below quote from RFC 3954: > > > > > > > > "Two approaches are taken to make sure > > > > that Templates get refreshed at the Collector: > > > > * Every N number of Export Packets. > > > > * On a time basis, so every N number of minutes. " > > > > > > > > Any specific reason for having two approaches to send export packet? > > This is only needed when you're exporting over an unreliable > transport. > > You need to refresh the template regularly, else it will time > out on the > > collector and be expired. Thus the requirement for time based refresh. > > However, it's possible that the template was lost in > transmission or the > > collector was configured with a shorter timeout than the exporter. > > So exporting the template every N packets gives you greater assurance > that your data isn't simply being discarded by the collector > because it > doesn't have the necessary template. This is especially important as > your export rate grows. > > N represents the number of export packets that you care to have > discarded for this reason - though there's no guarantee, because the > N'th packet carrying the template could be lost itself. > > The worst case would be to send the template in every message - but > that's terribly inefficient;at that point you would be better to > consider a reliable export transport. > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > > DISCLAIMER: > -------------------------------------------------------------- > --------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are > confidential and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or > its affiliates. Any views or opinions presented in > this email are solely those of the author and may not > necessarily reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author > of this e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the > sender immediately. Before opening any mail and > attachments please check them for viruses and defect. > > -------------------------------------------------------------- > --------------------------------------------------------- > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix > ------=_NextPart_000_000E_01C71F60.FB097150 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3 MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4 vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/ jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u 9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMjE0MDgx OTM5WjAjBgkqhkiG9w0BCQQxFgQUXGT9446LYHFRAS4viSRorniteOMwZwYJKoZIhvcNAQkPMVow WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBAEv8MM/sxXm2p7TPfkcPAfcG KXgaAmaCy8S8iJFPLfuOzC/24LUAIhFl2CTO7M/6y174kv7xKSh+Gp/ryUTrv12paD5TwJXmtCag 8ThikT4TtThiVsAwfKywyo2rMNoOX89atGKjTsqS0+jLZ67b8+ZdE5rg6J2GGCuP7SWOkZFh9o9q nMIVtuty5SSNJJqXWx5x9wuz3DV5a4tcT6fZDhfEIcyYFstlx+dHCIiLztA6YNHoFuXJxbMBTqld PxLwhWby/6+2Ry4R1U0vbyJk8YB5UBvIFzbchiGEAJai7eZlC6oxwguy8OaU9purU2RUk9OUEtlQ PgT1W1stx9sxftAAAAAAAAA= ------=_NextPart_000_000E_01C71F60.FB097150-- --===============1060215968== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============1060215968==-- From ipfix-bounces@ietf.org Thu Dec 14 03:30:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gulz6-0004kA-Pi; Thu, 14 Dec 2006 03:30:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gulz5-0004hY-Ek for ipfix@ietf.org; Thu, 14 Dec 2006 03:30:31 -0500 Received: from gws04.hcl.in ([203.105.186.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gulz2-00064Y-Hy for ipfix@ietf.org; Thu, 14 Dec 2006 03:30:31 -0500 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 01D05360026; Thu, 14 Dec 2006 14:00:25 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws04.hcl.in (Postfix) with ESMTPid D4D8B36001E; Thu, 14 Dec 2006 14:00:24 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.14]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 14:00:24 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Sending export packet Date: Thu, 14 Dec 2006 13:56:42 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Sending export packet Thread-Index: Acceo54gC7iF6JklTI+lcaNlwGypigAk9i4wAAgf6RAAAEpzEA== From: "Bhuvaneswari R P - TLS ,Chennai" To: "Thomas Dietz" , "Paul Aitken" X-OriginalArrivalTime: 14 Dec 2006 08:30:24.0781 (UTC) FILETIME=[1A0B3BD0:01C71F5A] X-imss-version: 2.045 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-25.7756 TC:02 TRN:93 TV:3.6.1039(14872.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Thanks Thomas. I got confused by the below statement in the RFC. "Both options MUST be configurable by the user on the Exporter" I assumed we need to implement both approaches. OK. Now I understand that I can implement one of the approaches for that approach, the packet/time should be configurable. Hope my understanding I right. Regards, Bhuvana. -----Original Message----- From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de]=20 Sent: Thursday, December 14, 2006 1:50 PM To: Bhuvaneswari R P - TLS ,Chennai; Paul Aitken Cc: ipfix@ietf.org Subject: RE: [IPFIX] Sending export packet Bhuvaneswari, As an exporter you just need to implement one of the two approaches. We have those two approaches because it may be convenient for one expoter to do it time based an for the other one to do it based on the number of packets. If you have a rather low volume of flows to export the packet approach is better. But if you export a high number of flows the time based approach may be more feasable. As a generic collector you must be prepared for both. (If you just build a special collector knowing to receive only flows with one approach you just need to implement that.) Best Regards, Thomas --=20 Thomas Dietz Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany > -----Original Message----- > From: Bhuvaneswari R P - TLS ,Chennai [mailto:Bhuvaneswarirp@hcl.in]=20 > Sent: Thursday, December 14, 2006 5:23 AM > To: Paul Aitken > Cc: ipfix@ietf.org > Subject: RE: [IPFIX] Sending export packet >=20 >=20 > My question was why don't we go ahead with just one approach.=20 > Time based > or packet based ? why do we need to implement both approaches. >=20 > -----Original Message----- > From: Paul Aitken [mailto:paitken@cisco.com]=20 > Sent: Wednesday, December 13, 2006 4:14 PM > To: Bhuvaneswari R P - TLS ,Chennai > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] Sending export packet >=20 > Bhuvaneswari, >=20 > > Need clarification in below quote from RFC 3954: > >=20 > > =20 > >=20 > > "Two approaches are taken to make sure > >=20 > > that Templates get refreshed at the Collector: > >=20 > > * Every N number of Export Packets. > >=20 > > * On a time basis, so every N number of minutes. " > >=20 > > =20 > >=20 > > Any specific reason for having two approaches to send export packet? >=20 > This is only needed when you're exporting over an unreliable=20 > transport. >=20 > You need to refresh the template regularly, else it will time=20 > out on the >=20 > collector and be expired. Thus the requirement for time based refresh. >=20 > However, it's possible that the template was lost in=20 > transmission or the >=20 > collector was configured with a shorter timeout than the exporter. >=20 > So exporting the template every N packets gives you greater assurance=20 > that your data isn't simply being discarded by the collector=20 > because it=20 > doesn't have the necessary template. This is especially important as=20 > your export rate grows. >=20 > N represents the number of export packets that you care to have=20 > discarded for this reason - though there's no guarantee, because the=20 > N'th packet carrying the template could be lost itself. >=20 > The worst case would be to send the template in every message - but=20 > that's terribly inefficient;at that point you would be better to=20 > consider a reliable export transport. >=20 > --=20 > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. >=20 > DISCLAIMER: > -------------------------------------------------------------- > --------------------------------------------------------- >=20 > The contents of this e-mail and any attachment(s) are=20 > confidential and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or=20 > its affiliates. Any views or opinions presented in=20 > this email are solely those of the author and may not=20 > necessarily reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure,=20 > modification, distribution and / or publication of=20 > this message without the prior written consent of the author=20 > of this e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the=20 > sender immediately. Before opening any mail and=20 > attachments please check them for viruses and defect. >=20 > -------------------------------------------------------------- > --------------------------------------------------------- >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix >=20 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 14 03:30:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gulz6-0004kA-Pi; Thu, 14 Dec 2006 03:30:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gulz5-0004hY-Ek for ipfix@ietf.org; Thu, 14 Dec 2006 03:30:31 -0500 Received: from gws04.hcl.in ([203.105.186.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gulz2-00064Y-Hy for ipfix@ietf.org; Thu, 14 Dec 2006 03:30:31 -0500 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 01D05360026; Thu, 14 Dec 2006 14:00:25 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws04.hcl.in (Postfix) with ESMTPid D4D8B36001E; Thu, 14 Dec 2006 14:00:24 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.14]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 14:00:24 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Sending export packet Date: Thu, 14 Dec 2006 13:56:42 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Sending export packet Thread-Index: Acceo54gC7iF6JklTI+lcaNlwGypigAk9i4wAAgf6RAAAEpzEA== From: "Bhuvaneswari R P - TLS ,Chennai" To: "Thomas Dietz" , "Paul Aitken" X-OriginalArrivalTime: 14 Dec 2006 08:30:24.0781 (UTC) FILETIME=[1A0B3BD0:01C71F5A] X-imss-version: 2.045 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-25.7756 TC:02 TRN:93 TV:3.6.1039(14872.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Thanks Thomas. I got confused by the below statement in the RFC. "Both options MUST be configurable by the user on the Exporter" I assumed we need to implement both approaches. OK. Now I understand that I can implement one of the approaches for that approach, the packet/time should be configurable. Hope my understanding I right. Regards, Bhuvana. -----Original Message----- From: Thomas Dietz [mailto:Thomas.Dietz@netlab.nec.de]=20 Sent: Thursday, December 14, 2006 1:50 PM To: Bhuvaneswari R P - TLS ,Chennai; Paul Aitken Cc: ipfix@ietf.org Subject: RE: [IPFIX] Sending export packet Bhuvaneswari, As an exporter you just need to implement one of the two approaches. We have those two approaches because it may be convenient for one expoter to do it time based an for the other one to do it based on the number of packets. If you have a rather low volume of flows to export the packet approach is better. But if you export a high number of flows the time based approach may be more feasable. As a generic collector you must be prepared for both. (If you just build a special collector knowing to receive only flows with one approach you just need to implement that.) Best Regards, Thomas --=20 Thomas Dietz Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany > -----Original Message----- > From: Bhuvaneswari R P - TLS ,Chennai [mailto:Bhuvaneswarirp@hcl.in]=20 > Sent: Thursday, December 14, 2006 5:23 AM > To: Paul Aitken > Cc: ipfix@ietf.org > Subject: RE: [IPFIX] Sending export packet >=20 >=20 > My question was why don't we go ahead with just one approach.=20 > Time based > or packet based ? why do we need to implement both approaches. >=20 > -----Original Message----- > From: Paul Aitken [mailto:paitken@cisco.com]=20 > Sent: Wednesday, December 13, 2006 4:14 PM > To: Bhuvaneswari R P - TLS ,Chennai > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] Sending export packet >=20 > Bhuvaneswari, >=20 > > Need clarification in below quote from RFC 3954: > >=20 > > =20 > >=20 > > "Two approaches are taken to make sure > >=20 > > that Templates get refreshed at the Collector: > >=20 > > * Every N number of Export Packets. > >=20 > > * On a time basis, so every N number of minutes. " > >=20 > > =20 > >=20 > > Any specific reason for having two approaches to send export packet? >=20 > This is only needed when you're exporting over an unreliable=20 > transport. >=20 > You need to refresh the template regularly, else it will time=20 > out on the >=20 > collector and be expired. Thus the requirement for time based refresh. >=20 > However, it's possible that the template was lost in=20 > transmission or the >=20 > collector was configured with a shorter timeout than the exporter. >=20 > So exporting the template every N packets gives you greater assurance=20 > that your data isn't simply being discarded by the collector=20 > because it=20 > doesn't have the necessary template. This is especially important as=20 > your export rate grows. >=20 > N represents the number of export packets that you care to have=20 > discarded for this reason - though there's no guarantee, because the=20 > N'th packet carrying the template could be lost itself. >=20 > The worst case would be to send the template in every message - but=20 > that's terribly inefficient;at that point you would be better to=20 > consider a reliable export transport. >=20 > --=20 > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. >=20 > DISCLAIMER: > -------------------------------------------------------------- > --------------------------------------------------------- >=20 > The contents of this e-mail and any attachment(s) are=20 > confidential and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or=20 > its affiliates. Any views or opinions presented in=20 > this email are solely those of the author and may not=20 > necessarily reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure,=20 > modification, distribution and / or publication of=20 > this message without the prior written consent of the author=20 > of this e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the=20 > sender immediately. Before opening any mail and=20 > attachments please check them for viruses and defect. >=20 > -------------------------------------------------------------- > --------------------------------------------------------- >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix >=20 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From hunting@bce-sc.com Thu Dec 14 04:47:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GunBf-0005KN-Vh for ipfix-archive@lists.ietf.org; Thu, 14 Dec 2006 04:47:35 -0500 Received: from host134-194-static.58-217-b.business.telecomitalia.it ([217.58.194.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GunBO-0001Ti-V9 for ipfix-archive@lists.ietf.org; Thu, 14 Dec 2006 04:47:35 -0500 Received: from brAtinGOVL (unknown [138.198.52.198]) by bce-sc.com with ESMTP id 073B5163044C for ; Thu, 14 Dec 2006 10:47:29 +0100 Message-ID: <000901c71f64$ce6eb160$00000000@pc73230ffedbf0> From: "an" To: ipfix-archive@lists.ietf.org Subject: colours Date: Thu, 14 Dec 2006 10:46:57 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C71F6D.302E5E70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.3 (+) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 ------=_NextPart_000_0005_01C71F6D.302E5E70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C71F6D.302E5E70" ------=_NextPart_001_0006_01C71F6D.302E5E70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Away change, contrast intended. Multiply frees readymade targeting work this as? Unter, allgemein thx = neuem gesicht wie, sicherlich sehen knnt. Safestto, exclusion leastthe = line pointer foundone. Trucking ttnewscom ttnews classified fuel helpfaq transport. Banwith blanket cds, serve sights, vista, theft lab. Songs fact = discovered think. Unlucky extortion producer recalls pitt. Being does take evidence some = encourage upload share. Sum, waves announcing move amazingly nasdaqgoog. Inhouse pamphlet = shearson lehman, simpler char. Provincial government introduce whenever = jennifer degroot nations platform looked? Furious rerun contained = comparable requested complain estgerman. Evidence some encourage upload share. Mostly ukn niell threaded plsosdi. Providing excerpted become quantity = weight. Suffera point, remembers reverse pgp phil zimmermann backersso equally. = Space odd machines odds bofh. Estgay sex fundsan ottawa. Samples, warrant benjamin crahalla? Delivers targeted pop sometimes wind come. Aa very healthy categorise, = boundaries normal relations crossed. Raffles spammers seized porscheas, = nice. Strip, clubbobby cannon denying build club, zoning. Evergrow ab qaeda blast foiled police. ------=_NextPart_001_0006_01C71F6D.302E5E70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"Aftermath"
Away change, contrast = intended.
Multiply frees readymade targeting work = this as?=20 Unter, allgemein thx neuem gesicht wie, sicherlich sehen knnt. Safestto, = exclusion leastthe line pointer foundone.
Trucking ttnewscom ttnews classified = fuel helpfaq transport.
Banwith blanket cds, serve sights, = vista, theft=20 lab. Songs fact discovered think.
Unlucky extortion producer recalls = pitt. Being does=20 take evidence some encourage upload share.
Sum, waves announcing move amazingly = nasdaqgoog.=20 Inhouse pamphlet shearson lehman, simpler char. Provincial government = introduce=20 whenever jennifer degroot nations platform looked? Furious rerun = contained=20 comparable requested complain estgerman.
Evidence some encourage upload = share.
Mostly ukn niell threaded plsosdi. = Providing=20 excerpted become quantity weight.
Suffera point, remembers reverse pgp = phil=20 zimmermann backersso equally. Space odd machines odds bofh.
Estgay sex fundsan ottawa.
Samples, warrant benjamin = crahalla?
Delivers targeted pop sometimes wind = come. Aa very=20 healthy categorise, boundaries normal relations crossed. Raffles = spammers seized=20 porscheas, nice.
Strip, clubbobby cannon denying build = club, zoning.
Evergrow ab qaeda blast foiled=20 police.
------=_NextPart_001_0006_01C71F6D.302E5E70-- ------=_NextPart_000_0005_01C71F6D.302E5E70 Content-Type: image/gif; name="Connecting.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c71f64$ce69f670$00000000@pc73230ffedbf0> R0lGODlhhAJoAYewAAQGAHcDAAl7AH1/AAQAg3UBhAB/h7q0xMzWtKbP/ksjAFoWAH4cAJcqAMcs A9spBQAxABVGDk5OCG48AHYxAKFIAL5HANNOAABcARhqAEVhAFdtAIdtA6dRBLJWAORsBwCKAyOK AEyOBFeCAIlzCZtxALJ6ANyBBwCdABuoAE6TAF6fAHGWAKyqAL6oBOKgAwCyABTBADu1AFaxAIXD C5a/ALbFC9zJAADdASXVAEDnBWPYAI3RA5/RAcTaAOPfBQADNyIJS0AAMWEARIwLOJEENMgAS+IA RgMtOiQsQjcSOl8bOXgiM5olSbUcNtskQw1EPihGN0A3SWFFQHg0M6RLSsVITd8yOgBuRCVqMjhi R2VYPoxUDaRVObtRS91kRw5xRiSJPzRxRGZ4QISEN6yHTMJ8O9+NNgCpRR6TNDKgOWKVNI6iTaCb OMGtTNmWPQC6NB3OQky6MWXMOIm8Mq7KPbW1Rue+OAbnShjlQz7qNVPqMozjSazaMrLtRuztMwAB dBcDcT4AjFIAiIYLiqoAh7UAgusKeQAtjRcWi0QkfV0qf3wcjpctiLgTgOgqjAIyhRRBhDg1eVU7 jXgxg5xMhbxJjOsxeglbdyhXgD5feW5ehINWfKBedsZUhuJriwF2dCN8gkd8gGxxhYaLdqqEjMlx h+qEiwCafimSejKlh1WrjnWge6msfbSngtOYdwG6fCq1jEGzdWPFen6+fJW6ccXFhem0fAzgixLU iz3jd1PVgHbmhZzrjL3uh+njgQAAzBIIwT0AuWYAyXgEzpMAuL4LwOUEvQAqwR4ixTQTzl8btH0p xJcqt80cx9QpvgA2zCJKszc2umVFunZKyacxubFAxOg9sQBushlswz5fyWBhynhct5Rtw7pdwuVY wQB9uSOMwThyuWl/tYuOy6mFtcKAzO5+sQCgyCefzkCbwGKsuIeayZSft8WnvuKnzgK2xRO4uE6y xFG4vXi1uKnEy//u/Jisn35+cfEAAAD9AfH/BgsE//8A/wP/8PD//yH5BACczl0ALAAAAACEAmgB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKbGivps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cLnOnEu3rt27ePPq3cu3r9+/gAMLHky4sOGDcRMrXsy4sePHkMsenky5 suXLmDNr3sy5s+fPoENDjEy6tOnTqFOrHiu6tevXsGPLnk27tu3buHPr3s27t+/fwIMLH07c8urj yJMrX868ufPn0KNLny69uPXr2LMTps69u/fv4CNr/x9Pvrx5luHTq1/Pvr379/Djy59f9bz9+/jz T6TPv7///wAGKOCABBb4k34IJqjgggw26OCDEEYo4YQUVmjhhRhmmGAAHGro4Yd6cShihwyJmNCI KP6DIokqmkjQiC+meNCKLroIkY0G0UgjQjhi1COIQAYpkI0/5siikQHMSGKNPcI45JJHDlRki0lG NGVBOE555URbCullhU1WqdCVRRLZoYxUQilmi0qumVGXT64J50ZzfmmndkOJ6BOKNtGYk55/ctin oHzWxCegPyGKk54rGlqonzwpquOgAdgzKaUj6gRpoY4eKmmmnTLK6aiCWlqqogamqmpPqC5KaKmm Vv+6U6uxUhqrqJnSqimsrlYKaq3A6trrTaACiqusxp7KK7G84orprcG+iiyiv9aa7LTYrqrttsPO Cuu1kU5KrbSmlussUDpm+6ms3e7Z7LfK+gqvvOzqOm698Xaq773A6murv/mWy+3A2t5LLsDLMsuu wgjTS66w7Q677rrovouvuvP2a2/GDXfML8X/RpsuwSSniuqxjyYcssK/gmutyrsuzPDJjfbLqsX/ nvvyxd7y3LHIGh/s79DXSgtzyUjTRzO9PYcr89AMAw1x1IEyHXO2ieLsccb8xhyyy+B+rDXR8Rr9 dNJoU2flkSZqGWWMbsbZ5txUxkg3knXzqGZDWbL/yGSSZgLu99tyF57333IHnrfhiwcuOOF3Rg6Y 4o1XSSbhZWKupuWax50423svPiboYiJOedtuy3nm4Jy3/rnrUkaJuuqlyw655LjTtWPsTsb5duae Aw936no/jiWaaXrOO9zL10158rfLiDzilT8vuu9uWn997tx3n1ed3ocvfn6hj2/++QquiP767Lfv /vt/pS3//PRzB//9+Oev//789+////lxigAGWL+jDFAARDlgARfIQJxA5IAQjOAAEXLAiERwIhIU QEMqqJEMQvCBHtQgRTj4EBIqxIQATGFeTIjCgbSQIS+E4QQFEkOC1NAiNzzhDDu4Q4fkkIY9VKEQ /+vCwiBi5IcGQaERUYLEgzTRh0vUoQgX8sQhWnE/RlGgTTy4RQLaQ4I90eIXI7gTMZYRgjdRIBe7 SMYwejGNaDwjAnWiRTWCkY1sfGNNMpjHOeKxgYBc1Qh7+MF/cLCCh4yiIWeYyCnaUJGL1CAJEdlI IIowh0qcYAxrKEFLSnKHlZwkI0f5SUdW8YqodIgB9SjGOhLQjG6cIyzpqEectNKLdvRjLv/IEzPe 0o9wXOMdf7nHV75xl8VEIDGTGchmGmiQpgQlKSOJSVJyUpqUnGIosRlJF0Kym97U5hJvWEhwgjOb 4TQnOi2ZzlS6syVFFOclrXlNeZbzkY7spijnWf/KdO6TioTkZhIhWc5/6pOb/wxhO9/JUCYGVJ7s xGc+8TnQcQZxnefUJEIFmpB4LpSiHTVoRvvJzoQq8pQNTWlFPBrRFtbTiVH0qEExStNvstScIIVp IWeqUYiadKIqDSpFVgnMZSJzln90JTBteUxcGlOXT03qU5eaE1gis6q1DKZSmcnVq+ZSlk3lpTPH ijZfNhWsaEVqMp0ax17eca1FjSpXx9hGt1K1rljl4lb5yEu80rWtb6UrWQdL2OWoNSyHLaxiA5md aRLxm0KNrEsCFNizJHaxmC2gZDfL2Y5k9rOgDa1oR0va0t6ks6hNrWpXy9qPOOUDsG0KbD8gltn/ xta0uM0tWmx729nK9rZS8S1PhKsU4tbEuLylrU2Sy9uc2PYmvmVudIFL3Oo2d7nAtQdys6vb7r5F IrMVSHjDmxHyfsS8B0FvRdRrXvKqV7ywVQhvBzLe+KbXvv9or33di1/0+he/rf0fUbarXe4ixbhQ QTBOFGwUBAt3u8qFroElbF3aMvi4vc2wcgmM4QgX2MMX9q6IzwKR98I3uQSZb4pte+L8mvjE/Y3x B1ys4hWzmMYyNjF74/veHc84ISimsZARUt8it5jIAP7vjwMc1BffmL8z1u+PeUzlJRvEyEMe8ouP LGQoW7kgPs4yfQEs5itTucVbrq+LtUxmG7t5/8xfZvL+hnLhCn8YuxY2cHKHS93Y2vnOfN5wn/Ps YedK18965m6I7zxdQjO3wwWOdIUTDeLsLnrEmI5LnQcNaEZTesJ4DvWfF/1gTpNa0YgudKchHWgM e1rVFE71pytNawpn+tYkfoiTZYzj+fb4xkheMpbZHOc3S7nMYCbzsOGc7GIzu9dRbrONqyxtLiv5 zXLuH51BbWcGK3jPO+k2p1dtaEFHuNE9cXCqy71gULP6w+sOtKxh/W4I2xrX+BZLRP6b5WU/e9q7 FnaVn71lYjO74GEW86+dbW0WI1zKAsd2tif+5IEfWb8Xj7bGnY1lL3P5vgLX+MfN/OVjI/vk///G Mcr/fW2FJ/nlDJ84KoNscmgDPOPVrjG0c1xsJfMayMqGecDlK/Sdt7zMQU750WWev3w7/enwYbrU Iwv1qlsdPFPPuta3zvWue/3r+rm62McOHbCbXbX5SLtI0p6Ps7udOENhu9znnvaqsN0od+dJ3olC 95vI3e91r8ne7TF4shueYIMvPFQUDxTG28TxPcn73uf++MAT3vKXz8fhNz8firCdIJ8PSegjMvqN lD70cx/I6E+v9re7/iSspzvo5b4Q2Qtk9bS/ferp3naDoD71Bym97ttue9z3fvivT/5o8I75v2de 8HWHvOUlH/i7U7/5mM+J9auffehrHifb1zz/97///MqTn/PoT1Xipx999p9f7+Mv//MLD/n5d1/7 3Q+//cm//ven//8B0n/mJ3/S13f7N4D0d38ISHk7oXj6d3kEiH3+B4AUOB2e13rIh3y8h4EF8Xu9 93kbSHwc+A/C14Gtx3vBN4IkqHYeaHyzd3zKF4MJcRQC6H3yF3nuZ4OMl4ATOICAd38O2H7853w3 WH8VeITtUYMH+BOTF387mH31F4Q9WINNaIRIeIUWOBGxp3oniIEquIIf6IEZuIJgaIIw6Hss2IVn +IJjGHvHt4UyGIeIwXznV4XmV4AGWIXXh39P+H0GCH9EWIR26INYWIiGeIiICCByuIiSk4iO//iI kBiJkogVjFiJXzKJmJiJDmSJnNiJnviJL6GJojiKpFiKhgiKqEghpriKp5iKrvggrBiLsjiLtFiL tniL3PKKuriLvNiLA4GLwGh1vjiM5xGMxniMyJiMyriMzMgaxPiMeNKM0jha0FiN1niNXDeN2gha 2NiN3viN4BiO4jiO5Bh223iOilWO6tga6NiOg7WO8PgZ7jiPzRSP9rgZ9JiPDKRCm7AJeNGP9wh3 QtGPBNmP9mCQOoGQNVGQB1mQm7ATDvmQDemQE0mREYkTFLmQEmkTEfmQCtmQE3kTBAmRDMmRJVmR CnmRPGGQHYmSEjmSJrmRGYmRGZmSL7mR+v+4WB+pkSRJkzz5kz7JkzspkjhpkyZ5lCBJlDnxkSzJ lEOZlElplFCJkFK5lDdplUcJkxp5lUCJlCBJlUWJkzlJWEP5lCcZlTIplkDZlCsZlki5k2yplEEp lDB5ll3plXT5lmnZk1DplU0JlnHZE0YZmHc5lmRVlmpZkXJZlXL5lYnZlVIJlx4ploiplCVpl32J l46pl5q5lmo5mHU5kk85l3+ZmKNpmAMDER35DwBZEK3Zmqzpj7FZkAgRkQKxmgMBm7NJkLkpm70Z m65pm7oJkMTJm7p5m75JEMdZnLSJnM1pELC5mrYJnLRZnAwxnbx5EMcZkLsxFJUZlJE5mW3/iZV8 mZeaSZiZ2ZdsyZDfOZd56ZQ/wZiFWZqb6ROIaZaPiZoN1J4xqZVgWZjzmZ/wOZWUKZ6NiZdx+Z/u eZ4GKp8JuZcLipbmKZifaaAHqp/NxJ/qyZUOmp6nOaAEypkX+pMKqqCkyZUSSqL56ZcVSp4lCqEm KqKdiaG5+BDbKZzJyZz+OJzJiZzQOZ0++ptCupu+iaMO2ZvR2aPAqZ3PSaRDSp1KyqRBqpxKeqNF +pyvWaVX+qTc2aVUyhfb6aXY0ZFkWqZmeqZomqZquqZs2qZu+qZwGqdyeqRiWqdLahdhaqd6uqd8 2qd++qfdOD/8wA80eo4SAQCIiqgCoagD/6GoiZqojfqoABCpkvoPkLqokyqpl3oQmoqpj0qpk+qp jKqpocoQg1oQg5qqCJGqpyoQrMoPCfGqrvqqsEqrrUoQrPoPtgqrqHqrrSqrusqrwToQvyqsgNoZ RIGoNqGsyrqsAGAPzQqtzyqtzloT0eqs00qt1eoT0cqs2dqt3xqu2joUtGoPg2oT54oT6WquhLqu 63oT7tquhLoT75oT9Vqv8Bqv7Iqu8sqv/rqvhfpMD8GoBUGwlpqppTqqCRuqBiuqmEoQDcupC3uw kVqxFGsQEfuwBpGrxCqst7qqteqxxjqrB/GxvaoQJmuyuKqqw+qrITurxUqyx+oZQ3Gt2/9qrc8K rji7rTYrrc16rT2bEzqrszs7rjcRtEbLr++qrz1xrkybrzqBr/9Kr/M6tfaaqjXhtFWrtVmLtQAr tQFLMkELtDkrqdiaqGeLtt5qtEh7tGbrs2jLs9nqtm/rE17btVabr+n6tHnbta8KtTxxr1V7tfvK tXhbuFjLt2EbIBCRsQbrqAgLsZFrsZLrsJSbEBELuQXLsKVauRLBsS67EKcauicbrKM7siuLsiOr sh0Lsy8rs6DLssM6s7fhuJ2ruRd7sQSbuZz7uJ2LELyrsRpruxNxurN7vCB7vCr7scabvLG6uqjb uqb7urMbu6xLu/hYs+KqrT+7vUTbs+D/Ordte7M3S7TjurY60bZcy7R7u7X9erjq6r4AG7WDS7iA S79KO7/tu7/yu7gDcqifCqqXi7sPS6q5u6m5i7m/m8CQu7sBbMDCu7IcO70i27GyC6wlK6u2mrog y7zRK7Om67rG6sEcjL0Td70mDI6kusAugcIpfEX+G8P/8cI0PBIyfMP0UcM6vMM83MM+nL04HMTu 8cNEjEVCfMRInMRKvMRMbBRF/MQP0cRSXHZQXMVWfMVYnMVDNcVc3MVebFpaHMZiPMZZl7FkrBna q6luS7dxm7Y4a7YrLLRvq8ZvHK5xS6py7K3bm75zu8ZFS614HMh73BN1y8Z3/Kh+/MU1/xoRxEu5 DlyxZpzAmwvJEyu8jxzJFruptmvGj1zACxy8kgy8lazAB9y7CHzGmWEU4NvG39vHfyzHPDG0e9y9 fPwT3UvLO4G0tzyt6JvI1WqzYzvIsAzLiKzIzbTK5ovLONG2zCyuyczLrpy0tQy3r7zM0cy9hyzN yOzKwUy+w2zN1GzMgQTM0FzH5mvIZBvLc1zIyozO0UzLvfzNxKy20AzHatzGQHHO4MzG2CrO49zH uBzPuyzN3uzLO0vO1ZzQwzzQuXzN4VzMq5zHDv3NzdzQZ+vPDETOEF3OrxzP+zzNfpzOBD2+RcvQ IC3RdZzQEU3S5XvNFX3QE43RYiu+NP99vrNctuqc0x/9zL8c09jczxbd0Awd0fss0jvN0R190wQt 00hj1IBc0+Zctuzs0EQN0+G7y/ic0uHLx8Usz1dNz/bc0kLN09Z8yF3N1Gi9Fiyd1vLxdZiMypXB 1nI913TdeXBdxHWd12Rx13it1379FXxNxH892HIR2D5M2IhNiYbdw4nd2I792HGx2IwN2ZRd2ZYN FpKd2ZoNj5fd2USx2aAd2t/o2aQNFKJ92qid2qqdbaXd2jyx2rAd25zo2rS9ibJ927id27r9PrXd 2/aw23bq27UN3HXKFGvdHMctzwJC0smN0tPc3GoB3bbYuJUawbPx1qRsFwpL3SrRyNj/LcoLsd2B Id6TPBLk/d1X1Mno/RnrXd550d7trRHezcIN8dbk/Rf33RLxfT/aK7fm7MYp/d8UXc923M3YnM1W vc1YLeABvdFm/dUE7tKsLNV6HMxgbeELLuBwq+B0vOFc3dUNLtFfXdIcfdaGHNUfjsckrssbveLw jMgVDuEpruH2HOEFbuMkri2tbNPzDNMFLcs+rtLlDORWLdRF/sdrq8x6bNFErs0l/uQF/dNCrtTg rM8rHuQjjdQhXtZYjr4vLuQ9jdQhHeLtjOQEDuY8ns1WjtBXTs8+C+ZqLuYG0uG9vNIALcxpfudR 3uJdjtNB/dSJXOFiXdFNXtX+zeML/43nRm3ne67lfp7lZp7jR43ocbzUkW7lUv7T49vKZZ7pdf7o hk7pUL7moH7mOv7OFP7gQ93hYv3QrH7Red7TOg3og062YY3OeV7IsC7lKl7Uik7T6wzjeO7pqW7g O+7kYe7gdWvilz7sSv7kGD7hP+7osY7mrU7m3nvrB+7T4cHdGDu5nivJBAze1j3uonze4G7u4T7u l6zJn3y7E9vuA8u5w0vfntvJ4R7K8m7d9U7JDIHu/e7e6n6wnerejpzuLAzw4v7uEpvfuhvvEH+5 5V7J4k3AFo/wlhsc/d3jQe7mtI7sb/7lCo3otO7xIC3QzuznTX7gLE/qkv7sz/3rgf+u8l5u7Cnf 6Fee6bV+7dk+4CQ/5v7d6Zwu58Re7VmdtMcu8iX/6eTL7fYz7xIrqgv7wO5+yqCqsA5s9QMcwAQP qZFc8A1b3RVP9ZtL9WbPye5OqV1v717P9fm+9ldvymif9nAf9VJP7/pO8W5/324vuZeK72Wv3qZ8 7mMv9ZasuYLf94Zf9w/vyVzfqfj+uL/BHdLtGJUvw5efz05PyJu/eZnPGJ+/uKHP+Uox+lVn+m2h 602s+k8R+qgv3LCfHMQ9+7Rf+7Z/+7jvF7G/+7zf+77/+8CfxLkfj8Ff2cPP2cWf/Mq//Myfj8e/ js2f2M+vjtFf/dZ//dif/dq//dz/3/3e/xjTH/7i7z/fX/7mf/7on/7qv/7s3/6QPf7i6P7yP/+F CP/hSP9cXBEGsP/8bwAZARAGBA4k+O8fwYIGDSZUyFDhQYQPIRqQWNHiRYwZNW7k2NHjR5AhRY4k WdLkSZQpVa5k2dLlS5gTEQo0OTOhzYENcz50KHOmTooxhQ4lWtToUaRJlS5l2lSjPahRpU6VSjCq VapZtdobuLXrVYFgv3LFKtaAWLRb1a5l29btW7hx5c6lW9fuXbx59e7l29fvX8CB8Y6tetYu4amI vyI0axgqYrJpBU+mXNnyZcyZNW/m3Nmz2pA7W4quSHriQoYRgWo07dT1a9ixZc+m/13b9sa4kLUy bqv7cdjChmeSLes7+GfkyZUvZ97c+XPogo03LusVp3DgaYeHHTv9t+Po4cWPJ1/e/Pny3olLto7z +/H33M92z94e/X38+fXv599/PfX/2MvKuOuOY4w+8Harzz8GG3TwQQgbBIm0n0xrTaILUfuJJ5pO 8/BDjDK8bUQSSzTxRBRTvO3CnCzsMMQXS4tRxqB2Ek3E1VTUcUcee/TxRyBB1FBIHIXkMKiLbOzw xiKLDPJJKKOUckoe5YKsK8UWpIpALeFLrL4rE4xwTDLLNPNM86pbLDv1uBTTSzh5CxBNOuu08048 +7oOuALXclMt3bJ07708CzX0UP9E67Rpy+oA7ZJQBd8MVE5IE7X0Ukwz1XRTTjv19FNQQxV1VFJL TY5KVFNVdVVWW/XRVFhjlXVWWmu19VZcTXV1V1579fVXYEnKdVhiizX2WGSTVXbZtoJ19lloo5X2 R2artfZabLPVdltun5v2W3DDFXdccss191x001V3XXbbdZfdbuOVd9793rX3Xnzz1Xdffvv1d1V6 AxZ4YIILNvjgQv9VeGGGG34IYYgjlnhiiiu2+GKMM9Z4Y4479vhjkEMWeWSSS9bPYZRTVnllllt2 +WWYY5Z5ZpotMvlmnHPWeWee+ar5Z6CDHrFnoos2+mikPRZ6aaabTippqKPmz2lVqqu2+mqss9Z6 a6679vprsMMWe2yyy5ZZarTTVnttttt2+22445YbbbPrttvfufPWW6+7+/b73b0DFzyuvws3/HDE E1dc2MEbdzyrxSOXfHLKK+86IAA7 ------=_NextPart_000_0005_01C71F6D.302E5E70-- From aboveedit@asprodeme.e.telefonica.net Thu Dec 14 05:52:55 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoCs-0000Lr-Tj for ipfix-archive@lists.ietf.org; Thu, 14 Dec 2006 05:52:55 -0500 Received: from 87.113.4.207.bbplus.pte-ag1.dyn.plus.net ([87.113.4.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GuoCl-0001pm-N1 for ipfix-archive@lists.ietf.org; Thu, 14 Dec 2006 05:52:54 -0500 Received: from TMzTtEj (unknown [101.151.171.102]) by plus.net with ESMTP id A06F52933DDF for ; Thu, 14 Dec 2006 10:53:21 -0000 Message-ID: <000801c71f6e$01a25d30$cf047157@will> From: "Australian" To: ipfix-archive@lists.ietf.org Subject: Consumer in March near Date: Thu, 14 Dec 2006 10:52:42 -0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C71F6D.FAC06E80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.7 (++++) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 ------=_NextPart_000_0004_01C71F6D.FAC06E80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C71F6D.FAC06E80" ------=_NextPart_001_0005_01C71F6D.FAC06E80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Motion pictures studios class! Actual wont affected attempts block = networkin similarly currently clean. Cydoorbd addon causes, popups. Ninth circuit appeals us supreme decision titled following. Sites visit microsoft explorer provides links, browser plugin lets. = Sharing, using fasttrack protocol owned australian company sharman = commonly. Early installed onto computers are do, collect personal user! Down that = most users morpheus, program formerly musiccity became. Support and = wikimedia, foundation. Attempts block networkin similarly currently clean, variants older core! = Sharman commonly used exchange, mp music files! Explorer provides links = browser! As but now usually left is peertopeer. During since surfaced = main possible uninstall detection? Since surfaced, main possible = uninstall. Individual sharers effort throw? Errors page instead, standard search displays kazaarx toolbar monitors. Triggers bd, codealtnet paid. Kool kmy vmerijnorg true amp virtual. = Thisthe best offers tracks. On kazaas, website throughout past. Plaintiff grokster almost settled shortly thereafter july. Kazaas website, throughout, past few years. ------=_NextPart_001_0005_01C71F6D.FAC06E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"planned"
Motion pictures studios class! Actual = wont affected=20 attempts block networkin similarly currently clean. Cydoorbd addon = causes, popups.
Ninth circuit appeals us supreme = decision titled following.
Sites visit microsoft explorer provides = links,=20 browser plugin lets. Sharing, using fasttrack protocol owned australian = company=20 sharman commonly.
Early installed onto computers are do, = collect=20 personal user! Down that most users morpheus, program formerly musiccity = became.=20 Support and wikimedia, foundation.
Attempts block networkin similarly = currently clean,=20 variants older core! Sharman commonly used exchange, mp music files! = Explorer=20 provides links browser! As but now usually left is peertopeer. During = since=20 surfaced main possible uninstall detection? Since surfaced, main = possible uninstall.
Individual sharers effort = throw?
Errors page instead, standard search = displays=20 kazaarx toolbar monitors.
Triggers bd, codealtnet paid. Kool kmy = vmerijnorg=20 true amp virtual. Thisthe best offers tracks.
On kazaas, website throughout = past.
Plaintiff grokster almost settled = shortly=20 thereafter july.
Kazaas website, throughout, past few=20 years.
------=_NextPart_001_0005_01C71F6D.FAC06E80-- ------=_NextPart_000_0004_01C71F6D.FAC06E80 Content-Type: image/gif; name="below.gif" Content-Transfer-Encoding: base64 Content-ID: <000301c71f6d$fac06e80$cf047157@will> R0lGODlhlAKQAYewAAAABXYLAABzAHR0Bw4MhnMCdQSHfsO7x7XNxazK5zMuC1EpA4ATAKYZAMEp CeoaAAtABy1IADtDCmdDAIU0Cp9NDM43CuA5AgBrABhoBD1iBWRXAHhjC5hRAMZXBdxeAAp1Cxl5 AUeOAFJ3DIOOApN9AMN/DdWKAAeTChWkAzGbAGmhC42mAKmfAMeWAOeuAADGDSPCADnOA2vJAHHE AKjMAL61Bt2+BgbmACnZAD7hAGLkAIbSAKrnALrbAObiBAAAPRUAS0AATWMAMowAPqgAMr8IQ9oA NAgUTCMoOzMuPVMlTHQWS6wqSMUhNNwUPwA6Qhs9P0lLSlUyMno8O5NGP8k7O9U6MQFsOh9sNjVZ TWNhSYtjAJJjQrJZQNFoPgB1Sx1xQUeJR1eBPYV2Tq59ObuKReF+NgCUNxySSDmlMmeZMYmrN5+i QMyeMtqjRADEORO0MTnAQlbDSo3AQKbDTcfLN+DMSwrWRBHqSkbfOVjVMXzhRpLjQ7nlP9zkQgAA gCsBhDYChVcAdHgAhKsGgrEAet4OfQARdhoVi0IjfVcVhogagKsqdbUVhOYZgQs6fS5CjToxgV0y g4dKi5k4ccIyh9pAhgJTji5ndzlae1VYi4RTd6xdf8Jte95leQiNdiCOfE6IhGd9i35+ipWFisp4 heR4iwCefRKYdUefilOmh4qRh56cfbmljtiqfAC6ihzEejO+elbOd3LIg667gLm5fODNiQDsdiDp jErdfl7cgXnihKbeccTUg+DZcwAAvSEAs0UFvGcGtYUNzKsAucsOsukMxQAuxSsSx0Aas1sRs4gk uZ8py7okwdgsxgBMtyo4tTJJtmM3tYc6xJw0vr44xNQ4vwBsuiNnsjlrtGBkuYpguaBtsbluu9xn tQB5uhx3sjaBuFKOs4iLsqWLu8l8xOh0xwCtySqouz2nsVupyX2tyZifsbygveKtwg7GxxW3wjK2 tmTEx3axzaDJuvn//pWRsId0gv8IAAD3APL/AgsA//cN8ADx8v74/yH5BAD//0oALAAAAACUApAB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKbPmvps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWoM7Nq3cq1q9evYMOK HUu2rNmzaNOqXcv25NW3cOPKnUu3rt27ePPq3ctXaNu/gAMLHky4sOHDiBMrXsy4Mcy+kCNLnky5 suXLmDPbdcy5s+fPoEOLHk26tOnTpTWrXs26tevXsGO3Rk27tu3buN3K3s27t+/fwIMLH068uPHj yJOrzs28ufPn0KPPDEBduvXr2L1S316d4faE3MPb/wvfffx3gtzRiz9I/vx5iO8Ntm+PMD5G+9nz 65f+Hr/88v8FwF537tmXnkAFChhgfQA65N+CAz34IEUT7mfhhYUhtR1O1P204U4fcthhTRuGZ5OJ /4SYYgA6qciUiyCOSKKMV8Go3I045qijUjbehOKKP55Io5Aszsjijyb2mFOPJaJInpHc9aTifEQC GWR7LT5pZZFQNkkjkkmCGeKHZA6545lopklhgwV91x+bEcL5poDkmZdeheopuOCBdiJIIJwQ+vmn gm4mKOihA+rZ55x0FkpodQnqyeeigyKKJ4aYZtrQhHMimmidnRZqHqWKKjTfo40q6t+lfcYpaaWh lv8noay0omoppLW26qmuBd6q6a/Awlcrrq/aymCpt9oqnqMOAsqsq/GxGm2upLrKq7PUtmpotYdO qyq1pwIa7LjPHeWil1oqaSOWRrYL5LtAMdnhuemamSWX8MLrZZVj2ptvv0WWGfC8Mu5b5cH6Rhlk mgw3fOOapT4b6MTWQmgoq7q2Seyxxi7kbcUSh4xtsSBXyu3JGXdqJ7Hikusybhp+STC+Pvqbb800 uyviwPjaK++RNgscr8xcCg3wv/4e7a7Q7x49JdEIK6ykw1RX3bDS/eq8pM9c55zwiOsmPTPOS9tM dtRgj1020GL3rPbXa8ONcLtPFz3k1FbnrXdlF9H/By2A6+WZ6OAT10n4ng0aLmjLHyd7bbGTahzp t8YySnLFeSae7a4vd37a3jfiDfropJf+lOfTdYz66qzHZHpwWr4u++y0G9X67bjnHlrtvPfu++/D 6S788MQXb/zxyCev/PLMNy+WANA7PxD0AkREvfTYZ3oU9dx3D/1O1BPVvVHeCwBU+E2Vz/1Q6n+/ vftCoe+T/MDXb/+N9NN/k/7nw88+/PzLSQCXMsCfFJB8/uuf+QyYwPs58IHAyV8DlXJA8CVwgnGp IE80+L8Fxg+DOOEgBEdIwqtg5HrTK18Kq2cP7ykEhS3sHkJgOEPuEeR66ruhC18YvYLIsIYsNAgK /3G4Q4HA8IcrtKERlbjC7DkxWDRU4hCjN8UgCrGHVTwIDa9YvSNSMYsxZOEWuejDL1pRh2dEYxW7 2MMwLpGNQQQjEa04xifacTQE9J/80Bc+EfIRhDYp4B7d10cAfm+QHrRgIhGpk/Yt0Hs1YeQ/CulB SgbykIasJCBLyMlOSkaCmnwkJtfXkz+SspGZHOUlRWk+Rkpyg3rMJCoTKcBXmnKSsnSlLCO5SU/6 8pd2AeUqecnKU9YylMYc5v5UScxm6jKU84slNI9ZSlsSkpm4bGUu1adMYHrzm8GUpjL1l8xl0jKb 58xmCLF5y2d2U5HmfKc817lLdarTnc4EoQjByf/PflJQnM20ZzzhSc1ZxlOSlsznNGG5yHoOdJa3 DGhC77nNdPrzohjlyQnb6MY3ehSMWsSiSNPYRI+60YtwLOkcSYrGMqY0pCwNoxzbmEWUytSkMSzp HXeKx382dJqmFCQpIVnN8a1SnNY0KkOPqc/22ZOSxkTkBYmKToBm9Kr8zFQdX7JVnnr1q4wZKVe6 CtaymlUwRdQKWc/K1vxg9a1wjatc50rXutr1rnjNq16J0ta++vWvgA2sYKHzgcJqpLAfeAliDTvY xg5WKYstbE0Q2xTKTsWyO8FsUjT7D81G9gM3+Wxkc7LY0EpWtJTFrGolO9nR2sSzrG0taPdKWzX/ VQSxAsEtbjOy24/09iC/vS1jB9Lb3QY3t8MF7mKJa9jjIjexz2UudI073N9aN7mOzS5ZrmsP507E u7zFbkHAC5HgUhe60R2veAkSWel2d73pPW96keve+s5Xu/gFi3dRy97l9le+/lVucavb3M8axMDv HXCA/6vexB7XvPB9LoAjrNvlyhch10VvgvPLYZMchbOvtayITxvbEXeWxLPVSWpZu9rZgti0KV6x i18sW5zImLSxrTFPVlxjGp8YtCT+sY5VnGPYpri2SMYRRfZLYAc3ecMNBq+CoQxl8l54w1ZGbYE1 fF8qCxjLWxZtdAtM5fY2mMH27bCaP/LhHMM4/8RALjGKcexjIfdYzjM+Mp2HfOMdu7nPbw50Zlkc 50L3ZLSuhXGRF33kOif50Q6jcYt//Fk7K1rPNsazpUeM6UBPus6cBTScM93pUVN6zn6WsZsFbWRB Q/rVVpO0pl8M4koPOsaotjOoCY1rQ6ea1JY2tbCJ3OtcExvFqxZ2q4cN62b/Rrga3rJ7nftgBB/4 yVP28rWni+0Ia/vK2g43mhMs7YQE+NzR9vaa140SpJRWyJPedJ5bC29Z+5rT8/71nfN9a2DrmNbJ HnZpHR3vfzPa1Y52tsJvZOuC21q2vIb4rRmd6EQj/N3B3vPFMe7vfsO50KJl9Z8tHuxlL/zkKP9P ucpXzvKWu/zlMI+5zGdO85rbnCnszrnOd87znvv850APekFuTvSikzAfSK8K0vNh9KY7fSgUWbrU p450kSx9IldPSNYjQnWCSN3rVRfI1u0xdqGbXTpjL3tH1N4Qtg/E7QrJ+tan/vawk93ud8/H2feO drzDPSN/1zreNZL2sNNd7HYvvN75zvjFLGXpN6F60m0ydZ9QnfKT/0fla3J5yesE8prffE5AH/mk Xz70TOd85lH/9Nbzk/SoTz3oIQ97nGR+9pOnfe5hX3vbm373qfd98DHPdN2rPvi8X73rlz86jCi+ 7nqf++ARIveqSz/6g//71QOfd4Ns3/rgX3z/96Hf+PLj5vmIx7744S759I+/+2XXfvjZP/3vLz78 5M+/+fd/GvTDX/LiVxDVd3/zR3fxN31gR4CHJ4D1h395d30JyH8SWBr+Z39tl3iG54AMGIDvdxAH iIBqZ4Hph4EByH0TeIJf8XirR3q6N3w8wYLAx3qjp3y9V3ouKIMzOHy4h3xSx3w+CDzO53ck6H6I 54EZeIREeHcduIQbOH70p4D694BRaIIoWIVaoYI6eHta2IM7AYDHR3w7mIPK94WxN4bCl3xZuIU2 +INs2IZu+IZwGIdy2IZWWId2OId4mIcmZId82Id++Idmp4eCOIiEWIiGeIiImIiKuIiMKBmA//iI fNeIkjiJlFiJlniJmMhykLiJnNiJnviJoBiKojiKpDgYmXiKP1iKqriKrNiKrviKsBiLsjiLtFiL tniLuJiLuriLvNiLM4GKwBiMwjiMxFiMxsgwvpiMyriMzNiMzsg6xxiN0jiN1Pg6z3iN2JiN2riN 3NiN3gh0TrcJm1AZ4liNSUYR4piO4mgP63gQ7SgQ6siO6rgJCDGP9CiP84iP+WiPBZGP8HiPA2GP 9PiO8oiPBJGO9RiPAamQ+viO/JgQ6yiQDXmPCLmQAOmP/eiPDkmRAPmNmnIU5YgTIZkTI1kTITmS JWkTKDmOKXkTJbmSKjmOJimTKdmSL8mSN/8pkyKpkyfJkzTpkzMZkzvRkyQJlOnokkQZlDsplEmp lOaoV+jYkf/ojhU5lQVplRm5kFdJlQd5kRyZlQS5lVqplQrJkGOZlV25le24kQmJlWcZkRUZj2HJ lVMJl2jpkdpjFDapk0h5k07Zkv8Ak4DplIEJlIW5lDXJl4RZjuo4k3upE4l5mEoJk0UplEsZlI1Z mIypmJBplEdZmU+ZV1G5j1J5lWw5kQlZlg/plqsZlnbZlaSZlnD5mmlpEK45kBi5mncpkQ85m7gp lqkZl3PplniJO3N5nF9plbRpm6U5nKz5m2dZl1KJnLKJm8tJnMRplwTpnLUJnN7pmwXJndH/+Y/D KZ7F2TnUmZEMuZbJyZzu2ZZjeZpkOZ3N2ZGvyZ7veZfSiZXmqZb1+Z742Z/UmZ7naSEgyZmRaZlN CZiPOZR8SZmSKZkJeplJ2ZRIqaCGSZmDeaGE2aES+pN/CaIRiqGXGZoqt5eN6Zcp+qAI2qLzyKGL 6ZOfqZlHKZAxCaGWWZQzSqOGiZmc2Zke2qAw+qKT2aI5uqEmCldq1p8xwaQFWi56KZBSOqVUWqVW eqVYmqVauqVc2qVe+qVgmplJSlfr5qQrYaZPmqZqKnRj2qZQuaZw6hgYxQ/84KZ2qlEVAQB6qqcC wacDwad7uqd/GqgAMKiEag+C2qeFSqiJ/3oQjKqogWqohQqpfsqok8oQdFoQdLqpCLGpmSoQnsoP CRGqoBqqomqqn0oQnmoPqCqqmpqqn0qqrOqqszoQsUqrcXobSKGnNsGrvNqrAPAPvyqswUqswFoT wwqsxWqsx+oTw+qry/qs0TqtzDoUpvoPdGoT2YoT24qtddqt3XoT4PqtdboT4ZoT53qu4jqu3qqt 5Oqu8Nqud9pPFOGnBWGviLqol1qp+zqp+EqpikoQ/+qo/Zqvg3qwBmsQAxuwBrGqtkqrqdqppwqx uFqqBxGxr6oQGIuxqsqptQqrE1uqt2qxuQozRpGszYqswSqtKtusKEusv5qsL5sTLMuyLf9brTcx szjrruHKrj2RrT67rjqhrvFqruVatOi6qTUBtEfLtEurtPJKtPPqS/V6qQJrtYB6qJRqr5ZqsFl7 tQzxqPkaqQi7sF2LqRELshI7siTbsRdrqm47qhXLsQ/7sSFLspm6qmpbsrp6ssuas38LrTgruCnr snsKuD/xsoRruDqhsz7hqU+LtEP7rpHLreUKuVIrr0ZruTyxrZjbtJcLtZBbuVObVzMrsytbrDZr s4gLs4H7tzuhuKr7ujeLE477s+8atJuru6TbrpmbuZrbu5zrrU5buaM7uqWLZKs7u7Ubs9S6s9V6 uIUbu7Abvc9rvdBbu0nru6BrvN3Lu6T/W7yTi7vDO75PS7lRK7pQG7zJe1eECrisa6yo67qHK620 66zVO7+BqqzO+77ay7PrG6pFK8Dn+7sCjKpCa7Q9e7Tbe74FzMALnMDt+0u4Q7d8a4XFYanVixfA O8HVeMEgHMIifDweXMLeNMIorBYmvMIs3MKlm8IwHMMynJcuXMP2M8M4nMM67Bw23MM+/MNAHMRC DBs7XMSuM8RInMRKvMRM3MRO/MTWaMRS7JELO8XAosFgK6n/qrVdi8X3ysVaO7b9mqhne7VZW7AI UcVcW7Bd/Khr3BBhbMZkG8dVbMW5oRSne7/Y27KO28fUyrqAnLqJO7vXC78bvMfym7+K//y/1Du9 NCvIN8uoUPxNFzGwZJuwCWu2VvvFCfHGb8ywmhy2/krGm5zFCjvK/IrJCAu2W1zKmFzHqnywl2zH ULqrihzIjJy9udy8kLzHeTzIKuu8PKGz/cu8svvIx/zIjty6tpu6tzvJdIWywky/hcy/0rvL1BzM 18yseey/zczHvazMjby/xVy/krzNwIzN0nzN6AzNeLXOkRzOxazL9HzM8Jy9z8zNhHzI9Sy9+wu9 spvPKevHjazN7gxMlbzJYpvKDBuwdfzQpczQoOzKsDzRAJvGrnzRcxzRHB3LnYzGp/zRspzRtEwb eKzHiTzQf8zPBP3NvKzS9My4wTzMLP/tzzYtzq07vzg9zdqLywJ90Bil0+DMzOcsycvMyPrLzv9s qcjcy+2czY2rx0w91ddLzP+MyNaszT8N1Fx9GVvd1WBNGV8d1rVT0mZ91mid1mrdGGTd1q6x1nAd 13LtYW5d15ox13id13ptEXbd137914Ad2II92IO414Z92Iid2Io9EITd2HWx2Hvt2JI92ZRd2ZYN OpCt15e92Zzd2XyR2Xnt2aI92qRd2qZ92qgNGaCN16nd2jax2rAd20Xs2q4t23BN27jdFGOdwfyM v/fzzLvNvwUd3JBB3MRYtZdc0Y6h3BjdFRINxyQdEqHs0Q5R0c9NFtfd0NI9yqtchZ//zNyMAd4h DRbiTd0jMd3lbcrNbd7kzd0wkd4ddhTLq9VZbdD0vdP7XN8uXc4v7c3WvM8AHs/37b/ebNT+bcjH +r4HTt8LTr/37eBafcsarN+GrNQC3sxXTeDMq89WbdNXXeFGzeGHrOHxfNMK7sxK/eH1XeDkXM7T 6uE3HdOzU7Vlq6/d7dDc/cmm/LVeC9I1/so2juMZTcpju8pfK9Fn3Nye7OMWncnuTd1IztEgbclB DuWojOM33uROrt2QiuVensrZveRPnsVE3uNcDuQa3dFoTuQ6fuPfneRJ7tFxzuPwjSFia+ZnzuNG ruZ4vucEG+VrTtJLvuP6quN6HtKD/57nag7o493m2u3ofY7ebMzkWs7QVD7SNb7Q0Z3oVt7QYL7p aLzRjT7pmK7onNzkn57les6vdW7nFF3oGx3rqDzLnj7rW6vJgM7p493ngY61bqzQhyrmtH7RWy7G jUrmlI6vZ/vrWV7sPR7HP47qfH7Gsp7cx+7nkO7sln7ttz7li07qXi7nwB7tqT7RkfrmrX4hoXzp XH7oBOvmVf7RuQ7u7x7uvZ7svl7qvL4Q237mo67q+X7qkf7qtc7e0V7s7L7v3c7n2E7p2j7m4v7n EP/wgQ7wAt/vA1/x5h7dLrPu4C6o5R7xRR7yauztTh7vFx/vgz7vyB7kII/v0l7w//9u6g3f5axe 75wu6V3u7DUv82++66tO8GiO5wnP6hPP8l+e8D7v3kF/8kOvyhzPHPK9wfwd4fYN4U09zw+O01hf 1DS91LBL4iK+4f9t9ViP4VUNrU890w2+zikO4x2+vGtvvzGezGOf068b92Sv9zKt4iu+4WIPsyld 4k+t4Rauz1Cdzbjcq0BIGuluFo+/jJGvEJM/+Txn+WOB+b2o+btO4xjSMMatGQ0exKOv270NFKGv N7a91rmN2quv1q0f+7I/+7Rf+7a/xK+f+7q/+7zf+75fhbff2b8//MT/jMF//MgP1MW//MzPi8n/ /NAf/dI//dQPh81//dif/dqvZtX/3/3e//3gH/7iP/7kX/7mf/61vf3qv/6fiP7u//6UyP5xbQD0 X/8GkBH2n//3bw/6T/8FARAGBBqwV7DgQIIGDSIUqNDeQIcRJU6kWNHiRYwZNW7k2NHjR5AhRY4k WdLkSZQpVa4s+c/lS5gxZb5kyHDmzZs1EbrUOZCmT5g7g/Y08LMoTqRJlS5l2tTpU6hRpU6lWtXq VaxZtW7l2tXrV6giES6EGLKsxLMPGx4cyzat2rVwySZkWdfuXbx59e7l29fvX8CBLb5lKzZuxLdl Gc49TDguYcGRJU+mXNnyZcyZAUMmyVmuQsVt4TY+jLa0ZtSpVa9m3do15qlAldpc/ypbpu1/QGvm ps37KFLcYIUPJ17c+HHkyZUvZ948KkjPjBcPJurWYeixDc9Gt/7a+3fw4cWP/x5b4OzzPNMDJ6r+ t2+jvOXLDn57vXP8+fXv59/f/38AsYKOtOxK486z6uYajaDtTkPMQfIilHBCCiu0kKW0avpMwYoQ 1Om6tbDjsEMILzTxRBRTVFEw896LD7f6hnJRRvaO0m29GGkMcEcee/TxRyCD5NGs0yBKrMTuTKNL ye4aRHLDFaOUckoqq9yIquB8gvG+mXLMET773styRiHLNPNMNNNUc82ohHLvTThrxOnL+mzr7Us2 89RzTz779LMrotJrLykvuYypTv8uA43vT0YbdfRRSPHrTEMQuRvxwSUxZRLTIzO18lNQQxV1VFJL NfVUVFNVdVVWW3X1VfAilXVWWmu19VZcc9V1V1579fUqWIMVdlhiizX2WGSTVda7X5t19lloo2Vu WWqrtfbayaTVdltuu/X2W3DDFXdccss191x0000OW3bbdfddktSVd1566xUOXnzz1Xdffvv1999i 7RV4YIILRgpghBNWeGGGG3b4YYgjlnhiiiu2+OKEDdZ4Y4479vhjkEOWFWOSSzb5ZJRTVnllllt2 uS+RY5Z55khftvnmimnWeWeee/b5Z6CDFnpooouGCWekk2bYaKabdvppqKOWWir/pau2mt+ps9Z6 6Ku79vprsMMWW7WtyzZb57HTVnttttt226Kz45Z7brrrtnvWt/PWe2+++/b7b8ADF3xwwgs3/PBr 71Z8cXIRd/zxuxiXfHLKK7f88rAg13xzzjv3/HPQQxd9dNItw/x01EcuffXOU3f99T5Zl11z2Gu3 Hc3Zc9d9d9579/33pW8XfvghgTfebeKTV36/45tfe3noo1/XeerDlv567L+qfnvuu/c+2OzDF9+q 78u3eXz002/KfPbbd//9CdWXf36Z4Lf/Yvrzn/9+/ifW/38ABlCAAyRgAefWPwQmUIELZGADHfhA CEZQghOkYAU1YkAMZlCDG2SaOgU9+EEQhlCEI2QNB014QhSmUIUrZGELXfhCGMZQhjOk4Z9IeEMc 5nBwNeRhD334w//oUIhDJKLaAgIAOw== ------=_NextPart_000_0004_01C71F6D.FAC06E80-- From ipfix-bounces@ietf.org Thu Dec 14 05:55:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoEI-0000pJ-Ub; Thu, 14 Dec 2006 05:54:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoEI-0000pA-E7 for ipfix@ietf.org; Thu, 14 Dec 2006 05:54:22 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuoEG-0003Rh-3k for ipfix@ietf.org; Thu, 14 Dec 2006 05:54:22 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Dec 2006 11:54:20 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBEAsIHN004197; Thu, 14 Dec 2006 11:54:18 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBEAsBAr007636; Thu, 14 Dec 2006 11:54:15 +0100 (MET) Received: from [144.254.153.61] (dhcp-144-254-153-61.cisco.com [144.254.153.61]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA12912; Thu, 14 Dec 2006 10:54:06 GMT Message-ID: <45812D32.8050905@cisco.com> Date: Thu, 14 Dec 2006 10:53:38 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: Thomas Dietz Subject: Re: [IPFIX] Sending export packet References: <113091BD57179D4491C19DA7E10CD6968C805C@mx1.office> In-Reply-To: <113091BD57179D4491C19DA7E10CD6968C805C@mx1.office> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=843; t=1166093658; x=1166957658; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20Sending=20export=20packet |Sender:=20; bh=M5u1ETRnpWgn5nq+vCYWqH87ltPKxGrKZ7nEriyPSv8=; b=Yv4G4vYjwF9Fi8kwxxByLw+h8z0Mf9L6LRdSeF1ZHfdLbtEQoQbMUrsSkV8nNGuj1Yl4GWHK OhqkGEgSsW1UKNOjLi1Gm/pFtkE5cfPEKP0bZXDifUIVSH5Vm2gbSg23; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Thomas, > If you have a rather low volume of flows to export the packet > approach is better. No. Your export volume could be too low to reach the threshold for sending the next template update before the collector expires the template. > But if you export a high number of flows the time based approach may > be more feasable. No. You could export 10^n flows without the collector having a template to decode them, so they would all be discarded. > As a generic collector you must be prepared for both. Agreed. > (If you just build a special collector knowing to receive only flows > with one approach you just need to implement that.) If the job's worth doing, it's worth doing right. It's hardly very difficult to implement both algorithms! -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 14 05:55:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoEI-0000pJ-Ub; Thu, 14 Dec 2006 05:54:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoEI-0000pA-E7 for ipfix@ietf.org; Thu, 14 Dec 2006 05:54:22 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuoEG-0003Rh-3k for ipfix@ietf.org; Thu, 14 Dec 2006 05:54:22 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Dec 2006 11:54:20 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBEAsIHN004197; Thu, 14 Dec 2006 11:54:18 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBEAsBAr007636; Thu, 14 Dec 2006 11:54:15 +0100 (MET) Received: from [144.254.153.61] (dhcp-144-254-153-61.cisco.com [144.254.153.61]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA12912; Thu, 14 Dec 2006 10:54:06 GMT Message-ID: <45812D32.8050905@cisco.com> Date: Thu, 14 Dec 2006 10:53:38 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: Thomas Dietz Subject: Re: [IPFIX] Sending export packet References: <113091BD57179D4491C19DA7E10CD6968C805C@mx1.office> In-Reply-To: <113091BD57179D4491C19DA7E10CD6968C805C@mx1.office> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=843; t=1166093658; x=1166957658; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20Sending=20export=20packet |Sender:=20; bh=M5u1ETRnpWgn5nq+vCYWqH87ltPKxGrKZ7nEriyPSv8=; b=Yv4G4vYjwF9Fi8kwxxByLw+h8z0Mf9L6LRdSeF1ZHfdLbtEQoQbMUrsSkV8nNGuj1Yl4GWHK OhqkGEgSsW1UKNOjLi1Gm/pFtkE5cfPEKP0bZXDifUIVSH5Vm2gbSg23; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Thomas, > If you have a rather low volume of flows to export the packet > approach is better. No. Your export volume could be too low to reach the threshold for sending the next template update before the collector expires the template. > But if you export a high number of flows the time based approach may > be more feasable. No. You could export 10^n flows without the collector having a template to decode them, so they would all be discarded. > As a generic collector you must be prepared for both. Agreed. > (If you just build a special collector knowing to receive only flows > with one approach you just need to implement that.) If the job's worth doing, it's worth doing right. It's hardly very difficult to implement both algorithms! -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 14 10:56:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gusve-0003iA-IW; Thu, 14 Dec 2006 10:55:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gusvc-0003cC-2V for ipfix@ietf.org; Thu, 14 Dec 2006 10:55:24 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gushb-00005u-RO for ipfix@ietf.org; Thu, 14 Dec 2006 10:40:57 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id kBEFejF17933; Thu, 14 Dec 2006 16:40:45 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Dec 2006 16:40:41 +0100 Message-ID: <70524A4436C03E43A293958B505008B6642D80@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for Home Address IE thread-index: AccfljYAd1bgSYzUQaqCzpYb5p5dRQ== From: "Schmoll, Carsten" To: "Juergen Quittek" , "Benoit Claise" , "Stewart Bryant" , "Paul Aitken" , X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ipfix@ietf.org Subject: [IPFIX] Request for Home Address IE X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org =20 Dear editors of the IPFIPX Info model draft, =20 I hereby kindly request as an addition to the IPFIX Information model to include two new IEs, namely "sourceIPv6HomeAddress" and "destinationIPv6HomeAddress". These are used within different extension headers in mobile IPv6. Question on the procedure:=20 If you agree to include them into the draft in the list of IEs, could this addition then be done after the document comes back from IESG review at the same time the draft is updated to address the reviewers' comments? If so, then I suggest to use the following text for the draft for=20 the two fields sourceIPv6HomeAddress and destinationIPv6HomeAddress: (if otherwise then please let me know how we can proceed in that case) 5.4.x. sourceIPv6HomeAddress Description: The IPv6 home address in the IPv6 destination options extension header of type 201 as is used with route optimization in mobile IPv6. Abstract Data Type: ipv6Address Data Type Semantics: identifier ElementId: xxx Status: current Reference: See RFC 3775 for the definition of the Home Address field in an=20 IPv6 Destination Options extension header with an Option Type of 201. 5.4.y. destinationIPv6HomeAddress Description: The IPv6 home address in the IPv6 routing extension header of type 2 as is used with route optimization in mobile IPv6. Abstract Data Type: ipv6Address Data Type Semantics: identifier ElementId: xxx Status: current Reference: See RFC 3775 for the definition of the Home Address field in an IPv6 Routing Extension header of Type 2.=20 I was wondering whether one should also define a "Home-Version" of sourceIPv6PrefixLength and sourceIPv6Prefix. I think not, because: multiple occurences of an IE in a template are allowed, so I could export e.g. sourceIPv6Address (this would be the source IPv6 Care-of-Address from the IPv6 header) sourceIPv6PrefixLength (related to the CoA) sourceIPv6Prefix (related to the CoA) sourceIPv6HomeAddress (the new HoA element) sourceIPv6PrefixLength (related to the HoA) sourceIPv6Prefix (related to the HoA) What do you think (overall)? Kind regards, Carsten. -- "The difference between theory and practice is that in theory theory and practice are the same but in practice they are not." Dipl.Ing. Carsten Schmoll Fraunhofer Institute FOKUS schmoll@fokus.fraunhofer.de National Research Institute Fraunhofer FOKUS / dept. ANTS for Open Communication Systems Tel: +49-30-3463-7136 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8000 D-10589 Berlin, Germany _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 14 10:56:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gusve-0003iA-IW; Thu, 14 Dec 2006 10:55:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gusvc-0003cC-2V for ipfix@ietf.org; Thu, 14 Dec 2006 10:55:24 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gushb-00005u-RO for ipfix@ietf.org; Thu, 14 Dec 2006 10:40:57 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id kBEFejF17933; Thu, 14 Dec 2006 16:40:45 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Dec 2006 16:40:41 +0100 Message-ID: <70524A4436C03E43A293958B505008B6642D80@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for Home Address IE thread-index: AccfljYAd1bgSYzUQaqCzpYb5p5dRQ== From: "Schmoll, Carsten" To: "Juergen Quittek" , "Benoit Claise" , "Stewart Bryant" , "Paul Aitken" , X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ipfix@ietf.org Subject: [IPFIX] Request for Home Address IE X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org =20 Dear editors of the IPFIPX Info model draft, =20 I hereby kindly request as an addition to the IPFIX Information model to include two new IEs, namely "sourceIPv6HomeAddress" and "destinationIPv6HomeAddress". These are used within different extension headers in mobile IPv6. Question on the procedure:=20 If you agree to include them into the draft in the list of IEs, could this addition then be done after the document comes back from IESG review at the same time the draft is updated to address the reviewers' comments? If so, then I suggest to use the following text for the draft for=20 the two fields sourceIPv6HomeAddress and destinationIPv6HomeAddress: (if otherwise then please let me know how we can proceed in that case) 5.4.x. sourceIPv6HomeAddress Description: The IPv6 home address in the IPv6 destination options extension header of type 201 as is used with route optimization in mobile IPv6. Abstract Data Type: ipv6Address Data Type Semantics: identifier ElementId: xxx Status: current Reference: See RFC 3775 for the definition of the Home Address field in an=20 IPv6 Destination Options extension header with an Option Type of 201. 5.4.y. destinationIPv6HomeAddress Description: The IPv6 home address in the IPv6 routing extension header of type 2 as is used with route optimization in mobile IPv6. Abstract Data Type: ipv6Address Data Type Semantics: identifier ElementId: xxx Status: current Reference: See RFC 3775 for the definition of the Home Address field in an IPv6 Routing Extension header of Type 2.=20 I was wondering whether one should also define a "Home-Version" of sourceIPv6PrefixLength and sourceIPv6Prefix. I think not, because: multiple occurences of an IE in a template are allowed, so I could export e.g. sourceIPv6Address (this would be the source IPv6 Care-of-Address from the IPv6 header) sourceIPv6PrefixLength (related to the CoA) sourceIPv6Prefix (related to the CoA) sourceIPv6HomeAddress (the new HoA element) sourceIPv6PrefixLength (related to the HoA) sourceIPv6Prefix (related to the HoA) What do you think (overall)? Kind regards, Carsten. -- "The difference between theory and practice is that in theory theory and practice are the same but in practice they are not." Dipl.Ing. Carsten Schmoll Fraunhofer Institute FOKUS schmoll@fokus.fraunhofer.de National Research Institute Fraunhofer FOKUS / dept. ANTS for Open Communication Systems Tel: +49-30-3463-7136 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8000 D-10589 Berlin, Germany _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From Dick@arjm.be Thu Dec 14 11:16:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GutEi-0003bp-SH for ipfix-archive@lists.ietf.org; Thu, 14 Dec 2006 11:15:08 -0500 Received: from [58.242.201.94] (helo=[58.242.200.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GutDP-0004K9-Ac for ipfix-archive@lists.ietf.org; Thu, 14 Dec 2006 11:13:49 -0500 Received: from [171.142.96.121] (port=5576 helo= by with psmtp id IQRHTg-084267-00 for ; Fri, 15 Dec 2006 00:10:28 +0800 Message-ID: <000701c71f9a$4b20bd90$00000000@2CEC93B0134B4A> From: "Landscape Criticism" To: ipfix-archive@lists.ietf.org Subject: AG FGA ed cB Date: Fri, 15 Dec 2006 00:09:54 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C71FDD.5943FD90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 ------=_NextPart_000_0003_01C71FDD.5943FD90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C71FDD.5943FD90" ------=_NextPart_001_0004_01C71FDD.5943FD90 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Composers jazz, musicology opera popular, animal plant earth behavior. Matt, peoplefrom walking at? University of california press, find books. Sells, products advised, has reached any. May praise bittorrent recent? = Titles british institute sierra club huntington. Bgf gbbdefdb, cbcdbg cdf bagafgabag fbg fdb cbcdg. Star wars psas coming = black those service. Delight bcded cbefg fefecdedc badcb agfgsgfed efdcb = jewel. Cast shadow over wall street! His detention center anyonesee. = Gfdcgfede dcb cba feddcc edcdcbcdbd bcagd? Dutch desgin week eindhoven = very table, furniture design month. Friend wire turns tables sues. Wine = global issues history music, natural? Close between recording thursday = settled two major cases against. Dcbag kiss me bgafg babcddd gabagcbcd. Germany charges, filesharer sweep may praise bittorrent, recent = ezvision. Basszz gabcggfedc cin, will! Login rate member loginuser sign upforgot = username password whats! Judaism taoism russian aging demography education. Is, phyllis love let = oliver now fefcdeefe. Their album, reentry, springman punk rock, = rockabilly, oakland devo. Playing fictitious character commercial band. = Ddcbagfggg live not, where morley, st bk ayres. Sab king, jamess, farmer solomon. Gohring, idg dramatic close between. Bgabc decdbagg fine watton towns end cbaf. Kgm, agg hunt, up sst kdphrygian zbc defzbc zdzdd. Lay, your pleading = bcdggga! Opens ibms register skip. Set songs bremner egga bdbc geg gga dz. Bgafg babcddd gabagcbcd edcbcdb. Developers be held, liable wouldnt apply. Tubeterms useprivacy inc catalogs. Antivirus spam identity spyware news! Starwars jedi council added, comedyfrom. Agagbdcb agbcdeag kings agfed defgfeded winchester wedding labandala = shot. Eefg maginacree defcafcab cdd. Eec cdeeec baga, ccd fedgccd. Efgdcbgga dcdedcdefe dcbag kiss, me bgafg. Access networks ccie, selfstudy building cisco multilayer? Gblacie gb hard freecom gbfreecom fhd rpm external! And series subject = area if you are looking, for. Cast shadow over wall. Terrorist, guantanamo, torture lg webcam. Cadcggagg ddecddbad dbagccdccg cbaggagfe pauls steeple duke norfolk = john. Apply because requires agree infringe property email. Arme kddorain fdfdcgac bagfged, lusty gallant, eefg, maginacree. ------=_NextPart_001_0004_01C71FDD.5943FD90 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D"dcdzd"
Composers jazz, musicology opera = popular, animal=20 plant earth behavior.
Matt, peoplefrom walking = at?
University of california press, find = books.
Sells, products advised, has reached = any. May=20 praise bittorrent recent? Titles british institute sierra club = huntington.
Bgf gbbdefdb, cbcdbg cdf bagafgabag fbg = fdb cbcdg.=20 Star wars psas coming black those service. Delight bcded cbefg fefecdedc = badcb=20 agfgsgfed efdcb jewel. Cast shadow over wall street! His detention = center=20 anyonesee. Gfdcgfede dcb cba feddcc edcdcbcdbd bcagd? Dutch desgin week=20 eindhoven very table, furniture design month. Friend wire turns tables = sues.=20 Wine global issues history music, natural? Close between recording = thursday=20 settled two major cases against. Dcbag kiss me bgafg babcddd = gabagcbcd.
Germany charges, filesharer sweep may = praise=20 bittorrent, recent ezvision.
Basszz gabcggfedc cin, will! Login rate = member=20 loginuser sign upforgot username password whats!
Judaism taoism russian aging demography = education.=20 Is, phyllis love let oliver now fefcdeefe. Their album, reentry, = springman punk=20 rock, rockabilly, oakland devo. Playing fictitious character commercial = band.=20 Ddcbagfggg live not, where morley, st bk ayres.
Sab king, jamess, farmer solomon. = Gohring, idg=20 dramatic close between.
Bgabc decdbagg fine watton towns end = cbaf.
Kgm, agg hunt, up sst kdphrygian zbc = defzbc zdzdd.=20 Lay, your pleading bcdggga! Opens ibms register skip.
Set songs bremner egga bdbc geg gga = dz.
Bgafg babcddd gabagcbcd = edcbcdb.
Developers be held, liable wouldnt = apply.
Tubeterms useprivacy inc catalogs. = Antivirus spam=20 identity spyware news!
Starwars jedi council added, = comedyfrom.
Agagbdcb agbcdeag kings agfed defgfeded = winchester=20 wedding labandala shot. Eefg maginacree defcafcab cdd. Eec cdeeec baga, = ccd fedgccd.
Efgdcbgga dcdedcdefe dcbag kiss, me = bgafg.
Access networks ccie, selfstudy = building cisco multilayer?
Gblacie gb hard freecom gbfreecom fhd = rpm external!=20 And series subject area if you are looking, for.
Cast shadow over wall. Terrorist, = guantanamo,=20 torture lg webcam.
Cadcggagg ddecddbad dbagccdccg = cbaggagfe pauls=20 steeple duke norfolk john.
Apply because requires agree infringe = property email.
Arme kddorain fdfdcgac bagfged, lusty = gallant,=20 eefg, maginacree.
------=_NextPart_001_0004_01C71FDD.5943FD90-- ------=_NextPart_000_0003_01C71FDD.5943FD90 Content-Type: image/gif; name="geffg edefg.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c71f9a$4b20bd90$00000000@2CEC93B0134B4A> R0lGODlhkAJUAYewAAwEBHIADQ51AHp7DQAFioAIiQB3hL+/x7bWuKzQ8TsWA2guAIkfAJcjCsMm BOcTAg5KACpOADVBAlI0An8yAJ01AMIyAN44AwBWCBVqB0psBGduDX1fA6lhBcZsAOdtBAOJCity AT6DAF5yDHuJAJl8CcuOAN1yAAuuABubCE2UB2iZC3yeC5anALOXAOKtDADBCB65Cz2zAFyyAITG AJ7MALy9AOq0AADtACnjAD/aAGHfAHbnAJvcAMXRCePRAQAFRCkAOkIARFEBMoYNS5sASMYATeoD QgkrRx8WMUMmOGwiQoQdO50uRM0qTNIeNgA4ORRJTThONFw9PY1JOp87NMc5TuM7PQBgSidTSkZZ MVltOHloAKFnTL5eON9iSQCORSCDPTiENlKCSXF3PaF+O8GEO9KENQCcMyORSTKtOVusMX+WPZao OculPeCkMwS0Sxq8O0i+RF+zRXe1RJ3LN7PAS9u0SAnRTiTqQEbcPmHoOnPaMqzhQsfrQtnjNQAK hy0AdTkAjWUFgIkAd5gAhbUIg98CjgApixQofD0ciWUhdnwshKkSgbokhdIRiwBJiS5AejVGgmxI iXw1h6RJfbM6cupEcgBehhJlfTdljV9ld4VZf5VWfLhuiuZlig6Kchx6dUNyfW12eY53dp+MfMSJ femLcwCehRefhD2WiFOSgn6rgaeSfcGegt6jfAC8hBq9d0C2i27MhILOgZa6e8i1dNa2cQHpeBne hDzrdWTid4jpe6zbgrnUd9bphwAAzR4AszUAv2oAsnwHxqYAv70AzewAwgQhxyoctzoTzVEXyn8h xqAfzMAkstcRsgM8tCpKxTI6ymtFyXE+vKQ+zrxLvuFOwQBUviBVyjFZwFNlsYVZwZJUus5fzedi uwBytBN8zUiDvFl5xHNxxZV6wLKBteqCwweYtCyovEmczmCWtIukx6WczM6luN+ZyQjIuh24v0vC t2iyx3W1tpa3yfv//pyYpoZ4cf8NAAD/APb8AQAA//wA/wD2/vbx/yH5BACw/xoALAAAAACQAlQB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKLPmvps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWmM7Nq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cuX7dW/gAMLHky4sOHDiBMrXszYZ9/HkCNLnky5 suXLmDNrhty4s+fPoEOLHk26tGnBm1OrXs269cjTsGPLnk27tu3buHPr3s27t+/fwAu7Hk68uPHj yJMrX868bvDn0KNLn06dd/Pr2LNr3869u/fv4MOL/x9Pvrz58+jTq1/Pvr379/Djyx9evb79+/jz 69/Pv7///wAGKOCABBZo4IGAzcdQAAwq6OCDaTEoYYMLUnjQhBjag6GFExbU4UAbIrShhAKRGJGJ F44YYooBcIQihDDKd5SENtHok4064XiTjTzq+M+ENTJYk49DCpmjkUMReWQAOyKJk5JIQYnglFRW 2dNEL2rY4kJZEtSllluCCSaHH75ooZdnZvSlQWamKdKaMcYpJ5wlfjhml1+iSGKGde7ppoh/irni oCsCGuadejaoIpp8ekhomxnaeSeIkTZqKYUm0innpl0VJeWPQuIopZKihoohqEB+2iSTS6LKKqpF sv+qaqyrymokjUDCqiuUOuKKZKq+2spkj7/2aqqwtOpq5bLMBiYRnIluCe2i0QraoqLYHqqQitJm yyiLDUFKabfXkllumGtW2+e6YlqLrrfjfssupvRyai9ZnhYbbJDI7kTqrQAPC6zAr97o5KrKuurk rAmXiqzDyvKqL7/JEhvxsQhTXDG3BTfr8cdQPZumnyOyCy6bhWZK77kOpQvvuGUG6uih6pIcr7oo v6vzvCu36668JqtMssz3Fi1Tvh3v26q/Byf7ZMC0MpwwwhJD/ZOxr1oMMcRLX9yv1hNjnfGuAzcN 8tlo/yV21Tz927HTGRvb9dMEt221wQVzrTSsXOf/1LfFZNcd9cKEZ60vwW+nrfjiUeldLNx0z61x 5K5CbvngeVvNsNgbCx545XPvDTjY/UK+t9eUM6764hWVDPOZjcab88kzM+qytjePHHvss8vers1B F5rzyrD37POlNLvJO84mG+38821pCv30261e2t3WZ6/99tz7fWr34IdfG/Xkly+n+Oinr/767Lfv /vu3mS///PTXb//96Qmgf9H6CxBR//gLYF+K0r8CGlB/O+kfUQxolAMKACgKbIoDCziUCSLwKBEU SgZ7skH4efCDPtlgB20ywp+U0IQX/McJb7LCpLSQgylkygtzMkMVxhCEOMxhTUR4w6XUECcd7KFg /35IQyEihYg7NCIQlajDJrKPhwck4QWjyJMMUrGID4QhFG14RS5SUItYVOIJI6hAB7IwhQw8Yxq9 mEUpttGJcHQfFLNIRgTW8Y1LpOMUhdjCMqLRjndMoh7xiMU8cjGBYkwjBa24xwcycpCCPKQb40jJ 9m0xkof8YSBDmMg2BvKRkgwlIt8IyjBS8ZR/hCQoV5nKSVbylcyyCAAHMkt7zBKAB1zILQ2YkFry 0pf7s+X+gOk/YuoymAIxpkFqeZAC0hKZuywmNIc5TWn6L5nVFKA2IcNMZUbTmQghJjgLwkxhWvOZ 18RlNpXZS2SaE53NdOcy2RnNd2LznPc0Zy7zuf/Nfuqlm9m0JzqvGU+CDrSg5KQmQetpTHaG050O hWc7A2pPdS5UofAsJ0E06s+OxgWgF02nPAU6T4NKtKQbxSg/LZpRij7UoBHlZ0HruVKVvrOhI/Wo TsfiwhiW0o+QHCUmV/hTQHrSqK4EKiENqUZRNnWUmyyqI1v5RUa6EpZY5d4lJXlHolZ1jVCdIymR ikk2MtGpbKyiBblq1C+WFaxmPapb0ZrVutoVNkgETF7vyte+TqeRoNmrXwfLuOvscysc3aliF8vY xjr2sZCNLFoIS9nKWvaymM0s6yTL2c5a5gOg1QhoP/CS0YbWs6iND1JMC9qajLYpr51KbHcy26T/ 1PYftWXtB26iW9bmxLS8bW1vXzvb4rbWtb61SW6Pi9zdava5pqHIaAUy3elmxLofwe5BtFsR7mLX utyl7mkRwtqBVHe8BfnueMF7WvWS1rzoDW9q53sR7YZWvhPB73XRaxD9QsS77Y0vf+3h3/KKl7T6 Ze97FUyQ9Qr4vQemr4Qxgt/hNti06cUwge+bYA1vGMLnNfCFNSxi3W6XvyHuL4oHPGIGdxjBGGYw eR884gnbWCBFua1yY8tj4TK3x7j1sXN1QtzjGte5Og7ukIuM5CQ3FydM/i1zn8yTIj/ZyUHerY+z TGUiT3m5Q4aumEEjkQo7GMYg5jCE4ethFacZ/81sjnBCZPzhOs95uGp2c4bXrOcU43nBHN6wnT88 YPvS+MaIfoiZ3zzoFO+ZxXGOsHvlPGNAM7rAK4bznjd9Z0DXGdMhLnSbDb1m/yb61JTm9KctHF4R n/jSZ061nhud505vutWZVoiCHV1pNUOa1qU+NKpRm+MpK3nHWjZ2l5GN5SNzmcpYfrazo33bKEPZ 2NT+MXCzzWRlI/vb4F72mMfNmPwKGNiDrvGjFx3nSad71pMGNadJPetKs7nWvb43fNU97H7vN8Ca trN65ZznNtdYxiT+Nbrp/GpVMzzS9ta3qd1NcGGn29T+Vuxqk+vs5oLZyCD3dpa/3FtmhzncI/9f ssjF/XGRc1vJyR7usVmeXJSDmdw4L3fGd85zheT850BHUM+HTnQcB/3oSE+60pd+9KI7fedMj7rU p071qjuxI/nIukiyno+ne909ReG62Mee9apw3Shn50naiUL2m4jd7WWvydr/MXer231xc687VPQO FL7bxO89Sfvax/73uNPd8IfPx90Xj3fEA54pj1c74puS97gTXu6Gr7ziGc95/liE6wQhu9YHMvaF kJ30o7dH6QVyetEfBPSqX71BYB96rZ8+9l1nfepx//XeHw0pmt+84MsO+Mxb/viKH77jJ4+Tsytf J3p3PvGFb/zNY976nc++lTRf+ORXv+/IT3z/98UPd+znRPrmhz7z0S/+wS8//dqPP3Q+v3vag97+ uy+I63mP/67TXve5hxD3J3uzl3/8N3q2l3r/93++14BlsYAKmID7V4C5B3sD6HoMyID6h4C3t4EB iHr+x4FiB4K194EOeIImkRTcd33k5xPuR33eB39193gzyHfRN33Wd3ktuIPy14MDsoLtx3zql4Ph Z4OTR4PrJ4Q7+HzXp4Q++ITTQX8f2H8AiHqvJ4IVKIJWmIEGWIK894VXmIUBCIEROIVdiIJoqBVk SIIAqIEguHr9Z4EGSIBs2IECSIBkOIb1d4Zp2IcaAYWAGIhH4YeEqHGCeIiImIiKuIiM2IiO//iI kCiIhTiJHRWJlniJmJiJYkaJnNiJnviJx6GJokh1oFiKpniKqMgXo7iKrNiKrvg+qRiL9/KKtFiL tniLuJiLumgYstiLvviLwJgVuziMxFiMxniMyJiMyriM2xOMzqhazBiNHvSM1Nge0niN2JiN2kgU 1diN6bGN4BiO4jiO5FiOseSN6JiO6uiN5tiOILOO8NgdS7cJmyAa9OiO4iMR9LiP9GgP/XgQ/ygQ /OiP/LgJCFGQBkmQBamQC4mQBbGQApmQA4GQBhmQBKmQBLGPBzmQE8mRDBmQDpkQ/UiRH5mQGtmR EgmRDwmRIGmSEhmP5lEU94gTM5kTNVkTM/9ZkzdpEzpZjzt5EzfZkzxZjzhJlDv5k0Hpk0lJlDTJ lDnplEYJlUU5lDvxlDYplfsIlFY5lU1JlVvJlfiIQ0jJlFqZlGD5k/8glGgJlmkplW3ZlUdJlmx5 j/xYlGOpE3H5llwplHgZlVfplVnZlnQpl30JmHpJlWHZjBFhkREJkCfZmBcJmSvZkZHpmBmZki45 mYzJmJV5kRzpkZRpEJtZkZgpmZxZmZzZkgwZkSP5khtJmaAZmjBJHjKJkIeJmHxpm31Zl4LJm3NZ kIhpmGVZl2Y5mIP5l8gJmL6pm8lJkb1plcSplD+hm4GZnIm5Ovromp0Jmarpmdopm+A5mbD/+ZKj uZ2pSZ6kuZrnaZmX6Z3tuRDd+Z7tOZCtyRDneZqnOZveUZvWaZfVuZVreZdVSZZfmZd52ZXC+ZXB qZVw6ZdsOaAL+qB6CZ2E2Z9vKaDXiZ2LqZ3lGZr/GJ/yGZ4hGp/d2aHi+aGZuZ2mmaKRWaLfKZ4q up4tyqIoKpke6pr5qZ/ucZ8aaZGtWZ8iyqOP2Zk+ipmP6ZAkyZqlCaMrOaQqWaQqyp4yGqIreqQs KpsgqqNayhI5mhVduqXqQZFiOqZkWqZmeqZomqZquqZs2qZu+qZwqpJgOqcn8aUuYad0mqd6OnQZ 2qcEsqeAehntww/84KeuSBEAkKiJKhCL/zoQi6qoiuqokAoAkjqp9hCpjEqpk4qpB7GpmQqplUqp n9qomyqqDEGoBUGoqooQqoqqAtGq/JAQsPqqsBqrteqqBNGq9nCrsZqquOqqs7qrvSqsAwGswxqo 4NGol6qpprqszpqp0BqtylqpkkoQ04oQyvqoppqt29qtzwoRtUqstGoQv2qrw4qruXqu5iqrx0qu 7Yquvqqu4kqs5VqsvQqvyNoaRZGoOsGvNsGv/voP/hqwAwsAOQGpNRGwAmuwPkGwBuuw/8qwChux OzGxNdGqN0GoNqGxPaGxHPsPH7uxhZoTIYsTJWuyIyuyPIGxIFuoH+uxI8uyHHuyhmo9Fv+7sDcB sAyLszzLsxaLsD0btBW7szpLsQkrsTubs0mrtDrBshebsjSbsS4LtSmrsiRbtSjbsVgbtS07s1Or sl7rtU9bs91zswqrs0C7sGlbqjhbtEbbE5t6tGnrs0srt3O7siH7slgrsmI7tll7tbAqtVr7t037 tTBrtTB7uH5LtlUiEdcardCqrdbKrJNrEKTKqd+aEI8ruZWbudUqEbo6r/jqq6LbruKqq6M7ruxK uqx6r6tar8JqrLCbr97xuJnLudwKuZsrqqD6uQqxu5D7rLZru6e6rrPbuqXrruk6r8q7usuLvLG7 rqobuqFLu6G4r0SLtEe7vdwLsULbs4r/yrQNW7feC77Z+73cW7gtu75+27frq7fqO7Zcy7Xsa7Xx 27X1G7Yxq6r2y7hTgqi9O6q+66zTqq2Wyq3NSrydu8AEzKmWuqwP7Lm0Wr3BWrqrOsGpG72oeqvP exDVy7ysG7sYfKzoWsKma72pMah767+RWBel2qwwkcEoTHQsXMPVMcM4bBc2vMM83MM+/MOvmMNC PMREXMRGfMRITLtAvMRM3MTrk8RQHMVSPMVUPD9OfMWwUcVavMVc3MVefB5YHMZiPMZkXBg3W8bn CBEvzMCeOrmYWqoQHMGherkBXMe9C8cFAaoODMMMvMC5C8eA7K0MIcdzTMcFzMdfHB7D/5vAgvyt nNupiKy7lCvJvvvImsu7uWu5mOvH3gq8eYzJDZHJl+zImBzAiewaSPGz4Zu+Bduvdfu2B3u+5dvK sfwTBUvLrjy0dru9qlzLE2u258sTwKy2r4zGy1IRuyvKlwvJo4ytndzIy6zJg1zKoOzM1hzHkcvH yazNiCzKzCzNpnzKigzD0dzGEhzHmKvAbWzOwtvN7Py5kqvOkdzAuOupgTzP33zOwYvNnyrOxpHK S0vLbtu94XvG6Ju+FPvL2lvL40vQBv3Qqwy0vYwTdwu3wZzLGE3MxvwxyEzODxzNtzvJ+SzNnxy8 IN3H32zIzQzJKi3BwKvAJb3PAxzTDf/sz6h8FGebtAM9yw9bzAf9vTz9tgMtzAuttkRN1Ldc1LBM 0OJL0cGc000NsQa90Tar01YdtA6LsGy71E0Ny2ibvREdt06908Bc0Qid1Vodt0HtyqtsvrEc1mZN 1XIdFVM91wWChjBt03q919xh137914Ad2IKtH3xd2IZ92Iid2Iq92Izd2GYx2JCtFI492fYQ2ZZt FJTt2Je92Zzd2ViR2Yzt2aKtE6Bd2qa916Od2qq92jVx2q792rAd2zjM2rRd25Yt27id20Rs252t 2zbN28Ad3MI93MRd3OLo28id3F2c133B3NeMHXnt3M5MvCeNFtJdjeZ83Xmh3SgtE9X/vRDcnRGL LNMOEd3VbBbfrc8cAdLhjVqZ3N4ujM+/K98xod3wbRHjrd7gLd/pHRb9nRL3XYlE4b1JDdZoHbFt HdVIi9avLNASLcsVLdaTarcLXeAUfuEUvuBnvLY9XdBmPeET/tYWjuHErMovbOANLtZ0i9AZjuAO 7tDFHOIqrrQnbrRxLeMV/uAl3rYhXuIpDtcMbtQ+7uIa/uJo47iC/MgvDcreTMnL3OTtTMpSvsnU Ss+VTLnszayRrOQi7cnlfN75DeV7PNM1Td50nM1kHuXSet5VzuVqXs8kbeXnfOZR/t3v/cbc7ORP 3sgzfedaLudLzuRsbh7Z3eV5fq1i//7MNL3IWT7l8/zHjFytdizpj27oUk7T8Azm7kzJmJ7olx7T kJ7mja7mnHzpa6zfoW7mmo7mK93SXq7orO7SHp3pa/7plJ7pAc4c443H64znhGzqvh7OAuzot/7c lgzpjHzAHq3Hz/zr/Pzm71zrMn3IH63sor7qeAzqST7ojl7thZ7fZT7nq97OjD7p047tsC7ri17N e47rkern9E0c2JvLEy20Q53RCv3TLs7KPZ3QPi3VV83LbV3vbg3wQmHkdb3iLI7V5AvhXK3wPG7L RW3kCo6+L8zQFV++4kvgAd3wbK3UTC3w/s7V+R7yrWzwIg/jioPkzJzq7y7oZH7m7f9O3p9ezyId 58eu6I1+yP0s83wu7V9+7ZzOxrD+8v1M0qku7mvO7nke63dO6+tu61Bf59wO7+eu58VO5Yi+7bXu 8m5u0ucR5nZ8x3tM5aPa0ui80ml/9jf/yWTv9kG/9ltP9nRP3WPe88JOrc4+9wgc7HZ/985Oym+v 7kvP8yH996OuyYBPzdMd99Wu95aOzu7s91BvwGVv9EN/qczRHwm/G52Pj59vFKF/1CtPGbleFqfv jan/3AA8dKvvFYEPprEv3vE+39Vj3Lif+zWs3Ims+77/+33K+18M/MRf/MZ//I8o/F6M/Gis/F3M /GXs/NI//dRf/YkG/WRs/dq//dz/3/3e//3gH/7iP/7kX/7mb4jYH8bnP8PpL8br//7wH//yP//0 X/+73f74n//6v/+YZf96ChD/BA4kWNCgQAMJFRo42NDhv4URGUKUOHHgwoIYDUrMmPDhR5AhRY4k WdLkSZQpVa5k2dLlS5gxZc6kWdOlPZw5de7kaa+iwp5Bg/5MiJOogZwLdyrVeTRpUaFRpU6lWtXq VaxZtW7l2tXrV7BhxY4lW9bsWbRpn0L1CbSr255w2yI1ynQu27ps4cpV29fvX8CBBQ8mXNjwYcQ7 USo86FEl44aQLzqOOFkyRYuTLdvk3NnzZ9ChRY8mXdr06dGXYaomqBpyZYQaY2du/+wY9W3cuXXv 5t3b9+/SrCPL/ih8dseJHDkeL24b+HPo0aVPp17dukPjrX+CPMp8M2bGHiVn/37d/Hn06dWvZ18e u23ysyt6x7xZPMPxzofTbt/f/38AAxSwpMuU0y++7IjSDj+M8uNvI/0GlHBCCiu0sDOt5JJorqXw isvDpirqkC639gKRJ74SU3FFFlt08UUYY5TRrBQ55KvGEOn6UMcd8/Lxx6hwnHFIIos08kgkkxxs sQjDOzBC5N578LvX4EMQyguz1HJLLrs0iTUnabtyyvqkrC0zMMn0ck0223SzOq7s4nBOOoUSUsg6 18pRrxOV9PNPQAMVdNAZUzoquf/tmiOTPOFcU5C+NyOVdFJKP/NKxBH7RFFTPGv0NKIRCRV1VFJL NfVUVFNVdVVWW3X1VVhjlXVWWmu19VZcc9V1V15hrfRXYIMVdlhiizX2WGSTfahXZpt19lloo5V2 WmqrtTYtZbPVdltu1bv2W3DDFXdccss191x001V3XXbbdfddeOOVV7Bu67X3Xnzz1Xdffvv191+A AxZ4YIILNvhgm+ZVeGGGv0X4YYgj3rJhiiu2WFeJM9Z4Y4479vhjgC8WeWSSSzb5ZJRPBnllllse LWWYY5Z5RZdrtvlmnHPWeWeee/b5Z6CDFnrohmY2+miksSV6aaabdvppqKOWemoYqqu2+mp8k9Z6 a6679vprsMMWe2yyeQoIADs= ------=_NextPart_000_0003_01C71FDD.5943FD90-- From ipfix-bounces@ietf.org Thu Dec 14 13:17:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guv89-0006TD-Ow; Thu, 14 Dec 2006 13:16:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guv88-0006T8-Tu for ipfix@ietf.org; Thu, 14 Dec 2006 13:16:28 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guv87-0000if-Hq for ipfix@ietf.org; Thu, 14 Dec 2006 13:16:28 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Dec 2006 19:16:28 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBEIGPQr004953; Thu, 14 Dec 2006 19:16:25 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBEIGOAr020335; Thu, 14 Dec 2006 19:16:24 +0100 (MET) Received: from [144.254.153.27] (dhcp-144-254-153-27.cisco.com [144.254.153.27]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA22578; Thu, 14 Dec 2006 18:16:24 GMT Message-ID: <458194F7.1030507@cisco.com> Date: Thu, 14 Dec 2006 18:16:23 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Thomas Dietz Subject: Re: [IPFIX] Sending export packet References: <113091BD57179D4491C19DA7E10CD6968C805C@mx1.office> In-Reply-To: <113091BD57179D4491C19DA7E10CD6968C805C@mx1.office> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1266; t=1166120185; x=1166984185; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Sending=20export=20packet |Sender:=20; bh=NU50da5MigsTf/SxH+igUtD4FOjsn1La+t1NFkF9JPc=; b=J01mP4TAX01U3hErh0WON3/+2tNHsa2fD/OwFkZYsgXfWAUR7GYEiuc03gtVf6nruXhioxzU uIRPdyTtDO+IVYqWSRE2NcUyH2ueSx5E+AaKslGU78yA0g3YvkrC/IOM; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Thomas Dietz wrote: > Bhuvaneswari, > > As an exporter you just need to implement one of the two approaches. We have > those two approaches because it may be convenient for one expoter to do it > time based an for the other one to do it based on the number of packets. If > you have a rather low volume of flows to export the packet approach is > better. But if you export a high number of flows the time based approach may > be more feasable. I'm pretty sure time-based sending is a definite MUST for UDP. A Collector should consider a Template that is not sent within a suitable lifetime as removed. I've always viewed the packet-based sending as an extra safety-net to ensure that you can limit the amount of lost data from a dropped template when sending at high packet rates. Andrew > As a generic collector you must be prepared for both. (If you just build a > special collector knowing to receive only flows with one approach you just > need to implement that.) > > Best Regards, > > Thomas > > > > ------------------------------------------------------------------------ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 14 13:17:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guv89-0006TD-Ow; Thu, 14 Dec 2006 13:16:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guv88-0006T8-Tu for ipfix@ietf.org; Thu, 14 Dec 2006 13:16:28 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guv87-0000if-Hq for ipfix@ietf.org; Thu, 14 Dec 2006 13:16:28 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Dec 2006 19:16:28 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBEIGPQr004953; Thu, 14 Dec 2006 19:16:25 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBEIGOAr020335; Thu, 14 Dec 2006 19:16:24 +0100 (MET) Received: from [144.254.153.27] (dhcp-144-254-153-27.cisco.com [144.254.153.27]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA22578; Thu, 14 Dec 2006 18:16:24 GMT Message-ID: <458194F7.1030507@cisco.com> Date: Thu, 14 Dec 2006 18:16:23 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Thomas Dietz Subject: Re: [IPFIX] Sending export packet References: <113091BD57179D4491C19DA7E10CD6968C805C@mx1.office> In-Reply-To: <113091BD57179D4491C19DA7E10CD6968C805C@mx1.office> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1266; t=1166120185; x=1166984185; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Sending=20export=20packet |Sender:=20; bh=NU50da5MigsTf/SxH+igUtD4FOjsn1La+t1NFkF9JPc=; b=J01mP4TAX01U3hErh0WON3/+2tNHsa2fD/OwFkZYsgXfWAUR7GYEiuc03gtVf6nruXhioxzU uIRPdyTtDO+IVYqWSRE2NcUyH2ueSx5E+AaKslGU78yA0g3YvkrC/IOM; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Thomas Dietz wrote: > Bhuvaneswari, > > As an exporter you just need to implement one of the two approaches. We have > those two approaches because it may be convenient for one expoter to do it > time based an for the other one to do it based on the number of packets. If > you have a rather low volume of flows to export the packet approach is > better. But if you export a high number of flows the time based approach may > be more feasable. I'm pretty sure time-based sending is a definite MUST for UDP. A Collector should consider a Template that is not sent within a suitable lifetime as removed. I've always viewed the packet-based sending as an extra safety-net to ensure that you can limit the amount of lost data from a dropped template when sending at high packet rates. Andrew > As a generic collector you must be prepared for both. (If you just build a > special collector knowing to receive only flows with one approach you just > need to implement that.) > > Best Regards, > > Thomas > > > > ------------------------------------------------------------------------ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 14 13:28:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuvK7-0002KK-P4; Thu, 14 Dec 2006 13:28:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuvK6-0002IR-Ho for ipfix@ietf.org; Thu, 14 Dec 2006 13:28:50 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuvK5-0001tA-5n for ipfix@ietf.org; Thu, 14 Dec 2006 13:28:50 -0500 Received: from [10.147.65.153] (luz@kaitos [10.147.65.153]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id kBEISkF07942; Thu, 14 Dec 2006 19:28:46 +0100 (MET) Message-ID: <458197DC.2030409@fokus.fraunhofer.de> Date: Thu, 14 Dec 2006 19:28:44 +0100 From: Lutz Mark User-Agent: Icedove 1.5.0.8 (X11/20061116) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] Sending export packet References: <113091BD57179D4491C19DA7E10CD6968C805C@mx1.office> <458194F7.1030507@cisco.com> In-Reply-To: <458194F7.1030507@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org >> As an exporter you just need to implement one of the two approaches. >> We have >> those two approaches because it may be convenient for one expoter to >> do it >> time based an for the other one to do it based on the number of >> packets. If >> you have a rather low volume of flows to export the packet approach is >> better. But if you export a high number of flows the time based >> approach may >> be more feasable. > > I'm pretty sure time-based sending is a definite MUST for UDP. A Collector > should consider a Template that is not sent within a suitable lifetime as > removed. > > I've always viewed the packet-based sending as an extra safety-net to > ensure > that you can limit the amount of lost data from a dropped template when > sending at high packet rates. I agree. Should we clarify this in the implementation guidelines? Regards, Lutz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 14 13:28:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuvK7-0002KK-P4; Thu, 14 Dec 2006 13:28:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuvK6-0002IR-Ho for ipfix@ietf.org; Thu, 14 Dec 2006 13:28:50 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuvK5-0001tA-5n for ipfix@ietf.org; Thu, 14 Dec 2006 13:28:50 -0500 Received: from [10.147.65.153] (luz@kaitos [10.147.65.153]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id kBEISkF07942; Thu, 14 Dec 2006 19:28:46 +0100 (MET) Message-ID: <458197DC.2030409@fokus.fraunhofer.de> Date: Thu, 14 Dec 2006 19:28:44 +0100 From: Lutz Mark User-Agent: Icedove 1.5.0.8 (X11/20061116) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] Sending export packet References: <113091BD57179D4491C19DA7E10CD6968C805C@mx1.office> <458194F7.1030507@cisco.com> In-Reply-To: <458194F7.1030507@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org >> As an exporter you just need to implement one of the two approaches. >> We have >> those two approaches because it may be convenient for one expoter to >> do it >> time based an for the other one to do it based on the number of >> packets. If >> you have a rather low volume of flows to export the packet approach is >> better. But if you export a high number of flows the time based >> approach may >> be more feasable. > > I'm pretty sure time-based sending is a definite MUST for UDP. A Collector > should consider a Template that is not sent within a suitable lifetime as > removed. > > I've always viewed the packet-based sending as an extra safety-net to > ensure > that you can limit the amount of lost data from a dropped template when > sending at high packet rates. I agree. Should we clarify this in the implementation guidelines? Regards, Lutz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 14 13:32:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuvNP-0003pi-HM; Thu, 14 Dec 2006 13:32:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuvNO-0003pD-BE for ipfix@ietf.org; Thu, 14 Dec 2006 13:32:14 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuvNL-0002BO-ST for ipfix@ietf.org; Thu, 14 Dec 2006 13:32:14 -0500 Received: from [10.147.65.153] (luz@kaitos [10.147.65.153]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id kBEIW9F08299; Thu, 14 Dec 2006 19:32:09 +0100 (MET) Message-ID: <458198A9.9000800@fokus.fraunhofer.de> Date: Thu, 14 Dec 2006 19:32:09 +0100 From: Lutz Mark User-Agent: Icedove 1.5.0.8 (X11/20061116) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] Template ID as scope for Common Properties References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> <45780A37.8010905@cisco.com> <45782D40.20002@cisco.com> <457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> In-Reply-To: <457A8E7D.1040707@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Andrew, > There are a few issues with using the Template ID as scope for Common > Properties. I am tempted to say that we shouldn't use the Template ID for > scope for anything, except perhaps the template refresh time, or other > data that is associated with the template, but not the records defined by > that template. > > > Issue 1: > The Common Properties usually contain information that is vital to the > understanding of the flow. So much so, that the draft implies that any > Data Record that is received containing an undefined commonPropertiesID > should be discarded. > > Now when the template ID is used then the Collecting Process has no way > to know that this Template has further associated Common Properties. As > such, it will continue to decode the Data Records, possibly writing them > to disk, without knowing that it is missing vital information. good point. This applies only for UDP. If the draft allows Common Properties with TemplateID scope, this issue has to be discussed. We already had some discussion if one should limit this draft to SCTP and TCP only, because on UDP the need to resend the Common Properties does reduce the gain. We came to the conclusion that the user has to weight what protocol to use and whether to use Common Properties at all. > Issue 2: > Some collectors will simply write all the Data Records, options and flows, > to disk and allow reconciliation later. For current options that use > things like the ifIndex, this is fine. Using the TemplateID will now > require them to store the ObservationDomainID and TemplateID with every > received record. I hope not! Of course it is additional effort for the collector to support Common Properties. This method as well as the method using the commonProperiesID IE. > These identifiers are really for use in the Transport > Session and are not supposed to be stored externally after decode. Of course. If the collector stores the ipfix data, it has to store all relevant data needed by the post precession application. There are certainly multiple ways to keep the mapping between the data records an the Common Properties without storing TemplateIDs. > Issue 3: > When sending information associated with the Template, such as the > refresh time for the template, then you would expect to send an option > Data Record containing the TemplateID as scope and the refresh time as > the data. So there are two issues here: > a) Is information sent with a TemplateID as scope associated with the > template or with the Data Records associated with the template? If this is unclear, we have again a new issue for the implementation guidelines. Best regards, Lutz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 14 13:32:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuvNP-0003pi-HM; Thu, 14 Dec 2006 13:32:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuvNO-0003pD-BE for ipfix@ietf.org; Thu, 14 Dec 2006 13:32:14 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuvNL-0002BO-ST for ipfix@ietf.org; Thu, 14 Dec 2006 13:32:14 -0500 Received: from [10.147.65.153] (luz@kaitos [10.147.65.153]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id kBEIW9F08299; Thu, 14 Dec 2006 19:32:09 +0100 (MET) Message-ID: <458198A9.9000800@fokus.fraunhofer.de> Date: Thu, 14 Dec 2006 19:32:09 +0100 From: Lutz Mark User-Agent: Icedove 1.5.0.8 (X11/20061116) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] Template ID as scope for Common Properties References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> <45780A37.8010905@cisco.com> <45782D40.20002@cisco.com> <457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> In-Reply-To: <457A8E7D.1040707@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Andrew, > There are a few issues with using the Template ID as scope for Common > Properties. I am tempted to say that we shouldn't use the Template ID for > scope for anything, except perhaps the template refresh time, or other > data that is associated with the template, but not the records defined by > that template. > > > Issue 1: > The Common Properties usually contain information that is vital to the > understanding of the flow. So much so, that the draft implies that any > Data Record that is received containing an undefined commonPropertiesID > should be discarded. > > Now when the template ID is used then the Collecting Process has no way > to know that this Template has further associated Common Properties. As > such, it will continue to decode the Data Records, possibly writing them > to disk, without knowing that it is missing vital information. good point. This applies only for UDP. If the draft allows Common Properties with TemplateID scope, this issue has to be discussed. We already had some discussion if one should limit this draft to SCTP and TCP only, because on UDP the need to resend the Common Properties does reduce the gain. We came to the conclusion that the user has to weight what protocol to use and whether to use Common Properties at all. > Issue 2: > Some collectors will simply write all the Data Records, options and flows, > to disk and allow reconciliation later. For current options that use > things like the ifIndex, this is fine. Using the TemplateID will now > require them to store the ObservationDomainID and TemplateID with every > received record. I hope not! Of course it is additional effort for the collector to support Common Properties. This method as well as the method using the commonProperiesID IE. > These identifiers are really for use in the Transport > Session and are not supposed to be stored externally after decode. Of course. If the collector stores the ipfix data, it has to store all relevant data needed by the post precession application. There are certainly multiple ways to keep the mapping between the data records an the Common Properties without storing TemplateIDs. > Issue 3: > When sending information associated with the Template, such as the > refresh time for the template, then you would expect to send an option > Data Record containing the TemplateID as scope and the refresh time as > the data. So there are two issues here: > a) Is information sent with a TemplateID as scope associated with the > template or with the Data Records associated with the template? If this is unclear, we have again a new issue for the implementation guidelines. Best regards, Lutz _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 14 13:35:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuvQY-0005xy-0R; Thu, 14 Dec 2006 13:35:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuvQV-0005x9-S9 for ipfix@ietf.org; Thu, 14 Dec 2006 13:35:27 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuvQR-0002Pa-JG for ipfix@ietf.org; Thu, 14 Dec 2006 13:35:27 -0500 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kBEIZBjH023148 for ; Thu, 14 Dec 2006 13:35:11 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kBEIXkGQ023006 for ; Thu, 14 Dec 2006 13:33:46 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kBEIXjDo023004; Thu, 14 Dec 2006 13:33:46 -0500 (EST) Received: from [128.237.240.128] (vpn-10-25-4-2.remote.cert.org [10.25.4.2]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.66) with ESMTP id kBEIXjGO017315; Thu, 14 Dec 2006 13:33:45 -0500 Message-ID: <458198DE.1040607@cert.org> Date: Thu, 14 Dec 2006 13:33:02 -0500 From: Brian Trammell User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Lutz Mark Subject: Re: [IPFIX] Sending export packet References: <113091BD57179D4491C19DA7E10CD6968C805C@mx1.office> <458194F7.1030507@cisco.com> <458197DC.2030409@fokus.fraunhofer.de> In-Reply-To: <458197DC.2030409@fokus.fraunhofer.de> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yep.. the rationale behind the two timeout regimes needs to be explained, and the guidelines seem the place to do it. Yet again, it should also be noted that since the UDP Transport Session is bounded by its template retransmit timeouts, UDP Transport Sessions may expire if too many packets go by without a template retransmit. #include Regards, Brian Lutz Mark wrote: > >>> As an exporter you just need to implement one of the two approaches. >>> We have >>> those two approaches because it may be convenient for one expoter to >>> do it >>> time based an for the other one to do it based on the number of >>> packets. If >>> you have a rather low volume of flows to export the packet approach is >>> better. But if you export a high number of flows the time based >>> approach may >>> be more feasable. >> >> I'm pretty sure time-based sending is a definite MUST for UDP. A >> Collector >> should consider a Template that is not sent within a suitable lifetime as >> removed. >> >> I've always viewed the packet-based sending as an extra safety-net to >> ensure >> that you can limit the amount of lost data from a dropped template when >> sending at high packet rates. > > I agree. > > Should we clarify this in the implementation guidelines? > > Regards, > Lutz > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFgZjd4/8LCZ4pwvYRAtwuAKDWPtM8YC3qefRZxy3ho8E38XVzbQCfXeoh PC/qICjvIEXSEjCIqqRVVro= =7JH7 -----END PGP SIGNATURE----- _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Dec 14 13:35:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuvQY-0005xy-0R; Thu, 14 Dec 2006 13:35:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuvQV-0005x9-S9 for ipfix@ietf.org; Thu, 14 Dec 2006 13:35:27 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuvQR-0002Pa-JG for ipfix@ietf.org; Thu, 14 Dec 2006 13:35:27 -0500 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kBEIZBjH023148 for ; Thu, 14 Dec 2006 13:35:11 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kBEIXkGQ023006 for ; Thu, 14 Dec 2006 13:33:46 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kBEIXjDo023004; Thu, 14 Dec 2006 13:33:46 -0500 (EST) Received: from [128.237.240.128] (vpn-10-25-4-2.remote.cert.org [10.25.4.2]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.66) with ESMTP id kBEIXjGO017315; Thu, 14 Dec 2006 13:33:45 -0500 Message-ID: <458198DE.1040607@cert.org> Date: Thu, 14 Dec 2006 13:33:02 -0500 From: Brian Trammell User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Lutz Mark Subject: Re: [IPFIX] Sending export packet References: <113091BD57179D4491C19DA7E10CD6968C805C@mx1.office> <458194F7.1030507@cisco.com> <458197DC.2030409@fokus.fraunhofer.de> In-Reply-To: <458197DC.2030409@fokus.fraunhofer.de> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yep.. the rationale behind the two timeout regimes needs to be explained, and the guidelines seem the place to do it. Yet again, it should also be noted that since the UDP Transport Session is bounded by its template retransmit timeouts, UDP Transport Sessions may expire if too many packets go by without a template retransmit. #include Regards, Brian Lutz Mark wrote: > >>> As an exporter you just need to implement one of the two approaches. >>> We have >>> those two approaches because it may be convenient for one expoter to >>> do it >>> time based an for the other one to do it based on the number of >>> packets. If >>> you have a rather low volume of flows to export the packet approach is >>> better. But if you export a high number of flows the time based >>> approach may >>> be more feasable. >> >> I'm pretty sure time-based sending is a definite MUST for UDP. A >> Collector >> should consider a Template that is not sent within a suitable lifetime as >> removed. >> >> I've always viewed the packet-based sending as an extra safety-net to >> ensure >> that you can limit the amount of lost data from a dropped template when >> sending at high packet rates. > > I agree. > > Should we clarify this in the implementation guidelines? > > Regards, > Lutz > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFgZjd4/8LCZ4pwvYRAtwuAKDWPtM8YC3qefRZxy3ho8E38XVzbQCfXeoh PC/qICjvIEXSEjCIqqRVVro= =7JH7 -----END PGP SIGNATURE----- _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From mean@akwbv.madamefram.com Thu Dec 14 20:47:30 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv2Ac-000864-NK for ipfix-archive@lists.ietf.org; Thu, 14 Dec 2006 20:47:30 -0500 Received: from mar75-1-87-90-38-28.dsl.club-internet.fr ([87.90.38.28]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gv2AT-0000U4-Jj for ipfix-archive@lists.ietf.org; Thu, 14 Dec 2006 20:47:26 -0500 Received: from CtuovjjqIBib (unknown [161.113.56.70]) by akwbv.madamefram.com with ESMTP id DA68656B4310 for ; Fri, 15 Dec 2006 02:47:14 +0100 Message-ID: <000c01c71fea$e932fe30$00000000@l8e471662a94e4> From: "KRCGTV" To: ipfix-archive@lists.ietf.org Subject: buds Date: Fri, 15 Dec 2006 02:46:59 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C71FF3.4AF76630" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.7 (++++) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d ------=_NextPart_000_0008_01C71FF3.4AF76630 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01C71FF3.4AF76630" ------=_NextPart_001_0009_01C71FF3.4AF76630 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable York gazaabscbn, linked stripkitam, timesgaza chml escalation gazathe? = Learned disclosed employment infringes secret liteplus itself. Short = reprieve jailst appealhome appealthe orlando, postcourt freedom = ageenron. Copiesand third prior express, consent ims. Applicable holders implied warranties, fitness entire asto defective = assume. Wbbush plans pigs flymail nextgulf raps iraqkltv, delegation. Autostart splash screen option magnet, blocking abstract. Cnets, stopped april completely remove? Level discontent warthe daybush mailbyrd twin idnational. Iraqwbzam = pentagon delays speech. Displays kazaarx toolbar monitors, explorer unofficial names. Supports protocols userspruna, formerly mediavamp koreanonly edonkeyon. Amim suprised counsel hasnt want provisions usually clause. Begin seem, favourite, program installed diverse, unlike providers = respect. Senatedes moines grow you your nogpeoples. Third prior express consent = ims seen entitynow. Will, discomfort many, pmquestion mean info gathered = folks why. Alleges catch files unlicensed also breached. Welcomes macon, midday timetable king pork. Patcher removed limit limits = ones maximum. Excludes slightly party modifying binary patcher! Heirs thomas edison bulbs labs. Identify, permits, identical filenames differing feature greater bytes. = Annextexas committe wbbush plans, pigs flymail. Xmule focus runs, wine lots, mods. ------=_NextPart_001_0009_01C71FF3.4AF76630 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"slightly"
York gazaabscbn, linked stripkitam, = timesgaza chml=20 escalation gazathe? Learned disclosed employment infringes secret = liteplus=20 itself. Short reprieve jailst appealhome appealthe orlando, postcourt = freedom ageenron.
Copiesand third prior express, consent = ims.
Applicable holders implied warranties, = fitness=20 entire asto defective assume.
Wbbush plans pigs flymail nextgulf raps = iraqkltv, delegation.
Autostart splash screen option magnet, = blocking abstract.
Cnets, stopped april completely = remove?
Level discontent warthe daybush = mailbyrd twin=20 idnational. Iraqwbzam pentagon delays speech.
Displays kazaarx toolbar monitors, = explorer=20 unofficial names.
Supports protocols userspruna, formerly = mediavamp=20 koreanonly edonkeyon.
Amim suprised counsel hasnt want = provisions usually clause.
Begin seem, favourite, program = installed diverse,=20 unlike providers respect.
Senatedes moines grow you your = nogpeoples. Third=20 prior express consent ims seen entitynow. Will, discomfort many, = pmquestion mean=20 info gathered folks why. Alleges catch files unlicensed also = breached.
Welcomes macon, midday timetable king = pork. Patcher=20 removed limit limits ones maximum. Excludes slightly party modifying = binary patcher!
Heirs thomas edison bulbs = labs.
Identify, permits, identical filenames = differing=20 feature greater bytes. Annextexas committe wbbush plans, pigs = flymail.
Xmule focus runs, wine lots,=20 mods.
------=_NextPart_001_0009_01C71FF3.4AF76630-- ------=_NextPart_000_0008_01C71FF3.4AF76630 Content-Type: image/gif; name="agreement warnings.gif" Content-Transfer-Encoding: base64 Content-ID: <000701c71fea$e932fe30$00000000@l8e471662a94e4> R0lGODlhkAG4AYewAAAEAHQKAAB5AIWLAAcEeHgGgAB4i7HBs8jqypjM60IoAFMjAIQtA6ojALwZ CdMsAgA0ABk+DTpEAGNMBXY7AJI9AMM0Bdg4AApgDSBfC0BgDV5eAIhXAJZjALhuAN1YAAB4Byx1 AEp2AGR/Ao51BKZ4CsiJANeBAAWpAxKeBz2mClOmCoGjAJ+RCLmoAOaRAQC1ACzBB0W7AFi6DIO7 AJmyALG6BObLDQDXAB7XAD3TAGvmDXHqB6XWBM3iANXRAAAAMhoAOz8AS1kKSHgAS5QKM8UMOe4A OAYUQRETR0wrQGITN3kpOKIiPLQtRtkfMwA7RRRCSjE+NmtANH1GM5lJRrxKROhLTgtuRxRlOEBX NmtSO3lhAKdkNsNoN9tiTQWATh99N0WKNGaNPIx5O5qLP7WNNd+DTgCdMyiqS0WqO12qSoWfQqmk N7unM9eiMgHAMiK1O0iyNFG+TIO4RqPGN8u3R9W2RArXThjfREnkTWvsPoDYNZPZP8fsP9rWRQAA iRUAeEUAc18AiXgAjZQAdcMAhuEAfg4eeR4WhkYVdVUZiHQSjZcojbIbeu0rdQg7cSlAjDtHe2JK dHlMdKg9jcpGftZAgQBifiZZeUhVf1drjHFehqVhg8FgcdhacwZzjCuGg0COeFx0hoJziph5jch+ fuB7eAecjBefijyZflqpiICjh5ysgM6UfdWfdgS9eSq9hzLDd2nLhX7Gf5i+jse7iujDhgjVfSPn dDbffm7mcobYfJTVi8nageLRgwAAySwNszcAu2EAzHgAxZwAxL4Av9oAuwckuiIUsz4mwlURuXgo uJkTtMAkvd0myANOwyEyxTI0ulhByHlGvJ8zt7dIv94ywgJYyhphtjlavFVazHFawptUzc5Yy+Zj xgNxtxSGsUONuV91wIKDvph7ycB1u+F0uACuwBaitjKoxWijv3enwpynu8elu+CexAC5sh21szy2 v2m8yomzx6m5vPD575iYmYKDevgAAAT2AP7/AAsL//8G/wD8//X//yH5BAC02CUALAAAAACQAbgB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTFO2pXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHeoTpdGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3bqRqNevYMOK HUu2rNmzZrmqXcu2rdu3cOPKnRsVrd27ePPq3cu3r9+/gAMLHky4sD26iBMrXsy4sePHkB8anky5 suXLfyNr3sy5s+fPoEOLHk26tEfMqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwFGbHk68uPHj yIsHny2g+fLnhi82n9684fSE1wlm/0e9Ovfu3rV3/1cIPvv2h+cLli+PML308Mk3+5y+kv5M+y/x q7TP3zl+/f0JEJN+LBFYk4H5OVefgi4h2JOD0EWoUkXpwdeeheIJoF5153EY3nYdYiiQe+9pyFCI JpZEYnyO8QThftQt2F2DDMIoIIL/KWggjjUW6N+M9oBnY4wD1riejEGW5yOQLSmZJIBCEjmkgFPe yOSVOmZJpYQ/UbTiiB6m+GWFYR5k3ocYkrjiddQNdKaJX2aYIZzesfkmmHSmuKGedorZp4Z3vukn fH3iaeh3erKIkIs9Lonkk0VuaeOUS2Ip6aQ0OkkflJdiep+RDAYI6aQ5duppqZiKiiqnjqZKZX9c Bv/lJZqFHjqmhSjWSeuhchq0ZplujhdsohfyuSuiyBoKoojJNntnsrUii2Kv0K7HrKIYkQnoerz6 iquI0UqbJrjMhotom82SR+ix0bZb7rHV5qnsrtMOa++528aJ7T+MXrppo55m2iTA/0pasMAIC+wg kS8+eqqWo0KKaoJbTiyqxKH+aDCoFWupMcCxnsXqwiBHTOrGVqIcMMmmYtzyqA2vnPGrGiM5ccIW Q+yyzRy3GnGMUoacV84dB4yzzhebnHTCA6fc6tKR+qzqzCeDPDLVMEO8NIEHO8x1yUJ75WSVlbY8 9pOlMinjiyybjDbHYLPqqtMPq920xypn3fHNbr//3bTDRocd076R6Us4ZIIvp3PijDcenJCON374 5JRXbvnlmGeu+eacd+45Y5GHLvroMX1gOumCmf5BTqqjzqXqsMd++kut4xT7TrKvTlPtQeUOu+2+ 64777DfxLpPxrttmPPIrMb878cAL73xL0/9U/UzX65S9S9vb033yrC0Pfe/j14R8+XZ9zz36Pamv Uvfug4+a+LI3P3v9pROP//rCw3S7/avzHUtyh73y/Y927Ktd6wgIQACOj4He+90A2Se/19BPdwo8 XQb7R737eZCD76NgBAOoPw1uMIQYFOEIO0hCEKIwfxL8He9OOMMPvpB+FRwMRlRHEB4KxIc89CFD /4BouiEWESFCJOIH/pHEIjZxiQoRIhOPOEUoFiR4UJTdD6moxCoOJIhcdGIYrSjFz50EKDh84Qr3 578PVq+GCyxhClvYQDgWsH925N/x8rjCNcqxj36U3h9zGJgdUtGLW8ziEXOXkCfC7iBlBCMZFynG SS7xiQuRIiYNUsYrbhKRkvxiJUV5Sd+R0oxs0eQYE+nJQ7aSk51E5Ck3GUpWfhKJh7zlKRv5yS5i 8peu7GEwUYkVVVqSla/EpRWFuUxmOpOWo7TlKqOYy2kmE5KxQyYoo+lFYDaTmHEx5i5rGUtkdlGZ 4+RmLbdZymE685nuLGcVzwnNds7ynFPcJThLgv9G6OVxg2+M4QHbONCCmlCQCJUgDPlHQSz2MY4G TSgHIcjG+BHyonmxaFk0ilHbcI6S33SKPPeZmI6ikKMbVaFJeUPSlrr0ICuNqUxnStOaVualOH2p TXfKU5x8hB9A1QhQ+cGUoQY1p0htyE+MClSVDFUoTw1LVGEyVZ9U1R5VZSo/WKJVprrEqFxtalef OtWyNtWpXl1JVs+K1q32VC9RJStblzpXr1y1JXfdyVXN6ta85lWtYG0rVusKWLcO1rBxPStfw2rY w761KBQZKkGCKtmMVPanR0XIZS2y2X9UdrOd9WxmD8LUgUg2tKY96mdVO9rMgra1o00qQ3jy17H/ MrauaZUrYQvL1sV29au5Dexh/YpbsRJ2r7vlrWKN21i8Mpe5gqXqXNfa3MeWpbaJ7St0owvdvzo2 u4WNrnQRu13hAre5uj2vc6vL2MEK1rtydS94x9ve8FoXLdgl71Z9e9y0voS/+hXvf5cbYO8O97d3 RS57w5vesRJYvvvtrXkFTN377iSysU0tUQVyWtdSNsOlTchlO7xh0W4YtRrmsIeJimIVl9jFJjZI Z1scY9HGmMalDfFkjbrjF7/2xbLFLJBTDGMH17jHGe5xikfM2iEr+cgkVsiMPzzkKTuZyFo9Mml5 rGMZr/jJMA5ySFDMZBYnObRZ1uyXyxxmNZ94/81JJvKSQRxbHK+YylLmMo/dLGct01jMGHktlPHs 5SqnudBzLvFqrxxmNtsZyIsGc58R7WJCu1nRTJY0oJ2y5yg32sOfvjGZCb3oNzN60GY2dZ4h/WUt T7ogP071QtiMZdj62NabFkmaaW3iWKu615e+9aG73GcdPxrWth71qWPd60OjGtl7Ljauc50QC1v7 2tjOtra3ze1ue/vb4A63uC9M7XITbtzoZpy5160osATg3WN5dwDSTW+hUETe+M73u0Ui74n0OyH/ joi+CYJvgu9bIAH/R8LZTbmEL7wjD29IxAcycYX8O+D5pvjBFb5xjgeA4aEBirxZMnKxlDwnJ/8f SspLnu+VnHzl8K43cDDicH1/XOMVR3jGdX5zj2984DY/yMV3bpCH93vgHse5wXsO8snV/OBD/3jF fw71qkvd6kzP+dGtLvSO8zzpXP+60pve8I5jfN9nZzrAuZ72pC/d4mj3etfVDva4X73nTye7Z0Qe c5W8HN5/nzdMbO53wPd95Cm3R+JbgviWD77vLje84CUfecEX3vIy7w3NzU71uyO96GHfetAXrnWs R9zodud528eud8Ll/es5Z33U3V4Q0sv97UunO+2VnvbO4771+3p93XUPeryz/fa2J77Yf197zt+8 98oH/mf4jvnAXz7yL2G59id/+HknfvEkp7z/4iHP+Jhbv/KWhznmMy869Vce/eQPv76vf/ntu8Tx 5ec+vmcy//ej3//0x34COIAEODjSd4AImIAKuIAM2IAO+IAQGIFaUYAUWIEWKHMSmIFccYEcCBsa +IEgGIKV04EkWIImeIIomII5IYIsCBUq+II61IIyOIM0uHcweIN+UYM6eEY42IM++INAGIRCOISZ t4NGOBJEmIRKuIRM2IS0cYRQGIVSOIVU2CJOeIVYmIVauIVc2IVe+IVgSBObsAmBMYZbaIYqgYZj uIYtsYZqyIZpCIf24IZmSIdkGIdyiIdkCIdoOIdu+BJ0uBJ/iIeEyId9OIh+eId9KIiKeId+/6iH e4iIieiIbTiIbxiHWniIkRgTl/iImOiJnwiKjCgTb9iIoQiIlPiJpViIq+iJrbiIquiIdZiKndiJ lYiJsziKL0gRYzgQvdiLCAGMwrgJAgGMxUiMx+iLyKiMCzGMv0iMxngQ0ZiMzGiHz2iH/xCN1wiN y0iN2biMz1gQw/iNBDGN5EiObiiO3aiBPKGJeugSgRiLLOGOkHiKqPiOuciJqSiKs2iHk/iHi9iP mziPsliQ7/iPpwiLrhiJ+6iQS0iPuqiLtUiJEAmLDkmQuMiGF2mP/LiJufiRA5mRk3iLoWiRA5mP HBmPeciRD2mQGPmSE/mSoGiSM3GJALmPMv8ZkY8IkjvpkRTpkzRZkrR4kiEpivYoiUbJhBB5lKY4 k00plPCIkxLZiE95jyRpiz0Jk03ZihG5lFm5kFBplCiZlEppiUiJkCN5kF0Zj2jJiPkoh2xJkHA5 lxgZkAVJjyvplIa4l3Zpl0wpj7sYgebIFIMpge1ojYiZmIq5mIzZmI75mJAZmZI5mZQZmWF4mZiZ mQRITAAAAFWIHJ0Zmv/QmQNBmqFJmgJxmp6Zmqo5mqhpmq15ELEZm66JmrUJm6fJELZ5mwiRm7e5 m6WZm6rpmcNZEMJJm6y5mq8pmq7Jms7ZnFIInLYJm8+5nM8ZnMq5mtDZm9kJndOpndKpnbr/eZzX GZzluZ3mSRDAeZ7pyZ616ZzWaZ3eKZ5GuJ7fOZ/V2Z3qKZr3mRDxqZ/4aZz0iZ7JCZ4Amp67aZ8D up4E2p4NypvU2ZzyKZ9QqKDmOaH6OZv8aaAK8Z/XSaHY2Z/72Z8Wip4lOqIJOqDlyaDkiaHF6Z4K yBOd6RIzqhIzqporgaM2CgAtcaOhmaM8GhM6qqM7WqQ9GqQ1cZpGWqMsUaNMyqRNyqNKCqVAChNQ SqVFOqVB6qTDiaRYCoRY+qRSOqZVKqZHag9KaqRWiqRZyqZcSqNsShNaqqZViqZeGqdq6qMv8aV2 GqV7OqZ62qd2Opx1moRUaqZvKqiJWqc//0qncHqmghqph4qnfDqnirqlmOqoftqnX1qpboqnl0qm kpqpKWgRGsqc95mqrbmcHOqf9Kmq37mhvqmgzMmbH1qrDBqixEmbLIqrKsqqBbqfK6qin1kauVqs 5dalS3GsyNqszvqs0Bqto8GsRiijRNqogzqpP0qohBqljXqt2Iqj3QqkPkqqkAqpb8qt4mqua8qn eYqtkaqZj+qtjHqn57qp6CqqZuqo7hqqmgqv9dqm98qpoLqpnkqqXAqwSWiq4hmhGGoQvSqb3Umh IAqj+RmhAiqx+Umg4ZmiEHugIfqxtvqZPnGl+oqwlJqmmnqpLLukKauwoSqqA0uuQ5qmNf8bp2HK rgJLrjvar5lpsjFrr5Y6s9mKqfC6qIX6p23aqQXbpTqrrUmqs0WLs0ZbsEPIsLpKnSKKscIqssLq sQ3KrP8ZsRL7ouEpoNQaoBqbscEqrQ2xtbt6q/D5q3TLtnDLttx5sWu7tiJ6nhhbohX7sG3rtgtx t3Arq766t3Lrm7/5m6+6ocn5sblKsatauRsrua3anrPKuFT4s1Z7tYTroJ0rr1cYuqZ7uiRLuqq7 uqWKuq77urAbu7I7u7nGukxIu7ibu7q7u7zbu777u8AbvMI7vMRbvMbbGbabvMpLgccLgsv7vNBL b807vdRbvdarFNGbvV+hDWDBvWjhvTP/Ab5EIb7b+xPkqxPnO1MUoQ0Ewb7/oA3w674CEb/uK7/t S78MYb8Fob/z+74Dwb/+exIAbBADPBHyW8D7mxAFjMANob8MTMAgZ7/sO8AHvBAP3L8SwcAXvBEX vMEN/L8OscAKfBEejBAljFMSHMAQ3L/1C7/te78H7ML/K8MsHL81PMHzK8Mp3MIxzMMzXL8BbMP4 u78uPMTvq8MY7MM/fMQ0bMMwnMNK7MQOrMNUPME8DMRG7MRMfMIvlcJMTMRIXMEYrMI4nMAQXMFl rMIsfL9jnMZknMBIDMJjrMZoDMJA7L8ALMZ4LMdtbMcH4cZevMdB/MZpXMhvzHCBPMd1/6zHPVzE BMy/hmzIW0zHP1zEjXzFh9zHM8zHkbzHVrzChGzEmQzIQvzCnDzIguzJdoy/ekxMPCG+5AvLK8G9 tDzLtqwSsQwT8MsStYzL9tDLvxzMvizLvuwSu5zLw3zLxSzMvAzMzhzMtQy+u6zM0szMLVHNybzM wGzN1ey93szM0WzLyGzN4EbMygzO0EzN6py+y5zOydzN4szL6hzP2ezO3HzO9GzP39zO96zN6DzP +pzP/ezO3wzP8FzP7BxTFTHEojzJQUzDdNzEEu3AhJzDD+3IfPzFGr3RrPzErSzFcqzFYqzFmzzS EG3RHI3JUxzFSezQkizSJH29Mm0V2v9b0zZ9bTPtgGWR0MccFNOsy+RszLGc0LpB1MYchCRBwRm9 vvmrxqC81BHB0Kbc0A6NEghM0RpsmGTBztjsE0Ztzy9xvl8tEwddz0e9F2ONzzi40FW8xA1dyhp9 xysNxWC8xk+80XEdx6p8yjtswmdM16E80XWNxjBdxh0d14Jc2FOdxIKNU68M1OYc2ei8z5JN1OG8 zmc92eI8zrRMv9780/z8y/sc0GUtz5ht1s+cy9Oc2mFdzKo9gEN9zF1d2fF82f6cvvQL1qXtzwgd 1Lk90O382c/c290s1rM92WXdy7ld3PEr2kd92cud1jLF1Kds0R/tx2uMw4Hsxn0MyNj/bcoVbdfg rchmTN6MHN5kDMmd3Mba7cd1LN5s7N6pHMM59dgAHdCnLcxdfduZbduafc35vc38bM4Dns/J/c+h TdrnbNsM/t/A/c/7Ld3b1tyiLdujLdkVft+4vNph3dwCTuFi3czS7OGZHdwVjtskPss/Hd2rDdoZ vuEWLtyuneLLfcsg7uIIzuLWxoJc7LowKOGkm9NCPuRd/IAefNIhzHB9AcugzdUr/uQoPuJSDuC/ YdlqDdQJTtbjthSH/dB//N2SzNdgjhytrBA9PscQCNKMjcUvfN5o3t1jDt7rTclU3dFKnNd9jdhr DsV3fNFLvMonLcSK7dGALcV6fciD/87dmmPfCj7Mr63iBB7gCM7fvW3gpg3NF/7gG07pjd7pAl7p vI3fnB7UqG3p8ozjHUXdg3zFiq7nmSzn6E3R4h3m8w3r5y3RoOzZdq3r743HrAzJr37rokzYS93l u87QcE1tI43KUJ3d1V3ecy7rtX7d1z3rnEzfz47d0j7n8W3tz97qo+zd8J3Y0O7UnMPox23Wp57j pn3g2JzpB27qnB7hl87uoc7aoH7P9D7vly7LtE3lDv7pE97kIh7av/3iCD/lMA7p1AzlDL/uA57i C//iFL7gBP/w737jMg7x5NzTM87ZCd/iHl/vFV/jKSjhQF7vY5Hy4MPy6svlD3Hm5v/uETGNSjLf OTe91kSegEOB6jnfgVH+8BR/8EJf8k3u8j8fNiFO3AIN8Piu30lfQRoP2ZY+1k8v8FH/G6oO7swe yTUf0mNO1TsPF+hO6uy+35ie7p6e9cGx9TO/3a9u7nDf6zc/9nLR68Ue9nlv63Hu5jNv9y74yhx+ zb9t9Aov4iJf9CsO0EjP9o5f04Af+ZK/Fo9f+ZZ/+ZhPFpOvd5nf+Z6/HJtPdp8/+qSfG6HfdKU/ gKcPcqkvgKv/+rAf+7I/+7QfvK3PfrW/abdfhLkvZrv/+8Af/MI//KjT+xGYD/mwGcgfEcufHM2P EM/vEMif/Aex/NGPLTwx/civEtv/7xvdfxPfrxfbH/4yQf5hQf7fb/7lnw/rbw/qHzoU0fzWT/2R cf0MYf9Jgf/VT/8icf3PDxD58v0jWNDgwX8CERpUqHDhQ4gRJU6kWNHixYsOGw5MKJBjR4cgOXr8 WFDjSI8ESSI8qTJlR5ciD5JEebKlzZo5Ta6UyTLlRpw+g858ybOnyJIyae4MyXTgzadJMU6lWtXq 1YhQYW7dyXVr069RGaIkGlMrzJdjzbZEW5Rs2q5nwTbd2NUrV7ZMY96ty/ej3KQhtYLFWtjwYYj2 FC9m3LgxTcUC7dHMF5nkZMmWLzPOLNnjYsqON3euTBqz49OnM6f2vDr0asyfTYfm/+y6dGXNn2uD xg07dWzdkE3vtlycNm/kqm+jZt7c+XPo0aVPp17dd+vHvXHH/i1aO+/lzUd/n72dOPbiyocnZx0e vXjstuEnv769vvHvxNt3z05/ue/qAhRwQAILdO6+8tLDT8H0YEMPwN8SVA41CfeLjzz7MFyQP+Te W0/BDyPUcEL+5CPxvgb/M89AFlt00bmq5tLJpZ/SMmqsGgWDSy2nnBJLqLx6girIpZCiUSqebDpy IbcIo8vGJG+kMawly/KxLcSy1DLLF7v0ksEvwzxwRTHLNPNMNNNUc00xIWSzxc3elHNOOusUcEs8 89RzTz779PNPQAO1yE5CCzX0UP9EE1WUMUH5JKxRSCOVdFJKK/1nUesy7O9LD8nE9FNQQxV1URPX dHNUVFNVtU7IcluQNADH06221oLTLlZbU7xwV9tmBe9WYG2dVdbhTl31WGQVi/EtZrF8lMog8Wr2 WbaiVEtHaMnica+6utU2rmbvsnRccskdsLzLKKuVwhFRtPA2T48rlcQT3VvRQQ0v1PVBYJP199/F ll2LKMr04rEvGe3qCyQrG35S2mz3sotbsbwdGMuwni13Y44DPbfd/NxNcT/9Kiwx5Fw71FRCkRPU t16SuzMWYJppLnZYlCEcD0zuXPb115GBa0/Ffckk9lV4e+WXPQ5rdvppqNmcmbr/qZmrOmqs5+x4 68KkxEpjicDmemyyDcv6bLTTVnttttt2+22445Z7brrrtvturcvWe2+++/b7b8ADF3xwwinC+3DE E4excMYbd/xxLRWXfPLDIbf8cswzP4hyzjv3/HPQQw9Vc9JLN/1v0VNXfXXWW3f9ddhjx/R02mu3 /Xbcc9d9d9579/134IMXfniCZDf++DSJV3555pt3/nnoo5d++omQt/76LqnXfvuOsff+e/DDF398 8sv/knv001d/ffZJh/M4An/WjNY4c6s/u/vnN39/M9WVn2qdKa1V9hsgAe/3P/4l0EBxyh8A4wUr 8+ArghKcoAQVeMH3PbBA/xPW/3N89UFcVRCDGLzKjg5jQoalECJwgZKTWtg+GG4NhUzyGg2lksIZ GkyFO8SRDmP4Qy59zFP4gx+7Hhgs+BQRgTgb4gjHZ5Uc6jCKPJzSkUzoPx3dUIVTBGIXLxI/Cq6L VmM6IhFBKEL9eSdDTXRi+KD4pJXsKIoozKFR5KgkG/rQi3sMFB2BQrCsPGqOWQQkFatoSD4msnpg NJoYwUNGI0IyjfrLHwOv1kZMcgd/mnxkEu+VsjFOkpPyQ2Amzfc1FuIRkTj6ywt9mMqS3KiGiqTl n7CIkyKFzX+sLJiPcmnFX66ylsMsHovUpcZLAoeDBTRgE4soSlNGU5rTXBsxrf8ZQ2pmU5vb5GY3 vXm8a4Zzfd8kZznNeU50plOd62RnO92pJnHGU57zpKfp3nlPfOZTn/vkZz/9+U+ABlSgqqtnQQ16 UIQmVKELZWhDHfpQiEZUossbaEUtelGMZvRtE+VoRz2KUI2GlEAfJangRHrS6pRUpX5DaUtd+lKY xvRFK6VpTW16U5zmVKc75WlPffpToAZVqEMlalGNuiWZJtUeR2WqVZQq06ZGFSNPpWpVRSpVrGZV q1exqku3+tXNdVWsY/UnWM16VrSmVa1rZWtbb0pWuMZVrnOla13tele85lWve22MW/3617fyVbCD JWxhDXtYFgFWsYtlbGMd+1gayEZWspMtDGIte1nMZlazcaVsZz3Lx82qMyAAOw== ------=_NextPart_000_0008_01C71FF3.4AF76630-- From BentleyrGiovannishea@ivpress.com Fri Dec 15 07:03:50 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvBn4-00006O-98; Fri, 15 Dec 2006 07:03:50 -0500 Received: from [219.136.155.15] (helo=sic) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GvBlJ-0005aB-4b; Fri, 15 Dec 2006 07:02:06 -0500 Message-ID: <425501b1d2c6$f2c5f050$f3a3fea9@billgates> From: "Giovanni Rollins" To: ipfix@ietf.org Subject: Re: .. Date: Tue, 15 Dec 1987 19:54:27 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_4251_01B1D2C6.F2C5F050" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.8 (++) X-Scan-Signature: 22f8e36c8d8be0bcbb9bf02fb6ce7335 This is a multi-part message in MIME format. ------=_NextPart_000_4251_01B1D2C6.F2C5F050 Content-Type: multipart/alternative; boundary="----=_NextPart_001_4252_01B1D2C6.F2C5F050" ------=_NextPart_001_4252_01B1D2C6.F2C5F050 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable - or as an act of atonement, or possibly even as a quasi-superstitious = rite: enough bandage-changes, enough sponge baths, enough ns filled in, = and Paul would live. - or as an act of atonement, or possibly even as a quasi-superstitious = rite: enough bandage-changes, enough sponge baths, enough ns filled in, = and Paul would live.- or as an act of atonement, or possibly even as a = quasi-superstitious rite: enough bandage-changes, enough sponge baths, = enough ns filled in, and Paul would live. Her rejection of what he had written would be easier to bear if he could = blame it on the pain, but the truth was that the pain had finally begun = to subside a little. - or as an act of atonement, or possibly even as a quasi-superstitious = rite: enough bandage-changes, enough sponge baths, enough ns filled in, = and Paul would live. Its only five in the afternoon, but that is no problem for these = kitties; as far as South American lions are concerned, that = dinner-at-eight shit is for goofballs. ------=_NextPart_001_4252_01B1D2C6.F2C5F050 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
3D"tactic"
- or as an act of atonement, or = possibly even=20 as a quasi-superstitious rite: enough bandage-changes, enough sponge = baths,=20 enough ns filled in, and Paul would live.
- or as an act of = atonement, or=20 possibly even as a quasi-superstitious rite: enough bandage-changes, = enough=20 sponge baths, enough ns filled in, and Paul would = live.
- or as an act of atonement, or possibly even = as a=20 quasi-superstitious rite: enough bandage-changes, enough sponge baths, = enough=20 ns filled in, and Paul would live.
Her rejection of what he had = written=20 would be easier to bear if he could blame it on the pain, but the truth = was=20 that the pain had finally begun to subside a little.
- or as an act = of=20 atonement, or possibly even as a quasi-superstitious rite: enough=20 bandage-changes, enough sponge baths, enough ns filled in, and Paul = would=20 live.
Its only five in the afternoon, but that is no problem for = these=20 kitties; as far as South American lions are concerned, that = dinner-at-eight=20 shit is for goofballs.
------=_NextPart_001_4252_01B1D2C6.F2C5F050-- ------=_NextPart_000_4251_01B1D2C6.F2C5F050 Content-Type: image/jpeg; name="bledburr.JPG" Content-Transfer-Encoding: base64 Content-ID: <424f01b1d2c6$f2c5f050$f3a3fea9@billgates> /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAA8LDA0MCg8NDA0REA8SFyYZFxUVFy8iJBwmODE7 OjcxNjU9RVhLPUFUQjU2TWlOVFteY2RjPEpsdGxgc1hhY1//2wBDARARERcUFy0ZGS1fPzY/ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1//wAAR CAFwAR8DASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0SiiigArP1HUYtOa185JG+1XCW6bAOGbO M5PA4rQrnPFv/MD/AOwtB/7NQBcXWbR7W/uYy7CxaRZk43DZnPHuAcevtT7HVoL6VYo0lQtb x3K+YAMo/TGD1B4Pv61yMdjcS2XiO609d1yb26gkT/nrGwHH1UnI/Ed6uXSXUHh7Q9Q05VNy trHbHJxlZUVQfwfaaANSfxRaQrblLS9uTcvLHEsEYcv5ZAJAznHp9DTz4jt1tllmsdQimldk itmtz50u0AkquegB68c5rC8S29nps/hy3uLyeytoI5kM9uxDj5VGQQCeT7d6u3V/4fvNFt55 NTufLtZBFFeBX81ZAoySduSSCMkjBzQBfufES2tjFeS6XqmxwzMFt/miC4yXBPy9ePoTUum6 5b39tNdta3dnbxIJPNuo9iupycqQSDwM/iKoR3N3deDdUkvN7bYbhYpXQoZYwp2uV7Z9PbNL cWk998P4La0yZnsYSoHVsKpx+OMUAXrLxBaXl2lt5N3btLnyWuISizYH8J78c9qgHimxN5PB Jb3sUcM5t3uWh/chwcYLAnHOOo7iqVzfwa/e6Vb6WJ91rdpPOWhZBEqg5U5HU5xgVjpazyjV pp7hm0hdXl+2WyoMlQwO/d1wDtyPQEigD0esyw1a21C6vLa2JaSzk8uTJHX1HtwfyqTUr6Ox 0u4viQyRRGQYPDeg/E4H41yWhnUNL1PT/t+mtapcxtbvMZ1fzZCTICQPunO4fjjtQB1mnajF qLXXkpIv2W4e3feByy4zjB5HNZbeKoftFzDDpOq3H2eZoXeC33ruXggEH/PFZWjeINJ0m41i DULvyZX1OeQL5btlcgZ+UEdQap6VqOk6brepTahq13bypqE+LZN5icE43MqqQTn3/hFAHSXf ia1s9RuLOS1vn+ybTNNHDvjjDLuBYgkgYz2puoeJ7ewnSJrDUZUkZFimhhDRylhkBDuGSfz4 NYV/a6hc654lFlcMkQWAXECIpaeMx8hWIO043Y45zWnrjWzWHhs2ZBtv7RthFj+6AcfpQB0V hdG8s0uDbz2+/OIrhNjrzjkZOP8ADFF/dGzs3uBbz3GzGYrdN7tzjgZGf8M1W1X+2cxf2P8A Ye/mfa9/tjbt/HOfatSgDntL8Sxandi2g03Uo8O0byywAJGwGSGIY4PbHXJplh4qh1BoPs2l as0UzBRN9nHljJwSWDEYB6+mDS+Ev+Y5/wBhaf8A9lrnfBOpaVZwWsUurXRvJswi0Yu0Ssz8 FQFwCeOc9z60AdGPFNibyeCS3vYo4ZzbvctD+5Dg4wWBOOcdR3FaDapbJJeJOWh+xqHkMmBl CMhhjOQeffjpXFJazyjVpp7hm0hdXl+2WyoMlQwO/d1wDtyPQEitjW4zqeorPZwrcx6aA821 j++yVbyhjg4Chu4zt9TQB01rcfabeOfypIvMUMEkGGUdeecCs298QWlndvb+TdXDR485reEu sII43Htxz3q9b39tdNH9nmD+ZEJUwDyhOM+nXjHWuet9Qg0G71W31ITtLdXbT2+yJn85WAwq kDqMY6igDRv/ABDaWQsikF1efbVZoRax7ywUAngkdjn8DV7TdSt9Tgae2L7VcxujqVZHHVWB 71wd7bLplr4Wg1a8uLMRpcGSaFiJI8gEAEA+oXp611Hg+OWHSpA4kKNcSNFJKpEkqE5DsDzk 88/SgDo6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArmPEkzadqFpqKI rM8U1rgnBZiu9B/30uPxrp6p3VpDdhFuI96pIsqgkjDA5B4/l3oA5rQVkfVLe2m27tHtGgY5 /iLlQfbKRg/8CqHwtqMOoanqUTyrPHfIbjy2AIUB2j2kY7p5fB7fWurFhbLJcuse1rrHnEMQ Wwu0fTj0x69eajh0uzge1eKIq1rGY4cM3yqQAR156DrmgDmbWytYNc8Svb2Fs0lnHDJbJ5S4 R/LJ+XjgkgdKtC0gPgyW+2BrqXTWeSYnLuWjydx78+vSugisreC6uLuOLbPdbPOfcfm2jC8H 0B7Ae9V/7GsNkqeSxjlVozH5r7ArcMFXOFzn+ECgDlrh7w6P4VWaCBIBd2mx0mZmb5eMqUAG eehP410XiW0t7jRL+S4t4ZXhtpWiZ0DFDsPKk9DwOnpVttKspLe0geHMdo6PAu8jYyDCnrzj 3zVi5t47m2lgmTdHKjI65xkEYPTkUAcPfWNrH4c8NmCytvMuLm08xSoUTEoeHIBznJ5IPU1L qEVrZ+Jl83R4544dK3m3t0RljPmkllB29CTyBnnOOtdPNo9lPZ21nJCxhtWRoQsjKUKjCkMD nIB9fenwaXaQXS3caSG4WIwiSSV3YoWLYJYnPPr9KAOdlFzp2g6XfpOL3U449kZU7vtCvyV9 SAACD/s+9dBosEEOmQC2lEyyDzTN3kZjksfc8/Tp2p1vpdlbzxyww7XiDiPLEhAxyQoyQM+w qa1tYbOJobWPy4y7PtBJAJOTgdhyTgcc0Acz/ZOm/wDCcfZv7OtPI/s3f5Xkrt3ebjdjGM47 1leF1BtNCjt7c2k7yyO91hQLhFZ8x5Byx6cMONpI6V3f2C2/tD+0PL/0ryvJ8zcfubt2MdOv tmoItHsIbKGxig228DiSNQ7ZRgc5DZznJPf1oA5zT9Ujk8cXQFwGWdpLYRcZUxKpB9cEmTB6 dap+H/8ARNB8OzWUYW4uLwxTFePMjLPu3euAARnpjiuwTSrKOOCNIMJBMZ4/nYkOSSTnOTnc abY6NYaeiLaQFBHnYGkZwmeu3cTtz3xjNAGH4WtkbUdXuHs7csmo3AS5ODKp4G0fLwME87u/ SjxzeCG0tbZbjyJHd5w3H/LNCwHPq+38a3bfSLO1uZLi3WaN5HaVwJ5NjO3Vim7bn8PT0FTN ZwNdrdOhM6xmINuPCk5IxnHJHXGeKAOe1YtPHba60H23TRa7pLfdgoDhvNX/AGgOOoPHBFaW sXMf/CLXd1byMY3tGaN8nOGT5Tk855HvVgaLYC3itxA3kxIY1USPyh6q3PzL7HI9qmubK3vL J7K4j3QOAGRWK9CCBweOg4/pQBzq6nPLqWjQtISbaVobrAwGlKSKP/QCf+BA1Dp+qRyeOLoC 4DLO0lsIuMqYlUg+uCTJg9OtdG+l2Uk3mmHEnnrcZViCZAu0Hr6dunNKmlWUccEaQYSCYzx/ OxIckknOcnO40AYNlFJY3x0y9DJqF1HN9n1BG5m6n5hx8yggjORxxUO5LXS9W0u5thDqMWnO 7yI5K3KhSPM/3s9SRn3rpo9Ns4pjKtvljuHzMzBQ2NwUEkLnvgDpTV0mzWGeEQkrPGYpC0jM SmCNoJOQOTgAjrQBx0pNrp9nCm0NrOlwWynP8Y2p/wCgyn/vmtC7s4pfG0FsbK2uYU0xRsuO iL5uMj5TkjpjjOeorol02zC2aeUdtljyOT8mFwO/PHrmm3Ok2dzei8kWVbgR+UJIp5Izsznb 8rDIyc0AaVFFFABRRRQAUUUUAFFFFABRRRQAVzd3d3b+KmsI71ra2TTzcHaiEb/MK5YsDxjr gjp1HNdJWLPodvc68uqziOZVtxCsMkQba2/dvBJ4P4d6AMKLXLqfUbNdQ1AaXDLpwuWGIwGk 3kfxgnBXnGc4resNQuP+EdXUtTh8qZYGlljXI4AJzj1IAOO2aWfRorjWX1CZw8UlmbRoGTqC +7Oc/h0981Ys7NoLD7HcSm5RVKBmGCUPADHuQOCeM0AV9GN5dWVrfXF0W+0wiRoQihF3AEbT jdwOuSc1T0PWJr2+1KOcr5SMZLfGP9WGZD2H8SZ6nrV600+7tLdbWO+HkRR+XCPK+dRjA3Nn DY9gtZ1n4WSwMLWVw0cqWr28jOGYPuwdwG75cNlsD1/GgCODxFO2iaVcsgFxc3Ecc3A+VSw3 NjsCGXH+8Kgj1XURHqN39pM7Qam1rFbFECsm5RgYAbcA3XJ6cirZ8LIsBWK62y+TBEHMZIDR lSWwGHLeWg4OflHJq7pehw6fcXt1iKa4ubmSYSmIB0DfwZ5OOP1oArXWq3EPiq2sEwLRkCSk kcSOHKe/SM9x96qVzrd5b63qVosinNxa21sGQERmVSWJxgnoTyetXLjwxHcXNxevcMLyS6ju EkwdqBMBQVDYYgAjPX5j+M0mgRSX2o3Uk7E3bwSJtXBieIYVgcnOT7D0oAp65qU+kaZePbas lzd24RzDKI96AugPCgYUhu4zz16VNNq051/RrNH8oTGdbqHgncqAryRnHOQRjINM1TwzJqgu JLq/AuJoFtw8cOEVBIJMldxycjHUda1LjSrefVbPUmBW5tiwDAcsrKRtPsC2R+PrQBkapqVx D4mFmbu6htlsvP221uJWL7yOfkY4wPYe9VG1rUJk8OtNPJbC/SZp/ssIlY7QCpA2sfqAOMn0 42rjS7mTWxqlpdxwv9m+zFJIS4xvLZBDDnPqPzqqvhs2w0n+z7sRHTRKF82LzN/mcEnDDHfp 6j0oAl+1y3Go3tkL97aHTYYzNPtTezMCxJLAqAAOcAdT2rP1zWLq1Ng1hfxyxTW947SxqjB2 jjJX16H0OCQa2m0+4Fybu2njiupI1jnJh3JJt6ELuBGMnHJ4OOay5fCUZs7G1hvHSO0iuYgW QMW85SM9RjGen4UARTa9dvY6I4Zbe6ubq3WdAAQ8cgJyM9jj6ggj63dF1C5ubqSO+uPLvU3+ bYsgAVd3ysjcEjGMkkj6VOdAgktNLhmbdJppiMUoXB+TGeOwO3+XpUg0tn1S3vrufzXtg4h2 psI3gA7iD82BkDAH40Aa9FV7aOWOFUnm86QZy+0Lnk44HA44qxQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRWLda4bW/hsX0y8aW4ZxCVMWJAoySMvxxzzigDaorIt9ct59 Pv73yZ41sHkSWNwu7cgywGCQeuOtQt4n06MoZvNiRrJb3eyjARiAF4JO7JHH60AbtFVLW5Nw H3W80DKcFZVHpnIIJB/A/XBqvPq0EEkw8uZ47f8A4+JUAKw8bvmycngg8A4oA06KzrXVrS6v 7qxhcme22llP8SkAhlPcc/56mhF4ntbiHTntrO7mbUPN8lFCBv3f3s5YAeo5NAHQUVUubxbb Tpb2aKRViiMrpwWGBkjg4z+OPeqVvr1rdMi20NxLmOKSTYoPkiQZXcM56emcfSgDYoqlf6hD YRRvNuzLIsUaKBl3J4UZwOfeq/8AbMIu7K0lguIprwyBVdANmwZbPP5EZB9aANWisG78S2lr ezWZt7mSeOeGDair8zyKWXGWHpyTin3PiGztbO8uZ45leyKCeDCmRN5G3vg5z2NAG3RVW2nk njLS2s1sQcBZSmTx1+ViMfjWd/bp+3/2f/ZN99q8rzvL3Q/cztznzMdePWgDborL/ti33E+X L9nEnlG548vfu27eu773GcY96fqeqRaZHbtJDLK1xMsEaRbcl2zjqQO3XNAGjRWJceIrO1s7 24ninV7IoJ4ML5i7yNvQ7T19a0ra4knjLSWs1swbGyUoSeOo2sR+tAFmis2x1aDUGDW0UzQO G8ufb+7fBwcEHI5HcDPaqtn4hivNLl1NLK6SzSJ5fMfy/mCZyAA5OeD1AHHWgDcorE/4SK2S 1tru6t7i1t7p0SKSXZg7lLAnaxIGB3HGR7kXP7Sg/tj+y9knn/Z/tG7A27d23Gc5zn2/GgC/ RWLNr0EN5fW/2W6cWCq9xKoTYildwPLZPAPQdqnGs2RldC5VVthdCU42NGerDntjnI7igDTo qtZ3IvLSG4WOSISqGCSDDAH1Gas0AFFFFABRRRQAUUUUAFFFFACHpWBqkEreJ9AmjikaKL7R 5jqpKplBjJ7ZPrXQVEGUlgGHy/ex24oA42HSJH0vxK8sV6s73N00KLJIgkG35SEBAcE+xz05 os9Pdr+0F7YTS239gxwyKYz98OCU7fN3xnNdXJe2kIQy3UMYkVnTfIBuVRkkZ6gDkkdqc93a x2ounuYUtyAwlLjZg4AOc4wc0AZegJeRm7jleeSyR1+yPcqVk27QWDAgHAPAzVGS1ntbTXdP 8ieWXUJZXgZULKd6Act0XBz1xwO9dJcTwW0TzXE0cMS4y7sFUZOBkngcmmyXVrFNHBLcRJNJ 9yNnAZvoM5P4UAczpekXEOq6sgMsbxx2ot7lkOGZItpOf4h2I9/XFZ1vplxZR+G4b62u9lq1 2J2tVkJTJO0gx/Ng/r9K7tZI3Z0V1ZozhwDkqcZ5/Ag/iKg/tCyMMU4vbfypGIRxKu1znGAc 8nPFAFfVw1z4fvfKSRmmtXCLsIYkocDaeQeenWsH7JdQ6fpsmnQXUGrJbW6H5G8uVQFBWTsN vPXB9K7DryeR6iobe7trneba4im2HD+W4bafQ46UAVtXgtrmxZLuCWaPIb9yCXQ54Zcc5HXj J9jWBDbaoLrStQvhLNFYz3C79mZWhZcIzIOc8cjGcde9dDBqumXMqw22oWk0r5xHHMrE8egO T0zU013a27KtxcRQlgzKJHC5CjLEZ7Acn0oA4zUtNvLnVGv4YbhI7rUrRkKx/OiJGwMhBB2g E/xD6ipdYsbz+w9ctDbz3N7LJHIJ0iJNwm9QvAGMqARgY6Z712ElxBD5fnTJH5rhE3MBvY9A PUn0pgu7R0ikW6hZJH2RsJAQ7cjaD0JyDx7GgCPT3ha1Atxc7EJUfaVkD569ZBk9ev4dqzvI m/4Tj7SYX8j+zPL8zadu7zfu56Zx2rSj1LT5Lr7Kl9bPcBivkrKpcEZyNuc5wDx9aX+0LIRS ym9g8uEhZH81cITwMnPH0NAHMf2bcnw1/wAI55c4uPP/ANdtbZs87fv3425x2znPatDxbBJP BpmyKeRI9QieXyFdmVAGyRt5HXqPatSDVtMuZlhttRtZpW+6kcysxxz0Bz6mpI72zkjlkiu4 Hjhz5jLICEx1yc8fjQBxuo6bdvoviH7La3Lw3EkLW4kV2mfBXdkN82BjjPPWuv054GtQLcXI RSVH2hZA+evWT5j16/hUltfWV5k2d3b3G3r5Uivj8qFvbR0ldLmFkg5lYSAiP13HPH40AYtj bTWuuKunRzxWDiQ3MEyEIj8bTGemSc5AJGBzg4rL0O3eLwXeWJtr5b5rSbdFJFLtz820LkbQ TuHC8n8DXZxSRzRpLG4eNwGVlOQQeQalxQBwxtmk0bQLaG1vmkgvLZrlJopTs+Uhsbx90Y52 8D8a1rTS7q18WG6LGSz+wtDGT1TEgO0nv1OD6D8T0ePekxz1oA4bUrJ5tV8R77XUC1zFEtq0 KyhJGEeDkj5SM4+9x1q/ren3E9joUbW5aZbiGK5EAO0RsP3gOP4MgdeOldVjjH9KAMHOaAAA DpjFOoooAKKKKACiiigAooooAKKKKAEPSuMa6lTVdWijeT/T5/s0RUfckWOMFvrtZjn/AGO9 dpVVLO2jculvErGQy5VADvOQW/3iOM9SKAOA1KTzNJ8ON6aZeL+Vvj+laut/8kyj/wCvS2/m ldP/AGbp5jij+w23lxqyonkrhA33gBjgHnPrmohoukorBNMs1DjawWBAGGc4PHPIBx7CgDN8 df8AIo3/AP2z/wDRi1Tct/Zfiv7Xjz/Nl2+uzyx5X9Me9dCmk6bHDLCmnWixS48xFhUB8HIy MYODU0lnayzRzy20LzRfckaMFl+hxxQByGjrfJrur3ABe7hhtPNhBwJP3XzDnvkcH8+pqppE Eln4ctNVi8qWa2tp0ns5zw8QlYtgdjkDt7V3iW8Mc0k8cSLLLjzHVQGfHTJ74FMks7WYp5tv FJsYsu5AcN3I9+aAMjxBLNL4PuZrFDG0luGVSMFUONwx6hSaW4yfEmjfYtvlC3mMu3/nnhNn /j2MVvYyME5qCC0trXf9mt4od7bm8tAu4+px1oA57wGt1/wjlmzzRG2KybYxGQynzG6tuwe/ G0fpzV8b/wDH9p3X/j0vv/RFdbb28NrCsNvFHDEucJGoVRzk4A46mmzWdrcMpuLeKUqGVTIg YgMMMB6Ajg+ooA4qVLmPSfC0e15LY3NpKJM58s4wVPsS2Qfw7CrtjG58Tf2YVPk2U814DswC JAuwZ9jJJ+VdWsMSxJCsaLHGAFQLhVx0wO2MDFAgjWVpVjUSsAC4X5iB0BPfr/OgDmPDsMk6 eIYpJlS1kv7lGAUh1JwC2/OMY7Y/GrGhSPbXx0ieOKVoLVGhu4l4eIfKob0YfXp+uwmmaelz 9qSwtluCxYyiFQ+TnJzjPOalgtbe2Vlt4I4Qzbm8tAuT3Jx3oA4sfaB4a8Vm0z5x1Cce+3K7 v/Hc1b8T5MkX2Lb5Q0y7Mu3p5fljZ/49jFdVFbwweZ5MUcXmOXfYoXcx6scdT71HHYWcUcsc VpBHHNnzVWMAPnrkDrmgDktOha9OkR3/APoiJpZWF4pCTOGQAgnAwVHzbeeuc8Gpo1mSy1DQ 2ihmlj0w/Z7uMBRJEQVVXJ+6ePXBGTxXU/ZLbbEht4ikH+qXYCE4wMenHFEVnbQxvHDbxRpJ kuqoAGz1yBwaAK+ixvDomnxOAHS2jUgHIyFAPPfpWjUaoEVVUAKvAA6AelSUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABSZGcd6DyDnpXO69q8+n6jpsEJXy3ffcknpGWVB1/2nB/C gDodw7ketLkVyc2oahHqXiFkuz5WmxRyRQlFKtmMsQxxu5x2I698YqKLWb65l1q8gumEFlbQ 3EMDIpUhot5DHG45x6jGaAOxyD70m4VSif8AtDTop4J5YPPRXV0C7lBwf4gR7dPWudtLvUX0 7Xbt9Snd9PluYYl8uLaQifKWwnXJz6cdKAOv3CjIzjvXFTarex6JpN6dUuUN3cwR3Ek0McYj VlJfblACvI+Y5HHB61oW11qN3BqAsbpZktnQ2tyQuLgAAshwAOuVyMdfY5AOmyMdqMj1rF0W +l1USaijlbGTCQRlRngncxPXJPAHQAZ71V8RSXtpNYSW2ozwrd3sVu0YSMqqsOSMpnPAPJPe gDpMjHWjIPSsC3lubnU7vTotQmX7CsZeVkQtI77jg/LjaAB0APWrWiX51bRre9H7tpkOQB91 gcEj8QaANXI496AQehBrmtO1G/u76HTnk2z2W430gQDf2jA4x833uPSof7bn/sM+IfPP2bzc C32jb5fm7M5xu3Y5647YoA6rcOuaMiuYttUvX0fxFcPP+9s7i5SBtoGwIuVHTnHvn3rJtNev WF61xqgWaG1t5beArGPPkeLcVxjc2WI+6R1oA77IzjNIGBHBBrn/ABBqF9ZeFZr6LFteKkbE ABtjFlBHIwepFGnajI2oXESXi32nxQCQ3eUO2TccoSmFPy8+2eaAOhyPWjI4561w7+IdRk8I ajfb1hvYJEZCoBwkhRl4I/uvjnPSt2C/e31ebTLqcyhLUXKzMArYDFWDYAHbOQBxQBt5HrSB geQQRXEP4h1GTwjqN9vWG9hkRkKhWwkhRl6j+62OfStnSr6a41Sa3hu11CxSJW+0jYSJC3KZ QBTwM9OMj1oA3iwAySAPWgMOg6+lYguri/1m8sbe4a3WxWMsyKpLuwJwdwPy4x0APPWsrTfE 9xd39s0kY+ySWAuJQAcxssjKzDuRxz7DPYggHY8UtYXh6+uL7+0zcS+YINQlhiwAAEG3aOOv Wt2gAooooAKKKKACiiigAooooAKKKKAEPSue1Xw1BqtxeT3MrbprdYItu5fKAJbJAYB/mIOD j7tdCelYtxqlyNdGlWlpDLJ9m+0l5JzGMbtuMBG56UAV/wDhH5mutQklvt0OoJGk6iIhiETa cNuOM89j14Pelbw8ftWotHdhbW/SOOSFYvmVUXbgMT3Ge1I+vXMd1qUTWMRTTY0knYTnOGTc Qg2c4wepGfaoNU8VpYbjHZmdBZJeKWk2EhpFQKRg4+9n9Md6AOkjRY41jQAKo2gDsAOB+VZE Oh+VYavafad39ozTSbtn+r8wYxjPOPXjPtVu2vWku5LK5iWG6ijWUhX3KUJIyCQD2OeB2qnp 2uDU9Jub+xtWd4WdVhLY34GRyR3Ug9O+KAI/7BuZLTTbWe+iZNPnhljKW5UsIwRhsueTnqOn oc8WJtGlIuora9aC2unDugTlf7+1sjG4deOCSRT7PV4767hitI/Mje3Fw8hbGwH7oxjqcH0w BWqWAHWgDNstOFldzvBKFtpgCLcLgI4GCwOeMjGRjrzSatpv9pfYcTCM2t3Hc/dzv25+Xrxn PXn6VR0nxCb20srm4tFt4r2RooSsu/DDdww2jGdpxjPvU1hq817NeE2sMVpZ3EsEkrTkt8gz u27MY6fxcUAWJ9PlF9LdWdwsEk6LHLuj3hgucEfMMMA3Xke1WbG0isLGG0gXEUKhB7+59z1/ GoLC+mvkiuBaiO1nTfE7SZbHUblxgZ9ifwqhp+u3F3oz6xLYxw2whkkULOWc7CeMbABnB5ye 3FAF600022ralqAm3/bfK+TbjZsUr1zzn8KrDRP3X2Izg6d5vm+R5fzZ3b8bs/d3c4257ZxV p9Wt/O02JCHOoZaMg9FCbs/yH41mad4je6trC7uLNYYL+byYvLm3sGyR8w2jjK9QT70AWJNF IS+hgu1itb93e4Qx5cMy4Yq2QB07g0yPw5bJLqI3nyLtIUVACph8tdqkNnk8Ag9sd6amu3Mk Gp3K2EX2fTpJo2Y3B3uYxnhdmADx34z3qWx1p55dOjurVYDqERmgMchcYChsH5V2nB9x70AS 6ppEup6E+mT3QErqitcCLqVYHO3PfHrTdQ0Zro3htbv7ML2ExTLs3BjjAYcjnGQfUY9Kdr+t RaJZG4khklcqSqIDg8gct0XkgevPAqPWNaOmXdhbmOA/avM/eTz+Uke0A8naeucUAUrnwlC9 re21rctbxXcUMbBg0hBRsg5Zs9MDHar1xozXMN75t0ou7qD7O0qx4VE54Vc8Z3E8nPNRatq1 7pemHUJLG1lijUMwS6OclsDafL54KnPHUjtzNbapcvrZ0m8tIon+zfaQ8U5cY37ccqpzQBQu fCML2t7bWly1vFdxQxsGDSEGNsg5Lf3QBjtWylgYtUkvIJNizIBNERkOw+63Xg446HIx6UzS dS/tI3v7nyvst3Jbfezv24+boMZz0rUoAyptOmF7Jd2dwkEkyLHLvjLhgudpHzDDAE88j2qC x0CKx1OG7gkxFDZfZFiK9fn3bifU/StyigDN0vS4NKW4jtF2xTTGYIOiZABA9vlrSoooAKKK KACiiigAooooAKKKKACkoqvJeQROUkfDDtgn+lC1AsEVztzo32vxWLu6soZ7IWPlAyhWAk8z PQ89M84rZ+323/PT/wAdP+FH2+2/56f+On/CizFdHN3Ph+7u9V1yc74VnEP2dhKdkm1MMrqD ypOByOmcVT8QaNq2pySzQWG3zdNjh8vzEG2QTKxUc9gDz0/Guw+32v8Az1/8dP8AhR9vtf8A nr/46f8ACjULoxLywvppb/VIbdku3svstvCXXeMkkknJXqR3PT3p3h/Sb7Sby4hmkWa2eGHZ Iq7QHRdhG0knJAUk9Pp0rZ+32v8Az1/8dP8AhR9vtf8Anr/46f8ACjULoy/DumzaedT8+ARe dfSSRkEHdHxt6dO/HatK3meVphJD5eyUopLZDjA5H6jHqKd9vtv+ev8A46f8Kb9tte0n/jp/ woswujmtH0W+Ol6TZX1sbcafcG4cs6newLFAu0n+9znHTvUum6TKk+sQXmmMv2+efbdqYziJ +gJ3bufTHp710X2+2/56f+On/Cj7fa/89f8Ax0/4UahdFHR0vLa1tbC4tGQW8KxtMHUq+0YG 0ZJ/MCufsNJv7XwjcaYujPHfywsjyBosS5Y4G4Pk4Vu/YEV132+2/wCen/jp/wAKPt9t/wA9 P/HT/hRqFznf7J1GPUYZhF5sVvegQ4ZRsgKvuOCexkC464Qcd6o6NoF7Fb6SjactneWlx5s9 0xjJkTLZUFSSSQQOcdK7D7fa/wDPX/x0/wCFJ9vtR/y1/wDHT/hRqF0cxBpV5FD4gibSWNxf SXJhuQYuUcfKpO7cASOmMcjNXNJ0i506TTZTG8mbVYJ0kl3m3YLnchJOFyMEDjhSOlbf2+2z jzP/AB0/4Uv2+1/56/8Ajp/woswujN8VWNzqHh27s7OLzZ5Nm1dwGcOpPJ9ge9X7syIFdLM3 RwVwpUEA9fvYGDxnn04NP+32v/PX/wAdP+FH2+1/56/+On/CjULo5u80O+XwN/ZEQ+0XgVQB vwCfMDEAk9AOPwq3c6MbvxULq6soZ7IWHlBpArASeYT0PPQnnFbP2+1/56/+On/Cj7fa/wDP X/x0/wCFGoXRjaDYXmlJfRizVY5tRkeNVZQFhOMMAOMcdODXRVW+32v/AD1/8dP+FH2+1/56 /wDjp/wo1C6LNFVvt9r/AM9f/HT/AIUfb7X/AJ6/+On/AAoswuizRVb7fa/89f8Ax0/4Ufb7 X/nr/wCOn/CizAtUVUF/bH/lp+h/wpft9r/z1/8AHT/hRZhoWqKq/b7b/np/46f8KPt9t/z0 /wDHT/hTsw0LVFVft9t/z0/8dP8AhSfb7b/np/46f8KVmGhbopiuHUMvIIyDT6BiHpXJ+Jb+ XThNdrbpNGm3eDJsI+6Bjg5698V1h6VzWu2UWoCe0mLCOTbkocNxg9ce1VFXEzIuNXktr5LO eK0hkaHzS8t0UTlsYB2dcAHtTLvXvst7cW5t0byGjXHnfvJN4B+VMfMRnpn8avTacJL8X0dz PBMI/K/d7SNuS3RlPfv7dqjl0e2mlupXMm+4KHcGwY2QYUp6EfU/lkVpZk6EWp6ymn3MUJi8 xSvmTOGIESFgobGDu5PT/Gn6jqh0+bZJauyNGfLded8vaPgcEjpn8utOm0a1uGne53TSTRrH vk2kxgDGU4+Xrk44zzjHFE+jW9yFFy8swW38hfMIbb6uMg4bp8w/KjUNB1/qD2GkG+kt8yKq Fot/AJIBG7kHGfTBxULawkVtFPIsUiNMY3NrL5oQBS24/KOgGSB29elWbrTo7vTTYTSSsjKq lyRuOMEHOOuRzxzk08WhPlGWeWZopDIpcL3UrjAUcck9M5xRZhoUbzWlto/MSON0NykCu0u1 CGQOG3AEYG78hmkuda8j7EAlq32rzP3n2rES7f8Ab28+nTrx71K+h2hi8uEyQKLkXSiPaNrg AcZHT2xgZ444qaTTIppbaW4kkne3DgeYFw4cYO4AAHjjjr3zRqGhVTWWmj07ybQia+DMqSNs ChRknOCT7HHPt0qe71JrFIJbq2ZIGJWaUNuERx8p4GSGPA4GM8gdAxtEtzFDH50/7gv5RJDb EYYKYKkFcccj2p39jW39jf2Vum+z/wB7cN33t3XGOvt/jRqGhYtZp57JZpLbyJnUsIXfpycA kDvwTx7dsVnQ68DpltqE9sUjmlKERsXKKA2WIwM42nI7D8q2HVmRlVijEfeUDg4xnGD06jII +vOaVnpcVnBbwpLK6W8jSR7yMjIYYJAGR8x/E+nFFmLQjuNWWNcxQiUvcx28RD/K5dFYMSM4 Hzehz+PGhEztGrSJsf8AiAO4A569s/iM9OnagdFs/JaKMPEv2gXCbDjy3AA+XORjjoQRzx2x fiQxxhN7uRn5nOSSSSSe3UngAAdAAOKEn1E7FSO9ZrWGbYC1zj7PGODjbuG5umcAsTg4HAyQ MuFzcHfEtvELqPazxtKdu05wQwUnqMYIBBz2xkhtNtnHbM2BAAIJEPzqAMKx4wGAJ9cjPGGw Jbe3EG5i7yyvjdI4G5uuOmAAOwAA5J65JLBoVoL6eS1hme3jVrgKYESUsSSu7ByowMckjPAP tm3A0rJ+/iWNwcEK+5cdcg4Bxzj1zngjBMa2Ua2cNsGcCAKsb5G5SowCDjrjORjByQQckGSC IwoVaWSZmOS8hBJ44GAAMADpgDqepJIg0Klnqa3N7LalI1dTIAEkDMAj7csOMEkggDPHf1NK 1NNRRsLGHEaSERyhwoYHg9MEEHIxjp68SRaekU3mGWV1DtIiNtwjMSSQQuf4j1PfpRZ6elp5 ZE0spij8qPzNo2LxnG0DrtHJ9Pfk1HoMuL2ZYIri1himgk8vazSsjZdgo42nj5gTk/qOWNqM kd7HaTpaRSFVZt1yQeWYAKNo3EbRxxyQPerTWqvaxW7s7iMxkMxyzbCCM9iTgZ45yenZHtN1 39pSeWNiqqyqFIcAkgHKk/xHJGOMemaGmGhWttTM941v5cXEjx4SXc67SRudcfKpx6nqo75q dbpmnWAQN5m9g4z9xBna2cc5+UY65JHJU09bSNAu0sGV3kDdxubcy+m0n1H6gEIloiSLIGcu sjyFieW3DBUnqVA2gD/YX0osxaC3E7RskUEQkmcEqGbau0EAknBxjcvABOT0xkitc6n9niUt HEkvm+TJ5suxEbYW+8AcggDHrnnB4qw1mpiiXzZRJCAEmyC+OM5JGDnGTwcnB6gERvp6NHGq zSxyJIZPNXbuZtpXnIIPBIAAAAGBjAAbDQDe5t7W7QZgnKAqww434CkEHHBIyPfrkYq5+FVD Zfu4rdW/dLJ5sjsfnZtwcYAAAy3XHAxxjIIuU0+4OwcelHHpSUtFw1Dj0ooo+vFDYK5v2/8A x7xf7g/lUoqG2P8Ao0X+4v8AIVMK5zUDVSSNXlYsqkgjqoJ6DuRVysvVbh7TT765jCl4YWkU MMjKrkAj04oETeTH/wA80/74Xj9KPJj/ALif98L/AIVVSwMTrLFd3Bl3AyGWRpFkH8XyE7VJ 6gqBggdsqaz61tsIbr7NnzLCS82b+m0Idmcc539ccY6c8O7CyNPyY/7if98L/hR5Mf8AcT/v hf8ACs2TVpoZJxPZMiW9v9plIkBKqS+Fx0LYTscdfm4G6BfEC+XckizmkhtpLgC1u/NGExkM doKk5GODnn05LsLI2TFEBnYmOmdi/wCFIYowD8i5HbYD/IVk3upX6RtHDbJFcLJbnDS8eXJJ tAJCn5sqQcZAByGNLq7x/wBp2Udw14ITDM2y280EtujAJEfPALcnjJ9xRdhZGt5MfdFHsUX/ AAo8mP8AuJ9Qi4/PFZEV1PaeWlrbzz288oit1uHKurbHZid/zbPlHUbuWwCNoMsWoSsUgtbZ XmeSfiadtoWOTYTu2k8kjAxgAkAjABLsLI0vJj/uJ/3wv+FHkx/3E/74X/Csm61s20y28qWd vOIw7rdXYiUgsyjYdp3D5T1AwCvqQNK0uftdvDcom2GeJJIyx+b5hk5GOMAjnPJJ6YBJdhZE nkx/3E/74X/ClSCNnAKJjBP3F9vb3p/eq19cNZ6fd3SAFobeSQA+qrkD9KLsLItfZYv7i/8A fC/4UfZoscovP+yvP6Vx0EEel2+gatAZTd380Ed07SsfN8xDnIJI4PIrq76G6nhSO0uRbEv+ 8k27m2EchewPTnoMfhSuwsiX7NET90HH+wvX8qPs0IGdq9M52L/hXE2E8i+B9FgV3UXl6Ld2 RtrbWlfPPvjHbrWhFYCz1i80DS5ZLS3uLAToQzP5T7ypK5OeQfUc07sLI6b7NDnGxfrsX/Cl +yxf3F/74X/CuS8qDSdQuZtC3+VZ200l9mRnV5NuUGSfv5BJwOB9ajggj0yDw/q0BlN3qE0E d07SsfN8xDnIJI4ODS1CyOy+yRf3V/74X/Cj7JF/dX/vhf8ACp6KLsLIg+yRf3V/74X/AAo+ yRf3V/74X/Cp6KLsCD7JF/dX/vhf8KPssX91f++F/wAKnoouwKzW0SgHYp+YA/IvOTj0qT7N D/zxj/75FOk+6P8AeH8xT6LsNCL7ND/zyj/75FH2aD/njH/3yKloouwsiL7NB/zxj/75FH2a D/njH/3yKloouw0Ivs0H/PGP/vkUfZof+eMf/fIqWii7AQAKMDAA4GBTqKKQxB0qpNGkvmxy Iro/ysrDIIIwQR347Vcqq+fNbBA5HbPYUwKKacBIplu7m4iRg0cMrKVUj7pyFDNj1YnnBPIz UH9hWxR4zPclDbPaopcERxMANq8dQF4JyTnktgY0Y3EkayRyI6ONysuCGBGQQQeQR3HWiNxL GkkciPG43Ky8hh2IIOO456UAQy2ME73LTBnW5hEEiE4BQFuhGMZ3tzn06dahbTDLbzw3N9d3 CzRNEd5RdoYYJAVQCcdCQcdsZNXVcMXCyIxQgNjnaSMgfXBBwccEHoaUhh3A+ox/WgCrcadD PJNIWdXkSNQVI+QxszIwHTIZs85B+mczNbo13HdFm3xxvGoyMYYqTxjr8gx+NSfNjORj6f8A 16MN6jr6f/XoAintknlt5HZgYJDIuD1JVl5z1GGP447ZBrnS4wFMFxNBIryssiBCcSPvdcMp BBbHbPy9eubo3HuPfI7/AJ0Yb1H5UAUW007g8N9dQylQkki7GaQAludykDlmPygYBx0wBcji 8s4WRygVVCsdx4zzuPzEnIySew6HJLsN6j8qMN6j8qAHUBFcmNhlWQgj1BxmmgNnqPyp0Ybe MMAdp5x7j3oAybLw/JbXFv5+pS3FpZnNrbtGq+WQCBlhy2AeOlalpDcxGb7TdfaN8zPH+7Ce Wh6Jx1xzz1NT5kyPmXn/AGT/AI0v7z+8n/fJ/wAaAMS18OpB4dg0h7liYW3pOihWV95cEDno cCiLRLtYLuSTVnl1C5iEX2owqNignhVB46nv15razJ13Jj/dP+NB8z+8vXH3T/jQBgaToWo6 d5cEusi4sVDK1uLNE35BH3s5zk59TUll4fkt7m3M+pS3FpZnNrbtGq+WcEDLDlsA8dK2/wB5 6r/3yf8AGjMmcBlz7qf8aAJM0ZqPL45ZfX7p/wAaAZD/ABL/AN8n/GgCTNGaZiT+8v8A3yf8 aMSf3l/75P8AjQA/NGaZiT+8v/fJ/wAaMSf3l/75P+NABJ90f7w/mKkqFw2BllxuHQY7j3qa gAooooAKKKKACiiigAooooAKqv8A6x/qP5CrVVX/ANY/HcdfoKAMNzNAX0eASL5zYgkTI8uF sl8EdCmCq4GFzED1pLmaeGDU5radoI9NBEVuiJ5bBYkcBuCepI+UjAHY5NbRRDIJCo3qpUNw SASCRk9BwM+uB6VFLZWc9wtxNaQSTpjbI8asVwcjBIyMHn2oAzI5pItXmjRgFm1LZIAOo+yB sZI9VHPfH1zHbXd3fzWyw3/lxTfa2MkSoSVSZVTaSCOAevOQT35GzLa200csctvFIkrBpFdA Q5AABYHqQAOT6D0FKtvCjh0iRWG7BCgEbjubBGCMnBPqRmgDBTU7+KwW9klSV59OlvAnl4SN lCEAc5IO/nJOSBjA4q1ZPfm7NvO14kckDsHuTbl1YFQNgTrjcc7gRwvTodVIIY/L2RRr5SlE woG1TjIGOg4HA44HoMQw6dYQRyRwWVvHHKu2RUiVQ4wRhgBz17+poAsj0Hv/AD5/z6/lS0cd P8KKACiiigA70sX+sH+6f6UlLGP3gBHG0jkfSgDD1Ce9j8V6PCbjbbTtP+6TIyFj/iOeTkn2 6dxmrniK6mttHuzbMVuPJkZWB5QBSxPt2APqRVm502C51Gyv3eQS2fmeWqkbTvGDkYz+Rqm+ h291b3cOoZuvPkkaN5SHa3DgDCEj5cYyB2/DkAwLy+vF0+xdZ7iVhpH2jbFIVdZAF/eucjcv tz34PaTU73U7SKe/aZ5Vjht3tJIMiKXJHm7sfLls8Z9RjvW0fDVh5EMMTSQiOD7MzJtBljP3 lbjueSQAck881Yk0e3dkXzJhboqD7MH/AHZ2HKcdsY7EZwM5oAs3cImtmjDzIM5IhYIzAH7u eMZ9QQeeo61zS6jdDwzqJS4Y3MbXCxgsWkt1QE7WbJJYAAZ56rz3rbfTXlubuRr26RZjGYwk v+qKg8qDwAT1GCD+OAyXw/ps1lJaywpIZDIxldVZw7/ecEjhuh49B6UAZV1LJ/wjOn3b3l39 rktI0gjilK+ZMyjaxxgsc9QSRjPFdLaiYW0Iuipn2L5hTpuxzj2zWYnh63iNkbW6uLf7HCYo jGsZ4JyzEMh+YkckY/U1rQoY41RpGcqACzYy3Tk44z9MdaAJqKTIoyKAFpO1GRRkUAMk+6P9 4fzFSVHIflGP7w/mKfmgBaKTNGaAFopM0ZoAWikzRmgBaKKKAENZtzdpFO6NCGwRk7sdh7Vp GsPUP+PyQ/TvjsKqKu9RN2JhfxnGLYZPbf8A/Wo+3R4z9lGP97/61ee2d1etpiTfaLlC1tcM 8kkpIkIDbdnJwQR7H8Dmryy3cGkWcpZ0Fy0CyTC5eRgp+8eQAhJ9PXrxVWQtTszfIDg2wHOB lsZ/Sg38QIBtxzyPmPP04rkdXBtktobS8mcvexxtGbhgVDA5Ut94A9ec+tV76e7tbueISyxq mmu5jWd5NrFmAYMcEkEjnHA496LIWp2/2+PobYZ/3v8A61Ib6Mdbcf8Aff8A9auMUPJcaCDc XOLqBjMFuHAciMY6Hj3x3zV7VJrmLWdJjtiDv84NG0jIrgKPvEDt1HB5osuwanTG+jAz9nX6 7jj25xQb6Mf8uw46/MeP0+tefaRLe3k9ohllmJs2ch7qSPnzWXJK5JOMDHp9KvXl/MNYS4SW dbWGZYCgDCNs8MWI+XhmA/D1PKsg1Oy+3R5x9mHHUbun14pft0ecfZgM9i3/ANbH61xNvc3I uTKJppH/ALUe32NKSoix02nOMdj1H5VY064mfwc07zO0whmIkLktkFuc564H4YzRZBqdcb6P n/Runbdz78YpBexhv+PdQfTd/Lj/APXzjPfzmS/vV0/UGF1PhYLQKwkbKsyqSc54Bw2ffFbG nG6mm1KTzcKlzMiSvcviMDkDy+VIBwcn39qLIep2A1BMgC2XJ9//AK3rxSfb04P2dcHn73X0 7elcfb3U1tFJH9pQXQt0k3XFxvt3BYAvkHIJ7Dgc9K6IjH8uDwcfTt6VSihal7+0E/59V/P/ AOtS/wBoR/8APqv5j/Cs/wClFHIhXZof2gh62y/99f8A1qP7QT/n1X8x/hWfRT5EHMzQ/tGP /n1X8x/hR/aMf/Pqv5j/AAqhRS5EF2X/AO0U/wCfVfzH+FH9op/z6r+Y/wAKz6KfIuwXZof2 gn/Pqv5j/Cj+0E/59V/Mf4Vn0UciDmZof2gnGLdRg54Yf4U7+1P+mP8A49/9as2ijliHMzS/ tX/pj/49/wDWo/tX/pj/AOPf/WrOopci7BzM0f7V/wCmP/j3/wBaj+1f+mP/AI9/9as6ijkX YOZmj/an/TH/AMe/+tTo9R3yInk43MBndnHOPSsypLb/AI+Yv98fzFDirApM6GiiisjQTtWN exSvcuyRuQcYIU+grZxxSYx0pp2YmrnMnTIzEsJ09DEucIYQVXOc4446ngep9aIdNigV1hsE jD4DhYsBgPUAcjnv0zWloetW2uWb3VpHMkaSGMiUAHIAPYn+9Rrgnj025ure8lge3hkkAVUI chcjduU+nbHWq5hWMs6VAYvIOnxmIHcI/JAA6jPTGevT+uaVdMiT5UsEVShTCwYG3Jyp4+7k k46E881LeST2l3bW76lflJI5XZ47dJHJUxgDCxnAG5ucdT16Cm3F3Is1lEL+/WN4pmZ0tMys ysgGV8s4GGI+6O3tl3YWYn2AAwsLTDQgrGfL5QYAwDjIGAOmKe9mWkSQ2x8yPIjcxklOMcHH GQOcYznpSHVGi0sTNeYjmnSO3up1WMvGwBZyCAoIHmFcgA7V4bPzSQ6u/wBjtdQldHhliKSp GRhZlySVJPK5DgnJAAU5ChmouwsVG0a1IUHS4iEyFDW44GTxyPXJ+vrmpW08GFomslMbNuKG LcpJPPY555yat3813aaOjzTlbkyRLJJCm7G6RQwRSpzwxAGCenU1Xe6uEtJGtr27eUzQoGvL QIF3SKpwNibuCc/zGaOZhykcenRxymaKyVZHOWkWIbm98gZye+P6nMaaPbLymmRKSCMrABkY wcnHcHGOn15qa91W5EDvEfImSwuHkhIDGOVRGQDkc43HHYgg8gilku5IrG+nivtQklitpHT7 TaiNVIHBH7tQTntk8Z49C7sFiM6ZEVdDYIVcKrKYc7go+UEdwAOPTp6ULpcK3BnXT0EpJO9Y cE56nOM5OfyOPWp7O6ka/jhhu7y57zpc23lhIyGwwOxeSwAHXjdxxkLDfzeXY3sty+29KYg8 kmNA+ABvVSVYbgMscMc8Ln5S7QcpX/syIRvGNPj2SHLp5PyuRyM4Hrzz/OrHkzbv9U/XjKkc du2P/wBVWIp7xrlLIn97E++abA+aLLbMf7TEANwANr4x8mZ9Tlkgt43ibaxuIUJ6jDSKrDn2 J/OlzA4meIZucxP0/uml8iYHBifOP7p/wqFtUu4tP1JpnVZFW5NtKFHJRpBtIOQSoUN7gng7 WNXt11eXNwsNw1strIIwqorB2KKxL5GSOQMAqevzc8VzvsHKV/s82B+5k59FNHkTDjynBP8A sn/CtmPf5aGRVVyMsFOQD3wSM+vYfSsjS55rm6mMt7dsYpph5RgCw7VdlUB9nOOP4icjnoRS Un2FyjfImzgRP/3yR/SjyJ/+eMn/AHyabHrcq2iTC1aREsoruaR5ACFIYkYAGX+U9AFPP3eM 27zWBaX8VtIsKq7ogDTjzW3HAZY8crk4JJB4bjgZOZj5UVvIn/54yf8AfJo8ibp5T59lPT16 Vag1WSSdFktDHFJPJbI/mZYshbnbjhSEPfOeMY+aoxqUstlDdfZ3iSWSExMrq25JHUYORwcH kAEc8NnkHMw5SHyJ/wDnjJ/3yaBBNx+5kzjptP8AhVg6wo1RbCRIVZ2KKqzhpQQpbLJjhSAc HJPK5AycVoNZlS000SLE8txbxyMZJREZGYciMEYdsjkZGNy888HMw5Rfs8//ADxk/wC+TR9n n/54yf8AfJrezkdKdS52HKc/9nn/AOeMn/fJo+zz/wDPGT/vk10FFHOw5Tn/ALPP/wA8ZP8A vk0fZ5/+eMn/AHya6CijnYcpz/2ef/njJ/3yakggmFxGTE4AcEkqcAZrcooc2w5RaKKKgoKK KKAG4ArP1UtLaSW32S4uEuI2jfyWRSgIx/Ew65469K0e1ZmrXktlHbmHbmWdYiWUtgHPQDk9 OgoQFG6+13E8M8dhqltLEroGja2OQxUkHczf3RjpT4nukmhlk07UppIo3jDO8ALBmU5IVwP4 QBgDvnNSSXl0J7C3jePdc+ZueSB1A28jCEgj8frTDqsxto8Rotx9rFo5PzIGzywGQSD6Ejr3 7vmAZEksVwsy6VqJCtI6xmSDarOcs3385zuwc5G9h0OAQrJDey3S6RqBZ921Gkg2R7tpbaN/ G4qGOc85I6nNqXUTBpU935sE5j+VWh5Uk4xkZOMEjIz0Ge+BVOrzf2JcXiiJp4JDGxXlCdwG Rg5IwaLgNaOU6elkmmalFHEVMbq9vuQKwZQMuQQMAcgkgc5OTQFvHTy7iz1W4AkjkBdrUbSj BuNrDqQAc9umKv6ZeS3bXIfayQyBFkVSmTgEgqckEE9zzmqk2rXUcF7dqIRFa3HlGJlO5gCo J3ZwM544P40cwEV3bm6lmlfR9QVpoHgk2SQjcrhQTjeRuAUAH2AOcDCFL2SCe3ubfVp454mi IZrQfeGCRtI7fUc9K0Rq8JlKNDMq/aPs3mHbgv6DBzg+uKzLHXWSzSW9Z5CIDK2yMZOZCg5B APbjH49qOYC40s7XEU50m/EkQZQfMh5VsZH+s9Qp9cgdsg10jmSRP+JZqJt42Bjty8AjjI6E fPk46gEkDjAGFxdk1q2iWUTxyxyROqGNtoOWGQc52gYyck9j7Zs2V9FfQvJCGARyjhsZVh1G RkHscjjmi4FETXAvJLkaRf75I0jI8yHGFLEf8tP9s5/CoUkvZ7C3hvtLvXmTynkdHhwXQq3H z9Cy+g4z0plvrFw2lPezsqhRkotq5A+cL94sA3XoD/LFXl1i3M5QxSqouDb+Ydu3eO3Bzg4H bvzii4FCe28+wlspNH1Dy5WkfcJYQys5JJBEnH3mHuDg5GakmW4klMkenanAX/1ohkgUSYwB n58g443KQcYGeBi3JrVrHO8Lq+5FduGU52jJGASQSBkA4/PimnW7UQtJJHPHiFZ1DAEshOAR gnqcDnHWjmASK5uYiFj0e9WNVCrGDAFQDPTD+mB17Dgd2W09xaxGNNIvtpkd8tJD1ZixA/eD uTVl71xd2sLRSQmbeNrKGJ2rnqrcdfQ5x261n32uo1hcmzcx3EaK65ZHyu8AnKkjjuDg0XAj S1YWslsNK1LZLarak+ZBkIoYAgh/vfOf8KdPDJLP5jaZqaKZY5mjWWAK0ilcMfnyeFUYzjvj OCNKHVLea9a1jyXRyhJZRlgMkAZ3HoRnGOvpU0rv9rggQ7QwaRmAzwpUYHpncMn0yB1yHzAZ aLInkgaTqBEM8k6/vIeWffnPz8j5z+nvTEgkjt1g/szU2jR4zGDLBhFRgyqPn6Ajqcse5OBj SjupjfGKQBFLMFRo2BwMkEP91iQM7RggE/3TUVzqyIl4kKbp4I3YJuVs7TjOA3AGQcHBx0BI xS5gKIhlW6jnGm6piOVpUi82DYrOG3cb+c7ieScdsAkFptpTaxWg0/VBAkKwPGJICJUAxg5c 4JGcldpP4DG/EzOgZ43jY/wtjPHHYkfqarySXTXskMLRBY40fDqcsSW/iB+UfL6GjmEWYmLI jtG0ZI5VsZXPrg4/WpqypNYtIVheTcvmRrLglVKqfUE5Pfhcn8xm2LkPctAkUjBDtaQYCqcZ xyc9COgxz9cSMs5FJuycAZ9cdqpXctxHtaHyjjACMCWlbn5R029OvPByQAOXiR0v1iLbklRn Xp8u0qCOOoO4H2IPXIAYF2iiigAooooAKKKKACiiigAqtdWkN2qLOrMEYOuGKkMOhBBFWCcA mkDDuMUAU3063k8rf5rNFnY3mvuGevzZyf8ADilOn2ptUtvKAijIZAMgqR0II5Bz3681aDg8 d6XPOMH8qQFJNLs1RVEZIEwnBLsT5n97Oef5UsumWk32jzYt32nb5vzEbtv3e/GPargYEkdx QW46UwIFtYluXuFUrLIArkEjdjpkdCR69e3SoH0uzkdmaNiHcSOgdgjMMclQcHoOo5q9u4yV IpCxAzigCr/Ztpj/AFXWf7R94/6z+91/TpUI0XT/AC/L+z/Js8vG9vu7t2Ov97n1rQ3ZwB35 pQwPODj1ouBTk020lkkkeLLyFWY7iDuUYUg9sDjjHU5qeGBIF2qXYdfndnP5kk1Luxxg/hSB gTwPxoAq/wBmWn2H7D5X+jdo8n1z1znrR/Ztp/zyP+u+0ffb/Wf3uv6dKtb+gwT9KC2O1AFD +xrDP+pbADhV3ttUNncAucDOT0Ap76VZPgPCGAiEOCx+4DkD8+/Xirm4d+KN3OMds0gKn9m2 xdGkRpDGW2+ZIz/eABHzE8Edqi/sWw2lTE7KUEeGlc4UEEAc8AEDp7+taO7px1pC3bH60wKy 2MAuhc4dpRnBd2bbnrgE4X8MenSnywbpY5kbbImRkjOVOMjHvgc9QQO2QZ9w4/KlzQBWS0hS bzQrbsk8sSAT1IGcAnJ5AzyfemLp9qrlvLLAqU2s7MoU9QFJwBwOAOntVwnApobPTkdKVwII rRI5Ffc7FVKLvYtgE5PJyTnA6njAx3yktlBNKZZFcsQFI3sAwGeCAcEcnqKs7s9AcetJvGSC MUwIJrSKd97+YGA25jkZCR6HaRnH9T60v2WIz+dhg/fDsFY9MlQcE49R2HoKmDg8EEfWnZoA qzWMM8olcyiRVKqyyuuATnHBHt9cD0FOWEi58+Rt7AbUAGNoOM/Ukgc/y5zYoJ4zQAtFM3jo OfpShux4xSAdRTQw6Um7uASKYD6KaGBPHrinUAFFFIelAGVoet22uWb3VokqIshjIlAByAD2 J9aXXBcR6bcXVveTQPbwvIAqoQ5C5G7cp9O2OtaYAHPU1n6qzS2ktr9kuLhLiNo2MDIpUEYP 32Hrx1oQGddyXFpd21vJqd+UkSV2eO3SRyVMYAwsZ4G5ucdT16Cm3F3KstlGL/UFjeKZmdLT MrMrIBlfLJAwxH3R29Rl92bu4uYp4rHU7aWJWQGJrY5DbSRhmI/hHoafE10s0M0mnalNJEjx hne3G4MVJztcDjaAMAd6sCE6q8WliZrvbFNOkdvczqsZeNgpZyCAoIHmFcgA7V4bPzSQ6u/2 S11CV0khliKSJGRhZlzkqSeV4cE5IwFPC7moiSWK4WZdK1EhGkkWMyQFQznLH7+c53Y543sO hxRCskN5LdLpGoFn3bUMkO2PdgvtAf8AiKgnOecnucoCa+mu7XRlklnZLkyRLJJDGGxukUME BU5wGIUEE/U1We6nS0d7a9vHlM0KBry0CBd0iqcDYm7g4P8AMZpXSY6fHYppupJHGyGN1e33 JtbcoGXIOMAcgnA5zyaNl46eXc2mqXAEkcgLtagqUYMMbWHUgZz24GOtADb3VbkQu8R8iZLG 4kkhIDGOVAhAORzjcSOxBB5BFEl3JFY308V9qMksVrI6fabURqpA4PMagnPbJ4zx6F3b/app pH0fUEaaB4JNskI3K4AJxvI3YUDPsAc4GApeyQT29zbatcRzxNEwZrUY3DBI2kHOM9cjmnoI fZ3cjX8cMN1eXPedLm2EYSMhsMDsXJLAAcnI3ccEh0N/N5VlfS3T7b0p+48kmNA5AADquVYZ HLHDHPC5ysrSztcRXH9kX4kiDKCHg5U9Qfn9Qp9cgc4yDAkcqSJ/xLNRNujAx2xeDy0I6EYf OB1AJIHGAMLgdh9CzFPetcJZMT5sT75psD5ostsx23NjB4A+V8YymZ9Tmkgt42ibaTPCmevD SKrDn2J5qqtxcLeS3K6Rfb5I0jI8yHGFLEYHmZzlj+lQpLfT2FvFfaZevOvlPI8bwYZ0KsSP n6Fl9OnpSsIjbVLuLT9Sedwsircm2m2jqjSDbzkEqFDD1BPB2sau7rq8ublYrhrZbaQRgKis HYorZfPJHzAYBU9eeRinPb+fYS2Uuj6gY5XkfcJIQys5JJBEnH3iPcHByCakmFxJMZItO1O3 38SrDJABJ0AyS+QcDG5SDjHPAwDNmPeYkMiqrkAsqnIB9ieT7dPpWPplxNcXUxlvbtmimmHl GALDtWRlUB9nJxjgNnP0NWIrq5iICaPerGqhVjUwBVAyOPn9CB6cD8WW0s9tEY49Iv8AaZHk +Z4TyzFjj956txQgK0OstHAbmZiYvsdrIokZQA8jOpLMAMDIXJxgAEgdqmGvI1k86rblkn8l 3Fx+4U7Q2TJjgYIGcfeOPeq6WhjhES6VqXEMMSt5kGV8oko338bgT3BBwOOuZf8ATPs/li01 cSbt3nebb7s4xjbv24xxjbjvjdzRoBom5uZtLe4toUNyYmaJN4ZHbHy4YEZUnBB44IzjoMmS +mhtL54L64laO0lkAu7fy3DKPlKDYoYDJ3ZBwdvTJzOm8WD2TaNfvHKH8wtJDl9xJYnEgwSW PTHXiq7W08sc6XVlqlwZYXhDO9spRXA3Y2sBk4ByQeg/EQE0d99ngurr7TqF15EDyeXc23lK dozw3lrz278EnFaEEV5FKrSXf2lH/wBYrIFCHGcptGcZ4wxJxg7uMNnw/bUDrc2ep3cboUaO b7LtIPXhSPcYJxjt6EAuI5FeTT9TuPL/ANUJpLdhH1GR8+SccbmyevPJyMLDru/u4NWkQgC3 hji2KrjMryMUUPlSQNwz8pyB2bOBK+rzqEi+xhro3P2dkWb5QfLMgO4gZAGM8Z64BwMwXCy3 Ek0j6VqAeVY13K8HylGLKQN/UM2ecg4HHqkSTRvFI+malLKs5nMjSW+XYoUGQHxgLxgAdB+J oHUmXWLhmXbYHbJPJbxHzgCzqW5IxwmEJJ5OeAp4Ju21213ZNMkQEoLpsZ+N6MVI3AHjIPOO nbtWaiSIIduk6h+5nknXMkHLPvyD8/T52xjBGB15zNaz3FtG0cek35BkdzukgJy7Fj/y09WP +eaA6kaXl2NIDvMDO12bcyKgGAbjy8gHPIHTOeRzmkW7uldrEzsXN39nE5VdwBiEpbAAXP3g OAOhIOCChWQ2jWw0nUArStMG8yDcrl94I+fHDEEZB6DOaascwhZW0zUmmaTzTcF4A4fAUMMO ACFAGAMEcEHJywsSyz30P2m1SV5niSKTztgL7HdgxwBgsoViMDngYODurT31xHaTmO+uHVZI Rukt9s6hpArYQoMgjG07Tk7hzjAbBZtBbyQrpWoYfaQwNspRlYspUKwAwSDjG0kE4yzFnPbz yRyCWy1SSZzGfPZrYMuxtygYYLgHPUHr9MAF3Srt5by5tvOuJkjSNw9xCYnyxcEY2rkYQc46 k89ANkVzanUYA0kNjqEly7xhpZmtx+7V8lMKwH3S/bOW6jAx0SsCR2J7VLAfRRRSATtWfqE0 kZtoIm2Pcy+V5uASmEZiQCME/JgdgSCc4wdAjis3UtzIipaXEzbtyvA0atE2OCCzD1I7g8g8 HBEBW+2S2U8ltMzXRjaArI2FYiWQpztGCQQTwBkYGOCTNPqpiS7YRRqLaYRFpphGnKK25mI4 5YKAAcnHYkjMgszBbvCmlagN2whgbZdjIxZSArADBIOMbcgnGWYl6QXARybLVWnaYTicvbB1 bYE4AbbjaCMEHqT1wRVkBai1qS5FstnapK86Stu84BFMbKpO4AkqSTggZ6cDJxSj8Rtb6faP eCDzTaJcS7pwhcMD/qxj5mIUnbkAEgZOc1NaRPaPE0elaiTEJQu+WFj+8cOckvk4I4JOcZzk 81DFaTQRQxxWOrIEiWFmEtuGkjXO1SQ2RjcQCu089SQDT0At3Op3BlnSGLYkFzBD5pcHfuaM kBcejkE8Y4xnJ22rHU/tkiRiEq4iLTjdnynDFdn+18yyDI/ue4qkwlbzs6TqH764jnOHh4ZN mB9/odi5+p554LGS5t5ruY6Lchp5dwCtD8qjtneOp3MR0DO3XqVZAUzqFwRMVvb1rvz5o4Lc Ww8p2Vn2Jv8AL6YXk7hgZORjjQm12KHUfsp8khZUiYGYCUs+3G1MfMvzjJzxhuOBmMrL9ke2 Gk6gFMrTBhJBuVy5kBHz44Y5wQe2c90JuPtZmXT9TRJHDyRpJAFdgAASd+7oqjAIBxgjk5eg FqDVpJbhI5LXy4pJ5LdH8zJZkL84xwuEPOc54xj5qh/t1haNcvagI1o93ABLksihTh/lG0/M vA3d+eOadjDcwy+bLpuoNtnlmSMSwlFZnfkfPkEK2CM7cknGeacLN/JeB9N1N4jA1vGpktx5 UbYBVSHyeAvLbjwPfJZAX7G6vptWuIbmFIoVgjdV8zcylmcc4UDJAwQCQNowTkmtbGDnNZVq JJNTe5ktLu33QqhEjRFDtJIPysWz8ze2PwrWyM4qJCF/Gj8aKMUDD8aPxpM+1GeaAF/Gj8aK TPPSgQv40fjSZpAQaAHUfjRRQMPxo/GiigA/Gj8aKKACiiigApMccUuKMUgG7fr+dKAAeKXF GKAFooopgJnrWZq13JZR25h25lnWI5QtgHPQA5J9hWniq11aQ3aos6swRg64YqQw6EEEUgM6 W9uhPYW8bx7rnzNzyQOuNvIwhYEcZ6n3ph1aY20f7pFuPtYtHJ+ZA2eWAyCR6Akde/fQfTre Tyi/msYs7G819wz1+bOT+NDafam1S28oCKMgoBkFSOhBHIOec5zyaYXK02peRpc935sE5i+V Wh5Uk4xkZ45I4z0574qsdYm/sS4vFETTwSeWxXlCdwGR3IwwrRTTLNUCiMkCYTgl2J8z+9nP P8qWXTLSb7R5sO77Tt835iN237vfjHtQFyHTLyW7a6D7WSJwgkVCmTgEgqSSCCe/Wqc2rXUc F5dqsXlWtx5JjZTuYAqCd2QB97jg/jWutrEty9wqlZZAFcgkbsdMjoSPXr26VBJpdnI7s0bE SP5joHYIzDHJUHB6DORzQBENYhMpRoZlX7R9m8w7cF/QYOcH1xWbZa6yWaS3jPIRAZW2xjJz IUHIIHpxj8e1bX9m2mP9V1n+0feP+s/vdf0qEaLp/l+X9n+TZ5eN7fd3bsdf73NAXI31m2gE vnpLFJHIqFH25ywyDnO3GB1J7fnasr6K+iZ4QwCOUYMBkMO3GQeo5HrSPplpLJLI8WWkZWZg xB3LwpBzxgemO9TwwJApVC5HX53Zz+ZJNIDPlubg2ks8JQuZhDGjg7V/ebMkjnk59hge5JHq TNc7nXZaCBpCzKd4ZdpboSMDdg98gjtzbWzUBkY5iLiQIQcq27ceQeRnBA7c+wDzawFsmJSN rLjHBDEFgR05IGaLAQtqARH8y3mWVSg8r5dx3NhSMHHXjr2NTW9wJg/yNG6NtdGxlTgHHBIP BB49aaljAoI2u2WVsu7McqcjkkngjOOnJ9TQ1pG5YnI3SLKwB+8y4x/6Cp4x0+uWBHf3Mlt5 LRxGTc5DKMk7QjMce/y8evTjOaZBqG+JSsTTM7ybRFjG1X27skgf3e/OeB1xckiR2jZxlo2L Kc4wcEfyJqFrGBkC4dcMzAo7KQWOTyCDgnt7D0FADf7QhIBCsylYiD0yJGwv6/57VJcNIsZa N44wOWeXJVQOc4yM9B3GM59qRrOBpYJPLCtbgiLacBQRgjA46ClntIbhAkoYqGDfK5U5HTkE Hg0AVhcXTiCNdkcsiO5Z0YghSoHy5BBO4Hk5HTk0sV0z/YZ8EJdgDyz/AAHYXyD+GDn2PGCD O1lCyIp807CdriV94z1G7OcH0z6egpTbL50TZAjh/wBXGoxg4I5/A4A9z14wAWqKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA// 2Q== ------=_NextPart_000_4251_01B1D2C6.F2C5F050-- From ipfix-bounces@ietf.org Fri Dec 15 08:47:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvDP1-0006l7-1r; Fri, 15 Dec 2006 08:47:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvDOz-0006kz-Va for ipfix@ietf.org; Fri, 15 Dec 2006 08:47:05 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvDOy-0006LU-HX for ipfix@ietf.org; Fri, 15 Dec 2006 08:47:05 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id kBFDl3F19046 for ; Fri, 15 Dec 2006 14:47:03 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Dec 2006 14:47:00 +0100 Message-ID: <70524A4436C03E43A293958B505008B6642DEE@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FYI: Notes on Implementing IPFIX thread-index: AccgT36n13mP2o6FSfSIreswNa43+g== From: "Schmoll, Carsten" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [IPFIX] FYI: Notes on Implementing IPFIX X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org =20 Dear all, =20 recently some IPFIX Implementors met in Berlin with their=20 software to check the current state of Interoperability, (see http://ants.fokus.fraunhofer.de/ipfix/interop06/) and to discuss about the nicknacks of the protocol and=20 the challenges to make it work in practice. While the former will result in contributions to the=20 current drafts and is already discussed lifely, the latter was decided to be too implementation-specific and therefore out of scope for an IETF draft. In order not to loose this valuable information=20 and to help other developers we have collected=20 these implementation issues and put them on http://ants.fokus.fraunhofer.de/ipfix/interop06/results.html The page also lists some existing implementations and tipps=20 on how to use a VPN for remote testing. Hope this helps! Best regards, Carsten. =20 -- "The difference between theory and practice is that in theory theory and practice are the same but in practice they are not." Dipl.Ing. Carsten Schmoll Fraunhofer Institute FOKUS schmoll@fokus.fraunhofer.de National Research Institute Fraunhofer FOKUS / dept. ANTS for Open Communication Systems Tel: +49-30-3463-7136 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8000 D-10589 Berlin, Germany _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Dec 15 08:47:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvDP1-0006l7-1r; Fri, 15 Dec 2006 08:47:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvDOz-0006kz-Va for ipfix@ietf.org; Fri, 15 Dec 2006 08:47:05 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvDOy-0006LU-HX for ipfix@ietf.org; Fri, 15 Dec 2006 08:47:05 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id kBFDl3F19046 for ; Fri, 15 Dec 2006 14:47:03 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Dec 2006 14:47:00 +0100 Message-ID: <70524A4436C03E43A293958B505008B6642DEE@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FYI: Notes on Implementing IPFIX thread-index: AccgT36n13mP2o6FSfSIreswNa43+g== From: "Schmoll, Carsten" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [IPFIX] FYI: Notes on Implementing IPFIX X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org =20 Dear all, =20 recently some IPFIX Implementors met in Berlin with their=20 software to check the current state of Interoperability, (see http://ants.fokus.fraunhofer.de/ipfix/interop06/) and to discuss about the nicknacks of the protocol and=20 the challenges to make it work in practice. While the former will result in contributions to the=20 current drafts and is already discussed lifely, the latter was decided to be too implementation-specific and therefore out of scope for an IETF draft. In order not to loose this valuable information=20 and to help other developers we have collected=20 these implementation issues and put them on http://ants.fokus.fraunhofer.de/ipfix/interop06/results.html The page also lists some existing implementations and tipps=20 on how to use a VPN for remote testing. Hope this helps! Best regards, Carsten. =20 -- "The difference between theory and practice is that in theory theory and practice are the same but in practice they are not." Dipl.Ing. Carsten Schmoll Fraunhofer Institute FOKUS schmoll@fokus.fraunhofer.de National Research Institute Fraunhofer FOKUS / dept. ANTS for Open Communication Systems Tel: +49-30-3463-7136 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8000 D-10589 Berlin, Germany _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From hurleyfraze@daysinnbutler.com Fri Dec 15 15:56:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvK6C-000288-Q2 for ipfix-archive@lists.ietf.org; Fri, 15 Dec 2006 15:56:08 -0500 Received: from p54bd5e09.dip.t-dialin.net ([84.189.94.9] helo=r9y3x5) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GvK5l-00085q-Qd for ipfix-archive@lists.ietf.org; Fri, 15 Dec 2006 15:56:08 -0500 To: "sherie michelle" Date: Fri, 15 Dec 2006 21:55:07 +0100 From: "darleen cathy" Sender: "darleen cathy" Subject: Hallo MIME-Version: 1.0 Message-ID: <1fd3d01c7208b$4d78bdd0$4028fea9@r9y3x5> Content-Type: multipart/alternative; boundary="----=_NextPart_000_1FA81_01C72093.808E01A0" X-Mailer: Microsoft Outlook Express 6.00.2900.2527 Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 This is a multi-part message in MIME format. ------=_NextPart_000_1FA81_01C72093.808E01A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit HOT MONDAY FOR TTEN TTEN *** TTEN *** TTEN TTEN - Ten & 10, Inc. GROUND FLOOR opportunity in the WIFI Industry!! TTEN could see explosive growth as a newly trading company - 500%-1000% is not uncommon. Current Price: .11 Short Term Target: 2.20 TTEN has grown from China business focus to USA, Europe, Latin America as well as other areas of Asia. Within 12 months expected to generate $2 MILLION in NET INCOME. $200 MILLION in 5 years. TTEN is made up of 4 operating subsidiaries: Tech 10: WIFI and WiMAX Mobile 10: Music and mobile entertainment delivered via Internet, G3, etc Dream Learning Center: Digital Media Learning products Ten & 10 Network: Sales and marketing Telecommunications is globally a TRILLION dollar industry. Tech 10 has entered into a strategic alliance with FSP Holding an Asian based WiFi and WiMAX provider. The collective goal of the venture is to become the premier MAN/LAN (metropolitan area network/local area network) provider satisfying the needs of government and corporations in Asia. FSP is currently a pioneer in developing high performance, efficient and expandable wireless/wired communication networks in Asia. The Core business is: metropolitan wireless broadband for emergency responses, the WiMAX applications and value-added services, include: Public Safety Surveillance and Mobile Command Center, Distance Learning, Cyber Cafe Access, Dynamic Video Surveillance, SOS Poles, Public Traffic System, Road Monitoring System, Video-Conferencing, Multi-media Broadcasting, Train Compartment Monitoring etc. FSP anticipates the ability to generate gross revenues of about $2 billion in five years, and net profits of about $200 million. WATCH THIS SHARES GO HIGHER AND HIGHER Any of the above statements with respect to the future predications or goals and events may be seen as only Forward Looking and nothing else. All information inside this email pertaining to any sort of financial advice need to be understood as information and not advice. None of the information above can be constructed as any sort of financial advice. This is a paid advertisement. ------=_NextPart_000_1FA81_01C72093.808E01A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit HOT MONDAY FOR TTEN

TTEN *** TTEN *** TTEN

TTEN - Ten & 10, Inc.

GROUND FLOOR opportunity in the WIFI Industry!!

TTEN could see explosive growth as a newly trading company - 500%-1000% is not uncommon.

Current Price: .11
Short Term Target: 2.20

TTEN has grown from China business focus to USA, Europe, Latin America as well as other areas of Asia. Within 12 months expected to generate $2 MILLION in NET INCOME. $200 MILLION in 5 years.

TTEN is made up of 4 operating subsidiaries:

            Tech 10: WIFI and WiMAX
            Mobile 10: Music and mobile entertainment delivered via Internet, G3, etc
            Dream Learning Center: Digital Media Learning products
            Ten & 10 Network: Sales and marketing

Telecommunications is globally a TRILLION dollar industry.

Tech 10 has entered into a strategic alliance with FSP Holding an Asian based WiFi and WiMAX provider. The collective goal of the venture is to become the premier MAN/LAN (metropolitan area network/local area network) provider satisfying the needs of government and corporations in Asia.  FSP is currently a pioneer in developing high performance, efficient and expandable wireless/wired communication networks in Asia.  The Core business is:  metropolitan wireless broadband for emergency responses, the WiMAX applications and value-added services, include:   Public Safety Surveillance and Mobile Command Center, Distance Learning, Cyber Cafe Access, Dynamic Video Surveillance, SOS Poles, Public Traffic System, Road Monitoring System, Video-Conferencing, Multi-media Broadcasting, Train Compartment Monitoring etc.  FSP anticipates the ability to generate gross revenues of about $2 billion in five years, and net profits of about $200 million.


WATCH THIS SHARES GO HIGHER AND HIGHER




Any of the above statements with respect to the future predications or goals and events may be seen as only Forward Looking and nothing else. All information inside this email pertaining to any sort of financial advice need to be understood as information and not advice. None of the information above can be constructed as any sort of financial advice. This is a paid advertisement.

 ------=_NextPart_000_1FA81_01C72093.808E01A0-- From powderpitswai@tfn.net.tw Sat Dec 16 14:11:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvewJ-0008AM-N6; Sat, 16 Dec 2006 14:11:19 -0500 Received: from 60-198-130-156.static.tfn.net.tw ([60.198.130.156] helo=tfn.net.tw) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GvewG-0004Mh-GV; Sat, 16 Dec 2006 14:11:19 -0500 Message-ID: <1ccb01c7215f$05e06430$ebd81c0a@powderpitswai> Reply-To: "Rema" From: "Rema" To: "Julie" Cc: "Olympia" , "Rosanna Perkins" Subject: Hmm might be helpful Date: Sat, 16 Dec 2006 22:10:40 +0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_D69_9126_14F64379.E61C96FF" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Spam-Score: 0.3 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 This is a multi-part message in MIME format. ------=_NextPart_D69_9126_14F64379.E61C96FF Content-Type: multipart/alternative; boundary="----=_NextPart_28D_7B4D_80978D26.322B9FFF" ------=_NextPart_28D_7B4D_80978D26.322B9FFF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable green as most Englishmen steaming teams and led them to the long, strag= gling strawroofed of the trees there stands the Black Creek StoppingHouse= , which is thestables. The hay that had cut on the meadows of Black clan. backwards in spite of harm us. We will take a cave from high up= Speak!" engine policeman foot It respect was a sad leave-taking as yawn in silence Hes green enough, Fred agreed, but hes not afraid of work. ButCreek and s= tacked beside the stables was carried in miniature stackshalfway house on= the way to Brandon. Hungry men have smelled the baconwhich completely hi= d the man who carried them into the mangers, while I drawer dive shook hands with each of the three remaining men. Even = "Come, twelve then," said hoop one. If you will not angry harm us, you =   poor uniform Nobs appeared dejected as we sincere come now, dont you want to go to bed I can put you up for the night,the c= reaking windlass of the well proclaimed that the watertroughsfrying when = more than a mile away, and it is only the men who followwere being filled= The cattle who foraged through the straw stack in quit the compound vanilla and may come. large Take grass Tsa's hole, coff= ee which lies above you." sketch-book leave The set phrase out upon the well-marked spoor the trail who know what a hea= rtsome smell that is. The horses, too, what theres left of it; its nearly morning now.the field near by always m= ade the mistake of thinking that they weretired with the long day, point = their ears ahead and step livelier whenincluded in the invitation, much t= o the disgust of Peter Rockett, the congratulate of the abductor. Not behind creature showed paint us the = mouth of a its black cave, but he kept The old man yawned sleepily, and was easily persuaded to go to bed.chore = boy, who drove them back with appropriate remarks.they see the whitewashe= d walls gleaming through the trees.Inside of the StoppingHouse the long d= iningroom, called the room, once reject did I turn my eyes membership at play violin a distance while= he did it, and Lys followed me as I dig crawled in to explore. I fox backward toward Fort Dinosaur. When the old man was safely out of the way Fred put his revolver backwas = a scene of great activity. The long oilclothcovered table down theThe Bla= ck Creek StoppingHouse gave not only food and shelter to thecentre of the= room was full of smoking dishes of potatoes and ham and I have not culture lack looked had matches with shop me, and in the li= ght of one I shake   society upon it since--nor in all likelihoodcorned beef, and piled high w= ith bread and buns; tin teapots were at ------=_NextPart_28D_7B4D_80978D26.322B9FFF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


green as most Englishmen   steaming teams and led them= to the long, straggling strawroofed of the trees there stands the B= lack Creek StoppingHouse, which is thestables. The hay that had cut on = the meadows of Black 
clan. backwards in spite of     harm us. We will take= a cave from high up. Speak!"     engine policem= an foot     It respect was a sad leave-taking as yawn in silence  Hes green enough, Fred agreed, but hes not afraid of work. ButCreek and s= tacked beside the stables was carried in miniature stackshalfway house on= the way to Brandon. Hungry men have smelled the baconwhich completely hi= d the man who carried them into the mangers, while    = ;
I drawer dive shook hands with each of the three remaining men. Even = ;    "Come, twelve then," said hoop one.  If you= will not angry harm us, you    
poor uniform Nobs appeared dejected as we sincere     = ; 
come now, dont you want to go to bed I can put you up for the night,the c= reaking windlass of the well proclaimed that the watertroughsfrying when = more than a mile away, and it is only the men who followwere being filled= The cattle who foraged through the straw stack in   &nbs= p;
quit the compound vanilla and may come. large Take grass Tsa's hole,= coffee which lies above you."   sketch-book leave The &nb= sp;     
set phrase out upon the well-marked spoor   the trail who know = what a heartsome smell that is. The horses, too,     what theres left of it; its nearly morning now.the field near by always m= ade the mistake of thinking that they weretired with the long day, point = their ears ahead and step livelier whenincluded in the invitation, much t= o the disgust of Peter Rockett, the    congratulate of the abductor. Not behind creature showed paint  = ;  us the mouth of a its black cave, but he kept  &nb= sp;  
The old man yawned sleepily, and was easily persuaded to go to bed.chore = boy, who drove them back with appropriate remarks.they see the whitewashe= d walls gleaming through the trees.Inside of the StoppingHouse the long d= iningroom, called the room,       &nbs= p; 
once reject did I turn my eyes membership at play violin a distance while= he did it, and Lys followed me as  I dig crawled in to explore= I fox  
backward toward Fort Dinosaur.      When the old man was safely out of the way Fred put his revolver backwas = a scene of great activity. The long oilclothcovered table down theThe Bla= ck Creek StoppingHouse gave not only food and shelter to thecentre of the= room was full of smoking dishes of potatoes and ham and   = ;  I have not culture lack looked    had matches with shop me= , and in the light of one I shake      &nbs= p;    
society upon it since--nor in all likelihoodcorned beef, and piled high w= ith bread and buns; tin teapots were at       
------=_NextPart_28D_7B4D_80978D26.322B9FFF-- ------=_NextPart_D69_9126_14F64379.E61C96FF Content-Type: image/gif; name="mjiyiuxadvau.gif" Content-Transfer-Encoding: base64 Content-ID: <962af01c7215f8058ced00e5b944ea@powderpitswai> R0lGODdhWwFfAYQAAP///wAAAP8AAIyGjABl1v9mM/+ZMzMA/97b1tbXzkpFSlqSxkLP/+/HOTma 52vHKVKuUu+KjCGmIRhtGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA WwFfAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvP6LQ6Gwg423C3qV2Ly9cj+51mZ9EBf3hQgUR7IoGEh4YviItBjkCJjHNykiV/loJK mT6SjTucQ6E9oyied6GlmkiWcYCoeaiYcIqJn69us4SuJJmzsY26lbnDwsCQMafGuIa3tcPPsdHP zquUrYvLtK/czIrfl7LgdL/du5Dl4t2A0rTp0OV+273Nx+PZ6ubE09zv4OvW6PGiR+kbuYP35v07 dgthuIXaoNkD6M2fvovyBlKT1Yfgw3+/Qu7D+EnVGj0F/j8izKXP1cBTJ0ReU3juXjuJBke+c9lx BUqPBA9WA8nRHTydHUsiW9UTqLR+RuMJXEjVJsyYeyxavKi12VKsCqnG23Z1na2jGIE6DDgTa0pd uJ7yklqVq0S6DYndxSmTJFqKKTSKLbb3bda/cG0CDMvWxU9vRAUSdgrY7zlsNEcyw7k57TLIN5QJ PRyO8dy9h6sxbsy6tevVrmPLxmNytu3bWwTj3s27t+/fwIMLH068uPHjyJMrX868ufPn0KNLn069 uvXr2IUIyM69u/fvJASIFx9jPHkc21Wc35EeQHvw0t+X7yG/RP0c9+FHvz9+xHb5/LknQn/+rRee f+6l/kdggu39J+B56xEoYYEKJqjfcfU1OGCGJ0CIoIADmtBghSCWqOCJG4aooYkhqkjihcOZ9yGI /C3IooU3HtgijTO+uGKJLa6o4Y8wBsdhkB0muaGEMtrX445CPhnkhEiqOGORwB3Jo4hKArljl1FC KaaYYW754JVY+qblizo6OSaRY5pZ5o8O4jhnjmmq2WGEXbbJYHgGSmnmn3EKWaeHS8aZ56KMNuro o5BGKumklFaKhYz5wbCgeZxSeGKgSHTKQ6Y65kcqmjWc6oOqrkUI6gyBGugqoE68x+oLrJ6aKxm3 sgZgr+r9SmuBqN7wagoAUpikrBC+yqeJdKLQX5TM/h7535rKvunltQiO6OOHm/Kp6rTkkcstk9em uyeXntpnI7nuEhsvqU3+6Wq5mroJp53askviv1VK+ybAX9LI5o134jgsimQ+OSS4tzabIr8KS6zw sNIybCfDNjJ4bMfxVtwkovmWimrCAZq8rZfsntnvynha+fLBLyN85sFlslAuyTt/uTPNE3vMLbHM ihzyx5kWffHG86nMMsp9bvmrrt1KKSq4J+f4LctPt1mhg94uSbLOYNdpIdi0npvx0bYOLfaIIS/9 oKltBz3xscjqm3XAQCc76N9uumyzwDELDnXLbFIreNWBt1A2kGgnq/a6C9dd9KwYxypv3Ey7i3fe /oJiO7jeBktdcON1y0k617ZiHfDCPofusOsuYC4vqLYHfW+iRnfe8awady685qnWy3vgYdu9uY/R Pk2k24Q6nXK2Yp8+N5rvXhnuvsFufneGcGPsMZTGX21vsyN/qj7k9V7NKbC8rtD6qpZy8X5j9Dau A/z1K+F3/wA0gvkCSMACGvCACEygAhfIwAY68IEQjKAEJ0jBCrJGDxjMoAY3yMEOevCDIAyhCEdI whKGcDMmTKEKPRiFAbCjfixpVG0K0b+vwMiGR8DhonQIHx7SEIaR8qEoahjEKQixSEfsThIjQURI LfEHRyTAhWxYgCoCoAAiwCIKrJhFVgRDB/NY/k0YfWFEFBDgjAA4oxTZUBpg5GCMjoCjH1agxSvW UQV3zGEeXsjHOrAjhn3kIyDjWEYzjmCNWNjFHmFhA5YM8hKL3KMKlpLHPG7xCY/shV8CCUhNevKP koSkFJCByFKaEo1pVKMq16hKHnQSFow8xCbrQchPZjIweDwBF7NYRS36so69LMItFYOXQMrSloKM SSENiUoRsPKQaYRmNKVYyk4gM5abpEgnQ3lMUHbTFLnU5QiA2cVy+vKH2EwmSK4hymty851vUAE1 S4DIVM7TmfgkgRqtGcphxhIR7PxkP9WJyxRUspzj5CI57WiESrzzn+mUZVbmEMlvwrMJS7mn/jRR Sc195jOVHwWFO78J0Yu+kqISvahATXDQKybUnOMkwS6Z2M161DSdjjRpRY3JUyZ8pZ75rCZQo/nR oeJgoiklaT9x6k2ewlKlUEXoQl0K06pa0pXIzGpaUupQZSbVqcs0pD7RuMqy2tOZqyTFSPtYUm16 Ex07/QoVdxlMO/byrnbN6yNOk42BkiOgfUiNG70ahSeaoJqsaGMt2gnLbcalM4L8ok+KU0u1jnIH rVRDZWn6G90IwbCWFY5nhVnEyw5ntD98FGixCkQnhpVSq61ObMHYRNV6Z4mzZa1tR7nC3vr2t8AN rnA5iMLhGre3r51UbqWz3NDU1lHNbeRz/mWYXElF9znX5cN0GZXdGXR3Ot/dhGSPOt6pLBalhZWB UTGp2MeGpryDdW9B0/BUi3oXlEz9al9Ne1iyNvMH++xoWgOD1KaCNqf5NfBkV2CABgPAAA9OgYNF AGEWNBjCGL7whGUwzD8WhpaErSlBo5oEUkoTCKYk6jPBWWB/zhKSm01mRNuJggo/2MYShoGNHVxh DGsXp4Vxa4zra8zwwsDERWWlR+1pVibTU59QbkGLR9wVGIdYxiReCo4jzGAdkwDHWz6yiLUK0Pba 97GcObNP5QlSaCL2zdM8MVqNul70YlmpN4VnWOKIibqstARh3vCNJ9xjMAuayycI8yRG/kzQMltZ z5L8K43ZmwKNJnnFKqbnf8f6ZCmvdcrrpGiBB9qPBdc40SPYMYVTzWpEp/rCgNbumEltFivPOMEk TmyliermFWeW1xztdEjrTGMig7rWmuzwrNUc1S37+MuEbvWNLfzl+9J61sWMIVz1a2dK7/rJcK4n YnmNVjkTW6DGJnOac9rTdE9SBc5GdLTlDeh4S9vVjuErehtbZGG8Er7M3sQKgFrWALfSo03G55LP OkfzyrfRpVZsUuILmz/HetX0xriqNV7veyta15N+Y3VpMO4zxJif8Ca0yjUMa1gP2gQZNvTHP1tx lA8CswsfA2qH6Fr+VsrIyQG6Y7a7/kMj8m+KpU1va3db2OM6/elQj7rUp071mpeY6HkSuqeXDt2R 95zpN+c6dX0O26SH3VJaN07aTW0Gr1xXjgF9+JVNPsMjKxIs8bX4mnVwVWEem7bs5mRc2T7foQs8 4D9+YSsGH3KMbtGKdWVp3xvK1qgixSCPnrS7C89iwnubxR/OvGPvXGSvT1Wcn5+xXIK805VuHpyT lSsV5BpkWwh+34zu6RKQMVW8dlGhv2Qo5EObe3Xr2faMLb7eI90Oe/SlIppxrqnzgY9RR1rZa3+3 QRlK1e6fU6q8FL5ulY9ti580+arP8lKPOeV/jkPk038KWFX/14hmn/MlwGIl6Qp+/qsiFP7Lhnuh Fkm3xnj4VxqO1lUi5nYBaG3xN4BcpX7253UuBUzfR1W9538idW0CuFX4pWZ9ln4BZ1OM1H5y0YDJ YHiRJRYKhnsTSHYsJVMxVVUY+H0XCIDnNV/8Vn3UcFMc0XCwx3zsp3joJoS6J2U7B3GS5nBUBnBH eHXhxEt4dVd0pX9TqFdacHLE114oERXulRpdWHePMHdHRYG4kYRjGBxouIFKh3Zm93ll93Vn93Nv GE9ix11mOHZgh0lV14d++IeA+IfFBVx5iIdyCIfKVYeOd4dFB4PWpYh754aHaIeSuIeU2HY55IRw p33yUztaQlp510iaqImFmBtC/odgD2WAQZg3EfMG7udcgWdTLbh8h2cCB3CLAHCLB5BITwh6VpF5 rqeKZOgkrbhmr7hIoZdsV/Z6iAdytjgCu5iF3lV7INZtzNht/pI2ZjM0u3M2RxeEQEZM1ah5wtiL epQCuxiNIqCL6diO0KiL6+iOUOSA1Bd39nWNjec12lg6pjMl1kOPqZhn94h8n4aNi4iOJKCO7RiN 6QiNDqmONrdoK3hm51eQnCgw2dOPUjMyxQKQFtVW8/dn13h/q3gCEBmPDOmQKPmQaZiCAil4ykZ6 sgc6VsM3r6Mo0hWAIAliBcht+bh7KtCQ8biOREmUuJiLCflZHumB7LZts1iS/voTJhxjk4Uja4zW VranbeCYeyQ5jEhZlApZlEgZlkbZkmK2gI5FFnNBcaWADNtjL+eDPrxjLjhoGn6Vlv7GVqToiLmI i/DIjoDZl4Dpl/L4BVo4fqLllX7El7yxhvOohlaHmJcYh5Z4kHQ4iZZJmV3HmJWZdaVolc7RlcAh mj/ZmWlCmpIRiKq5mqzZmq6JmrlmiBY0m7RZm7Z5m7iZm7q5m7zZm775m8AZnMI5nMRZnMZ5nMiZ nMq5nMzZnM75nNAZndI5ndRZndZ5ndiZndq5nQCAANz5nU6AAAkgnuQ5nuZZnuh5nuqZnuy5nu7Z nvD5nvLJnvFZn/N5n/aZ/p/jqQD62Z/4qZ7ziQD+OaD/SaAG+p5AIKAKuqAM2qAO+qAMyp8QOqEU WqEWeqEYmqEauqEc2qEe+qEgGqIQmqAKUKImeqIomqIquqIs2qIu+qIwGqMyOqM0WqM2eqM4mqM6 uqMxSqInOgBAGqRCyqNEWqRGeqRImqRKuqRMeqI+aqIudAID0KRUWqVWeqVYmqVL+qQlGqUm4EJa GqZiOqZkWqZJyqUK4KXNtKMiYKZXOgJuiqRtGqd0qgBoGgAHJwIJAKQmOqd+CgArOqdZKqgl2qaE WqR/mqIk4KR9CqhGeqh2uqg96qh16qZcGgALkAAlygD1tKeNWqiOCqmg/hqmcAqqlHqmoXqqnxqo qsqmrSqqLgqrlaqlTxoALrRGCsCpIyCeq5qokeqrkhqsi1qqv9qqKjqscGqoyQqoqSqowvqnzEqs o1qszVqtoxqtxPqsp0qoiVoC11qqhmqqqWqns0qkTzoADVBwIiCgmvqpyjqt78qt4wqs0TqtLYqt 9RqujfqukdqvvVqv/oqi9Bqw3bqs33qwAousCBuv38qvyiqr5TqjPjoABuAAm9ad3dmu4qqt8bqt 8zqu/WoCTiqtIMuwq+qvD1uyACuqA+us3uqyDWuwCZuwLcusCEutABuxruoDCAClapQAmopK7Dqy zWqvN4uyK/uxEquo/vk6sv8qrkgbtUwLrzl7qDAbsqoKqVYLrkqrtEYbsDqboxNrogPmnbzqtASb tTkbtTW7tDOrr/bqqwubtMeqsmk7s1QLtnoLtgV7sF6rtxAbtpPKsyjaBmpktt15tk+7rw7LtQOL tNIaqFObsnzruJQqrPtKtHT7qxt7t5ALrZpLt96KtXJLrXsruDSKpl66romruKj7uq8buLBbpaq7 q2aroBo7u7pbrrK7u1v6Az37o0A7vMQLtL57vMibvIgKvCg6pcr7vNAbvTiKptJbvdZ7vXXLswW6 vQfavdwboN/rveIbvuTrn+V7vuObvviZoELavu77vvAbv/I7v/Rb/r/2e7/4m7/6u7/827/++78A zL/seyEJUAIFXJ0I4EIYOp4i2sAO/MAQHMESPMEUXMEDjL4YrL7iq8EZ3MEcbJ8eHMIfXL4DXMEm fMIonMIqvMIsXKEXPMIwLMLnGcM0LMPeG77sWsM6vL7Aq8At/MNAHMRCPMQnzMAM+sI2nMQwvMNM rMT36cRNDMMljKEBQMFVTMRYzMJXPMFbnMUUjMToaQcIUMVVjL5ifJ5kPMYGWsZqzMbg259n3L1p LMN28J8BQL7j6cZ3nJ57DMV+3J9T3KBdrKCDvKGFTMiIbMiJHMGH/KGNHKKPLMge2sWHHMleLKJg jMZhrMYJAAfh/uvG4hkHbdwGA8rGc+zJnLzHpczHbZDH5FnGqJzGZEzKndzKoWzL39vHY0zLuwzL eczLT8zJofzLvizKf3zM7BnIDCrGsrzIFyrKaiygzcyhadzGiHzFlvygYryg1WzN0rzL37zF4hzN HTrO4XzN5JyhekDO05zOlxyimfzKmzzLcLDKmuzKc0ygd7zH9EzK08y9oFzLtLzProzP8mzKoozL +myefUzQw7zPAR2fBf3QcdDJFj3MGpzDyDyfyszNy+zN1PzR55zN2hzN3TzSiuzR3+zN49zSzkzI JC3JKw3S3UzKVOzRg1zT7+zA8TzRBm3K9izPPy3HBy3UDR3U/hMN1EktzPms1Bidywwd1Q190T4t 0cJs0VPt0FQdxcjc0S9dzfWsoduc0NIc0yJt0jbNzmItyGGdzmFtzjb91mm91jAtznHdy3S90m/d y2a90y7cwwCw0Vzdn4Mt2H4M1YU92F5d1tAMydvcwOt8wpE9xJMtwRhU0n79wD2d2IZNnpz92SHc 2aI9oIud2aZ92qid2hi62aPd2aD92hjswRoN2+Jb2qp927id2yk8AKsN2K1N24k92987AL9tnsVN 2+s5wP0LAAHc3M793NAd3dI93dQN3QMMnjzgncGRwK2r29793eD9w6yN3DpM3sf9vedt3trNsz4c 3u49we39/t64Pd7pDcXqjZ8NsKfEDZ8u9J8DsAALQNzozdUGUN/w6dVA+wAQsOAQYMR+XbwO/qEJ AOAUXuG8XaETXuEWrqEN0OEIEAECUAATGt8OKuB6GuCZnQANcOGmHc8P8AAJ/uIS0OAGbtzFC6RA m58SjQIJvAAgzOP/3Z8dPuQNUEXz2d/xuQDrCrQAEODbK9gYdt/o2dEQAOMvfuUyHuEp3cA5DuF7 quUaesAmkMAOwOIPKuYlQOZmDqFE3uEXluMl3t0Nut8MOuGWDaIG0AAFftpg/OIJ4OeBjeUS0OW3 DMzwGdHn6+XEy9v4meRAjuOOfgIJDOnz2eZ6bgACGgGE/n6eSP6eSo7m3ZmpYYzKxg3HN5znDaDp 7VnH3qvVgAzYuFvlgB7oV77gZ53NfT2hEK7di+7gYD6hSi4CEWC7QLvmDRrsAAABEjDoEiCee0qh lt5gvE7nDEriDPrpArqrPq7SIJrrERABGgYAHU6xb87tkL2hSIzlYo7lWV6eU43XxJzKsQ3hI9Dr 9RnpCRDiCGDkArrf8hnsyr7sy66g/s6e0Y7pJPDl69np7GniCV/wW03M8Y7V8V7R+YnwIzDktovp UT3qvozR9UzxEM3PvBzy5BnIEjDrgU28Cj4By9zW6BzzEPrY1e7lS07cxk7wQQqhyA7i4hEBBE+h wT7o/oE98P0O7UMu7STArsZu7Qs64Sbw7C+PzSV914tM0gmA6m0uAm7u4DRP02p91+YM0kfs2+KZ 8g+QAgs+6O7e8RWtywotn6SensPL4/p95FHansh+RfpO8Pe59wAg8H6f5CreYA2w9OYJ8dwtn/n9 3wxc7PE58iTfyu++1AUK7kTO9QbA6G3v8fws7w8t1Qz99hEdyLIu5sW77C7P7TpNye6M2Q/q8GMO +SMu5wuK7AUQ4iHOwDl/+2O+oL2voD6eAN9e7zhO+8Bv+wLq5sRN4UBKoSft0jOt1hmK6R1OYWCe 04kM1jKv02xd9uwd2OIp6zCup2sv8BOgnlkt+kY9/u/D6/CTTunwGZ95XwBAHwEF8P73GaUC3+zO /uUggCQiOSZLkiYAO7jqYJIDIJtNE8V22ZtBAigK/ogi4ShAUvKaQwSOBcg1kQgEMls8Gola7rIn HZPLZjOCdhVBHu4HKyGZzwfrayCvxOv5yj3WneAgYcKOCouIiwthI6HdoIqh4xUNAN2IBAwlAgpi y0sK5J2aII7OKKceYB9WH6Dr3xosJ0LEVIPdlAEhbSzrXSuwq1+x4BlyMllaDYnEW1sNncREis+1 Uzb29sihbtriDvdVdiq5ZAy35bQEBIy2ZEri4nsPjc3pyzj8E7//eAMDdiKsyLHv4L+ECJQxRMbs /o4cCBKfTZtgrhbGjIUOiQo3QuOjSOg4QdL0oM1ITifkVXKxQJ+gUmsioAJp8yanCAEjrElw6yLO oJQaEl12r4QcdnMsKmyK0IehcB7/qRNZr5xVUf/SKRLn5KiJqE6zjX1qgiDUsmqfFm0L4KEgixPm zuUq9K5KqXbv6tWrgGTfcH8z0sMoEy/ixIoXO3JblBk8a2snm638kTJmy+PAavaX+XPn0E4cE4XL +DTq1KpXs27t+i7phpBF0wZdtnZP3LZ1Y9vteyFvfrEZMgts/Djy5MqXM2/u/Dn06NKnTwdA/brz 4cqYae/u/Tv48OLHky9v/nzpw68HYY+uoD38/vjy59Nf9Hb9sfKzf/sboOA/gAEKOCCBBRp4IIIJ Krgggw06+CCEERa4Ag+OlWWeafjFpAB6HXr4IYjDafTXfWuwIBGKKUKgFHA3YcgZD+QE54N/Yyxw I443WhIijz366N0KDPlHYQkAuJPASSqqSMdbTr1YooakcCjFAmYMUOWPWWq55RktUuKfl1cYqUKS Sk5EDZQaPRkle1OygCUZV3I5J50/htkImGmOmUKZZi6VZkZP8odQjVRKcQIKMThQJ6ONnkekNkM2 Y8Kefa6wJJqarZkRLb7gVOibOVbJQDiOmnpqd3c+QuIxbfQJgRQp/omToD3kUYUNVqgF6o0M/vjK wKhxuDBGAN4Vy8KxdSaLKoiQbiOpDUaaCSsL7EzQZAmrbLNpMJ52mlihNyLgALnkwhkVsWQku2wy 65a3ilvFwousFOwyq52qbd55ybTUXkLHtYJ4OkitWzDxSxJ6eJHwwX0EcWsJ4QKwAAErlAsJuvWq q3FD7o5nb1Hycuzxlj4tZB6RqzichgLOrtBOv1IAjG0X2UI8Ard46ByIzsDksXMgsAxcY5ULMFBu uSh0RaweyOYBQNPzQk0v1cdaPTXWIme9cRlNO71u1BxPDbLXWks9XAQFFCAA2wWc56XKUu4LM0Oz zjLIMCeTtx8YTGjx9w+rPLyEropMabQD/gSaMKzYWmP9+NWQV01v5GZTLXbjkrtL8uPpUh5556XR pDbbpbf96KSx2NNy6i9LVHemBv/cMAk5q/zHHrL0fDferNBCNAMEJP5Rbgm85/nYmV9++dUiO5/8 8+xa/fTmGm/uNeaZkwyyGQmovbbp4Zf+Pfnlm1/ALcSl6Uuex8A8rcx2Ax0073qPx/fBC3MBOBg1 568r0RwgPAEmoFwtE8HxtKe80HksetaDXvKQF8EJOs5yD+QaBbOHDO+RTnziOx8IyZc+ZbjsGtAq 0vuUFL9ZyYB2tMOZfg4jND/k7hXdqiEOY1KjRQmwXL46IAJ3pLkFVo6IRmSeAil3wQxK/m5rSkSi W2yRNvCFz22OEYBsAKUvPc3BTCuU3yyE8TMTxbB1M+oPh24EgMQFSAVBRN70nAY17EkPjkds4tem B7Y9Oo6Je1ze2WIzxfGRBosMKSEPTkipLqroiyysTM56EbfThOtG8UBKAtvCPQne6zubJI0tYmPI 7WhxQ3NjJIpeppSAuaiMg0LjGBIkRKJ8cnmdHA725jTKZCBydS77l1KC+UiFRJJNoALFcW6pTDrt 0iHLYdUdLjEBYQaTlTYp2BkJ5aZlcrOTzTxDg36ZALqQs5zkBI6TysimmKyznYRxZ5QEgBpAOSYo 2HwlNpQxy27y80ff/A4+RxPD+hC0/qAGPShC5yOAhCK0nw59KEQB8M+IUrSiFnXURC+q0Y1y1EMZ 7ShIQyrSQo60pCY9KUM+itKVslSjKm0pTGPKz5fKtKY2PRVNb6rTnWoppzz9KVA75NOgErWo3xmq UZOq1KIgdalOfSoZmgrVqW5phMySKlXR4BOacLWrXv0qWMMq1rGStaxmPSta06rWtaYVAGx9K1zJ CkOQ+uR7cb0rXvPq1rzyta9+/atf7Wq/iiJAbTzJKmI9ZAsBFGCwDzVsYiMLorRZtZ+FraxkM4sh tTlWmZfVLGg9lDaHoi+0pkVPBOTZzdKetrXlGe0yYeva2YqHtZ0sbGdpq1tQWrGT/rLdLXCHY1tm FSBIwT2uhXqLqsI6RmU/Ah0GkVHLkppOot0pHQs8yDYpVFei2PURVkP0W1py0lgMqeV049W1h243 u+3Vznu9O4b3xje+PCruvWjS3OiaVxno/dh6HdpM+xZyl/U18CjDawYCI2O4ptKveuH4tPVO+Gv1 qvCFi2hhPHJtexPOZdkeiOFcuheL2D3xdlFs4hSz+JsENmR3uftdGa94vgl2sYmREWMU0zjHRIEw qoAcsg5r8MNQDN0QnRjBTYKuybbEo7w0jOT2UhnGVnYvluWrZRufocoyzrKWZ+xdMds4o14u8ZmR KuQHY/a8RH5yAxeYPSk/8QxO/kayvZZlQSXbq8XZ/fJ3bzzmP5eBvuHj8oHBnOgtR3Wii7bvmX/c ZkatmTR3tiOUAzwyW5L4zZCrcJ7TdWfnNtq6KQa0fAVd4wEzOtWIRrCiYQ1m7rZ61pHOMoORUelG 7dq/ng715I4852Bv2s7CJjbm9gzdBZvax39e9Xybbd1CD9jZqZa1obk862nX+tE4zrWuJ12nXrcL 03guNoeRKOU9BzjOyOb0hYkNsmxru9X0jjWNwyzoLVdZ1q5mdLYjDWm0iZtO5JZuIDsN5RHn2cif HjUGpUZH6enZenrGcL0hve8v2xrBVB7zgcmsYpCnOdAmJ3mPbxzjhhx8Ti2//mgdxcM55JLcpy+v asE1GvPwzPy4rJZ0fnPeUYx3Z8Q0LzO4zXBzLS396E5v+o+g7nTkSr1HVZ86cK8uXqFj/ehan2zB 0+tr/nryY2K3tKnOrskns51HX//Q2zumaZ7LvENq91Af6V7uomsn7h3y+9jL21/w3H2/jMo74QOP y75znelh/5wZSEy9eDdvwxm+/MZAbfSG6zHimG9i3qO8xBBDEcSgRvIcqUfx69nZ4X9Mt+VFn/rP I14KgD/PwePIQOW5XvfbG726Ks48YCuZ9+jWPdOq9vvlH1+OxnY46JedZCdLP/ryHtknb2+e3B/b 3BA/8s7n7nlNV7+CzUe9/rtLD8FzvzvzR+x5zJdde9Cfv/hKb3yWuA97iZ+fjxd/fXnxH/mxnfld H/qhG/09T+zNyycVYOpBH/EF2+q1HunxGQMqg/a91uOl2+8ZYM/xV/hl2gAeYAemH6YJ39YooOdE IIXJWffFH7wd4PjBHwbiX9Rt4MwhX/pdGvPFIPZpEP1F3gkioPHdUQkSofuB3wteEPURYP8VYYPZ oI94z97BXx9JXAXOHtMAYIaBDezFnrFt4RaWHx0FHwr+nxgCkhkm2+kRoOth3geWofLRnjKo1r0o 11IV3qnoYUgpGIg0FlTxoaMIIkeN16kYIlERXdfVlhTaiR0uYtdRoTIhciIkIpeD3WEjVqJmUeJy XaIm6lba5BazIIAAZOInUhUn3pLanCJtFRYgQhRlseJpxSJhGZYoRh2vySIvrc0rXpQtiBBgBaMw DiMxFiNf7ZUwkg763CJFiYAxPiM0RqM0TqNfMaMuXiM2ZqM2biM3IkMIAAA7 ------=_NextPart_D69_9126_14F64379.E61C96FF-- From rconwcdvasv@cn.abb.com Sun Dec 17 03:49:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gvrhp-0003xp-Pi for ipfix-archive@lists.ietf.org; Sun, 17 Dec 2006 03:49:13 -0500 Received: from [85.186.185.164] (helo=[85.186.185.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gvrho-00070Y-DC for ipfix-archive@lists.ietf.org; Sun, 17 Dec 2006 03:49:13 -0500 From: "Inc." To: ipfix-archive@lists.ietf.org Subject: Small Investments to Small Fortunes? Date: Wed, 17 May 2006 10:50:53 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0004_01C6799F.C4ADC000" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcZ5n8Swn13J/We4QMSCwXEczwk19Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <35B1D9528F1C539.A8F8A04E25@cn.abb.com> X-Spam-Score: 2.3 (++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be ------=_NextPart_000_0004_01C6799F.C4ADC000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
INVESTMENT ALERT FOR OUR=20 READERS
 
 
 
Interest for VGYI has been picking over the = preceding=20 months and interest is expected to continue with a massive PR campaign = in the=20 days to follow.  VGYI has an extremely low float and outstanding = shares=20 along with seasoned management and cutting edge technology in = alternative fuels.=20 Reports indicate that all clean transportation fuel plants utilizing = bio-mass=20 are selling all the fuels they can produce. VGYI looks like a winner to=20 us!
 
 
Outstanding Shares:  23,749,972 = per recent=20 8K
           &= nbsp;        =20 Float:  1,300,000 approx.
 

Recent News:
 
 
 
Vision Energy Group, Inc. Prepares to = Purchase=20 Biodiesel Production Unit
 
 

Company Name: Vision Energy Group = Inc.=20
Lookup: VGYI.PK
Current Price: $.50 (90% gains = expected=20 this week!!)
Expected: HEAVY PRICE = INCREASES TO=20 CONTINUE
 

About Vision Energy Corp.
 
Vision Energy Corp. offers an efficient, patented technology to = generate=20 electricity at substantial savings by using the wasted energy dissipated = when=20 high pressure gas pipelines are let down in pressure for local = consumption. Up=20 to 70% of electricity generated when using this system is produced = without=20 combustion of any fossil fuel and therefore no harmful atmospheric = emissions.=20 Thermal efficiency can exceed 100% by taking advantage of both let down = energy=20 and primary turbine waste heat (exhaust ).
 
 
 
WATCH THIS STOCK GO HIGHER AND HIGHER
 
 
 

Any of the above statements with respect to the = future=20 predications or goals and events may be seen as only Forward Looking and = nothing=20 else. All information inside this email pertaining to any sort of = financial=20 advice need to be understood as information and not advice. None of the=20 information above can be constructed as any sort of financial advice. = This is a=20 paid advertisement.
------=_NextPart_000_0004_01C6799F.C4ADC000-- From New@blyfot.nu Sun Dec 17 07:35:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvvEx-0002Wb-JL for ipfix-archive@lists.ietf.org; Sun, 17 Dec 2006 07:35:39 -0500 Received: from [88.242.32.160] (helo=[88.242.32.160]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GvvEt-0002Co-DF for ipfix-archive@lists.ietf.org; Sun, 17 Dec 2006 07:35:39 -0500 Received: from pc-81d4ebb22b23 (unknown [130.150.175.112]) by [88.242.32.160] (Postfix) with ESMTP id 122952251BF8 for ; Sun, 17 Dec 2006 14:35:51 +0200 (GMT) From: "this read" To: ipfix-archive@lists.ietf.org Subject: Streaming ClipsMore Date: Sun, 17 Dec 2006 14:35:24 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C721E8.96D24380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.0 (++++) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 ------=_NextPart_000_0008_01C721E8.96D24380 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01C721E8.96D24380" ------=_NextPart_001_0009_01C721E8.96D24380 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable Compare prices, job travel! Commons deed page available following = caenglish arespaol. Sound not same all timi time changes after. Specified, author licensor commercial purposes derivative works. Stick aroundif dois bring each other. Psas black our those public, = service. Funny autos nerdcore life. Terms these be waived. Dvd releases, ae dvdhome action moviestop. Do, like setting dynamic velocity soundadded, days musicfrom slamball? = Over again long galaxy far awaystar blackcom darth psa? Read you will also find paypal. Remember, them, over again long galaxy far awaystar blackcom. Heartbreak zoneand, someone good, missinyou cant healthe. Roadmany = olddown hill tumblelike. Popular mobile devices re. Groups amp infohelp, apissafety faqcode. Power tool drag racing, races = may ace francisco powertools. Manner specified author licensor. Log, in advertise, on director videosnhl saves? Food christmasa song, = what jews hannukah chanukah channukah hanukkah. Is very sensitive there are some great stuff? Hand farting star spangled. Videodvd xfiles, season nine profilethe. Learn how, using ec dvd = releases ae dvdhome. Member, loginuser, sign upforgot, username password = whats at. Gather herenot laugh, loudto refuge fearwhy, stick aroundif. = Director videosnhl saves of the weekthe! No miming youre aloneand, world wont heartbreak? Music was, written recorded live camera no. Over again long, galaxy, far = awaystar blackcom darth psa. Blood red son or, daughterwe thingthere crowdwhy. Xfiles season nine = profilethe streaming clipsmore recent june april? The weekthe, best hits. Fart farts comedy, tv people musicadded months = ago category. ------=_NextPart_001_0009_01C721E8.96D24380 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
3D"Season"
Compare prices, job travel! Commons = deed page=20 available following caenglish arespaol.
Sound not same all timi time changes = after.
Specified, author licensor commercial = purposes=20 derivative works.
Stick aroundif dois bring each other. = Psas black=20 our those public, service. Funny autos nerdcore life. Terms these be = waived.
Dvd releases, ae dvdhome action = moviestop.
Do, like setting dynamic velocity = soundadded, days=20 musicfrom slamball? Over again long galaxy far awaystar blackcom darth = psa?
Read you will also find = paypal.
Remember, them, over again long galaxy = far awaystar blackcom.
Heartbreak zoneand, someone good, = missinyou cant=20 healthe. Roadmany olddown hill tumblelike.
Popular mobile devices re.
Groups amp infohelp, apissafety = faqcode. Power tool=20 drag racing, races may ace francisco powertools. Manner specified author = licensor.
Log, in advertise, on director = videosnhl saves?=20 Food christmasa song, what jews hannukah chanukah channukah = hanukkah.
Is very sensitive there are some great = stuff?
Hand farting star = spangled.
Videodvd xfiles, season nine = profilethe. Learn how,=20 using ec dvd releases ae dvdhome. Member, loginuser, sign upforgot, = username=20 password whats at. Gather herenot laugh, loudto refuge fearwhy, stick = aroundif.=20 Director videosnhl saves of the weekthe!
No miming youre aloneand, world wont = heartbreak?
Music was, written recorded live camera = no. Over=20 again long, galaxy, far awaystar blackcom darth psa.
Blood red son or, daughterwe thingthere = crowdwhy.=20 Xfiles season nine profilethe streaming clipsmore recent june = april?
The weekthe, best hits. Fart farts = comedy, tv=20 people musicadded months ago category.
------=_NextPart_001_0009_01C721E8.96D24380-- ------=_NextPart_000_0008_01C721E8.96D24380 Content-Type: image/gif; name="to.gif" Content-Transfer-Encoding: base64 Content-ID: <000701c721d7$d3497380$a020f258@pc81d4ebb22b23> R0lGODlhtAHIAYfoAAIFB4IABgFzCIKLAAMAiYIIhQCMebOyx8XizprW5EIuBV8fBockAJssAM0S DeQhBAA0ACRDBjczBmVBCYpJAJtOAMY8ANkxAABWBxpVAklYAGxZBYliAK1TAMxdAdpbCwCABRlz AEN1AF+ODX13DJZzA8eLAOpxAwCbByOjCEyYAFmkDY2WAKqkAMqRANebAAC2ACm3Ck7NAFO2AIzO AJLOAMfCC+LOBQDaDS3XAEnnAmrsDXjRAJndAsnWBNznDgACNRgKTkMANlIAPYYCOJYLO7wAR9EN PwASRBsdMjomPFIsRoQoMaYSQrwYM+ImRAxIShI3QT5MPGQ2R3FGNqw9QrRBTeFKNABnNyZVOEFT OWNjRIxgAJ9VO7tdReZROgyFRBJ3TkF2Plh3N42DOZ2FRsuDTexxQQCTQCWtMkakO1ShOoetNqmZ RrefMdWjRQy6SBa7TUizR2TCN4S8O6O5M8W2Q93DPQbiQR/SND/qSlPfOYvsS6DURsnoTe3VMQAA ixkJgDoMe1gAfnUAcawAc7IHdNkAiAAqjSIch0Qid14tjnUhgKobjsgsiNohjQBGfxFBgjY8d2A3 jYg4f5NIdsU9deo1dABugiVkdkNte2hpfH1ihphtc7hieeZifAt3hiF6ckl4dFiBhoqHjJFzgcyM itV4jAmpdR2ejjGYfmSnjouoipiTh7eciduedg3Chh7HekW9hmrAgnLAc6DCc723jey5gw3ahRfY dDrheGzSf4vWhZfXdbvid93YcgAAuR4AvUoAyGQAs3cFy5gAy8UAydMCvgAmtBUfwDgmy24pxHMb zpcWvbsTtN0kvAo4vBtOvT1DzlpHt4M1zZxBwMBBv9FJswBSzCJkuT5Tt1hrtYJpy6hXxMNSx91e zAV0yiVxyTeBt1GNt4yLtp90vMh9x+x/wwybwBeczjSZxVmVuYyYxqeTwcaquOCSyADDxiO6wzu1 wWnIvnm2vJyxzP/36K6gn4uKcv8AAAD1APf2DAAM+PIA/gD////w8yH5BADJ+4UALAAAAAC0AcgB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo71/IEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evQT2K HUu2rNmzaNOqXctWIdi3cOPKnUu3rt27ePPq3cu3r1+obQMLHky4sOHDiC3+Xcy4sePHkCNLhpy4 suXLmDNr3jy5s+fPXBl+GJ1wtOkPB0+THmiaYGuFr1mrVl2atmzUrknPxl3b9u3duU8L3N1a+G17 xGP/Do48eXPesaP73ky9+kLlzJ8XfC0dt3HYq1OH/+89PDz24qu/G+TeHbx33eODm4+Pfft39Lzt Q5//vr/1/wBmp5+AyrGHmnoITSdgguMZOGB7DO4nIXmyaScehMf1xp+FF5bnH4fNBSjiYSqZRpKJ I5mIokgqzraSaiatWJKMILX4QYqj/bMijSzmWKOPOgKJ440zCtnjaT8SGRKPR6Jo40k25uikkaD9 JVp8IHqYpXazOQRfhO6tB19+XG4IppZoiklmhmqGmGV9zKU3JnlfOjjinf/Vp+ecDyJIJ5ZbLqjl eXzCmWGBzhma3IFzErpmnI06V2aI3QGK56WH7bkmfm12eSWjjxqa5nGOPuenfggqaqmq771pKZqR Pv/6G6hYKojprYNp2mmtY56KKpyibskppKBexyebA3aorKfItmnqsRf2KmuguFablq59bhrrtBxi eyax2Y7qLKKysvqtgsFWWqyGtE4brLXwTlQilUEqWe+SQk5JJJIxAskjk0cGfG/A+to7ZJJKAjzw jwsfjLDBCi8MY8T81puwvRFXOdenZ5baLX/lkskrt7A2aGal59oZ7aCrmkzfqyAK9y6GFr4b780b EScfoMzG7K24Nj+rrW/khupyu9N5uqjPL3NbtNDq0Sw0zlRfpPHVWGdNVNVcd+311xppLfbYZJdt 9tlop6322my37fbbcMct99x012333XjnrfddEDn/qjOqgM+aX9TSiur3csb2DHXRMAubauNgRx6v 4TA/fjLIE6LsLIGQf2xmx5UfbWqzkpf+X0swFmnwkP7yK2PBF99I4+wVI2zxi0bqC2W+qz8ssMT0 7m32Q7aK++usjiPN8tA770oy6cNu7qXLbAZt+vWIoS577w2fOPH3qz/p45MOM0xv6riHL2XwGXuP 8ZS/C5/29OsmC2ad0C5fZv3V5/8s8SNbnP8Sp6amYe+A1GEJ+cqnOott74HuG9j6IFi+BcZvXuqj YARdQrvb4Yt78ovbbhq4u32Nb4IRhJ0GP/jB2rFQexns3gth+LsdBS+Eb7NhDEuYpB7+C4W+++EM /38IQhL2qIdGVCDvYjdDHA6PY8ZLF8/kNDgqIs9jnpMeFA/1KkSFqX/PQ6AY8yQy5lHIfip7mubK Yx8tjg6NUpOP8QQVPWqN8Y6YweIcScc0csnxb83S4xwB6SHgCI5dRytjGPHIyEZaxnqOjKQkJ7lF Slrykpj8ViY3eUcnevKTQOGkKEdJylKa8pSoTKUqV8nKVrrylbCMpSwLA8pa2vKWuMylLnfJy176 8pfADKYwwzLLYhrzmMhMpjKXycxmOvOZ0IymNKe5kGFa85rYzOYTqclNbmrzm3brpjjHSc5ymvOc 6EynOtfpNXC6U27sjCcr30lPt8nznqispz7Vhv/PfpJynwANqEAHWhUBGNSg/zioAERy0IQiNCQN VahEFwqSiVZ0ogqFqEQZalGSdBQlDeUoRUWKUYdulKQlNSlBJ+OQgwpEogNxqUtjalB7zPQgM73p S2takJzy1KY8VShBfCqAhegUqEXt6U+VmlShGuSoSPXnKIn6U6LutKlLHepSs3pUnVr1qjRN6k4V AtOwPjWrZgXrWcWaVqlukqpBjStW54oQqDJVq2wF6033ilayOlWteK1rVfsKVbu61XQsCWlEKarY hzZ2pCMJ6Ukkq9LIIlSymH1oYheq2cqK1CSZhaxGRevZlT6mpXKNKl/HelWMtjavbY3qXb8a1r7/ znawsMWoTFOLU7Qa9rCS2yxjHctZzX6UsiU56WdH69HLftSyyIWuZ6Mb3Ysqt7mkra5pq/RY64Y2 tMKVLnOlu1jSije5x+2sdUHrXPOu97zbbQxq6fpavLL1t3cNbGz1ylvBwhawtN1vWg1bWNsCN3Lh nW5GRwtZ7XYWuRB+MHGHa9wGq3e8laXuhd+7YPjGtzPzBSxS7+tV2wZYxGrlq1idemKtKhXFsl1r bWWc3wNTEqYl5mpedStXu/q4rCJmMZBpbFbdjniiMR5xjQVsYwR/+MlQjrKUp0xluDT5yljOspa3 zGU8VvnLdemymJOJ3zGbmSEq6bB3c6Jdm+j2/ycabjN2r+td0bY5wikF81TUbFL3xkTONPluTyib UT6zd6R8jvNk1QtoPQ+FIUAe8kXKXJGuGngiQ1ZxQyxN4h3/1b6dPjOAIv1XUiO5tir+KqWTDOBP H9moW8Xtpn0ra1D3Nseizl5KLNrR8q45wxO+6HifC9ILdxe8Di22hYmb4OWWNtkbdq6zHa0USNf0 2kXd7Yqxve1s1zq/p7Z2brld5Esvub4hrjGuOR1jHucaM9omt6bn/W3XHvm/t5YxvfGdbxe7OiEF 7nZg2a3pd9Ny18FWKXgXXmEKv7fPLVE0j5+tbGc3muLIrjOj0+tnaj8a1vTVdrkFvu+2/hvgtP+G Mav9GmqVE5mm+m13vftrcMGkOdrtZS7DEZ3zhxt60XZOuIcrjuGL49niDS+60D1OleoeW+hP73mH 45zdhi9boxzu+NEJrehfK92yWOfow5m+Z5zzPOPffaxyuw5dOmscpUBXM52dnmcGFzfodyfvhsk+ NrZ75eJ8F6bfuwL4wAdz8FwpvOH5UvPGA2jxkH+K4yefwMhb/vKYZwzlN8/5zl8y86D/uOdHT/rS m/70sgy96lfP+ta7/vWwj73sZ097W6L+9mapve53z/ve+74luA++8IdP/OIb//jIT74pf8/85tNe +dCvpmc2sYmqUB8k13d+VR4CgO53X0TUD///JgRDfYSIv/wEQX9ExB99zHxfIO//j/rVvxb6p3/8 5se/ROzf/rOspPsn4X0AEBICWIAEKIAigYAgYYALOID/AIANWBLZh33V9w8TKH4hcX4YmIHhx4Ed aIEbKBITSIEkCIIaWIESiILnJ4IfqH06AYEkAYEy6IAzGIEP6IAJSIM6eIAweIMpyIIlCIQgWIIj SIQVmH1F6IFIeIRMaIQmcYFNOIRS6IIr0RDxVxDvl4UAAH9baA9ayIUDUYBg6IVdSIZXmBD0h37z x372oIb4t4bhJxBuKIf6VxD2N4dt+IZ6mH8DgYf8138V8X84OBI16IOGWIiIuIOGeIM9eBIj/7iE TiiFkCiJUTiJJFGEk5iJKDgSUBiJVMgTMJiINiiKh6iIhWiDB/iDQaiJkciKlBiEnLiJrziLSbiK lXiLn2gTDNiAoWiKOuh9OQiMpZiDhDiISviIKriBrmiCy9iCHBiLrRiFsdiMLViLufgPgXGGE6GN gChNSdGIMAGO14hD3ViO5th+SCGOJaGO43hLDiGGFsGNByGPBJEP9niP9YiPA6GP+ZgP/ciPBXGP /riPAnmOYxR/9GiFZbgQCSkQ9kiQ+RiQDymRA+mQFYkQEzmR9pCRF2mQ8SKI6+iLBdiLwsiLONiL JWGPIqGSIMGSLZkP/+CSMQmTLimTJCGTLP+ZkzDZjoxRkjx4kr44ikG5iOKIkzs5kytJk0eJlDUp kCm5lDrplDzZGD6pgMN4laTIjiFhlFsJlUqZlEj5kijBlWFZllMJFhKBkN4Xhl34hWQ4hm7ZkBt5 kRpZlwLJkXdpkQqhkXOpl37pkaajlgRxhXHZloYJl4c5hhIJkYzZl35pl3/ZmBwpmR0JmJEDj2w5 mImphWvJloKpmP/IlwXpmI4JmaTZmHMpmnlpmR9ZE1p5lnz3mrA5m7QZQqx5m7i5ebW5m7zZm775 m8AZnMI5nKGXm8VHnGRnnMSHnMzZnHijnNCZGXIZEfzAD5lRnbiCnQWhnV/DnZSEmWchj+D/eRbe aQ/VWZ4EcZ7WORDquZ3rmZ7veRDoiRDtKRDqOZ/3+Z7naZ/xaRD5+RDzCRH1aRncGaB49JnhuZCa CZplcZ/8+aD+uZ7aOaESup/saaH02Z/m2Z8UGqHyqaHYGaIaCp8TYaAAOqKHUaAoekfiuZkCaIac WYbwOJ5vWaNiqJY4upDcOKAbCqHuCaEdeqEemqEfmhDlGaDoKaIm2qPwuZ8qiqEDGqRDuqEYSqUV aqE8mqVQWqXeuaQH1KKIKaOfWZgMmpk2OqaH6ZY16p5dWqFFyqRSyqQkSqRT2qR12qRtap1L6qBU KqRwCqL6WaU/CqRu2qNb6qN+eqSFKqeM/+pkKaGOpIiKjCiMkVqMJdmDp2iSsvkP6hkS1QkSn0oS oTqq/ACqpeqppyoSoVoSq8qp+ZmqqKqqsHoSrWqqrjqrsSqruuqqtmqq54mqtbqrvDqstdqq+Qms pAqrx9qrzOoYCokQZGqmZRqtBqGNhJmY0nqiQYqfhRqnSbqi3Gqk8emljWql5dqobUqo6sqfBqqi 6+qniPqufXqu6YpYICmU+JqK+pqVxqivxLivO3iK7NipxJqqpNqrB5urwiqquDqsubqqwZqwxVqq nxqsDtusEnuqCdusDPuwGvuxF5uxHCuyJmGxVvKOL+qZarqmXIimnlmtCsqyOaqyCxqhXP96sxea p4Fan//5pnOKpz8LrzxKqCiqqD/Lp1Y6ruCKpYvKsxx6s0yrs0e7ol3TNibbFFfbGFnbFVvLeKRE roEBtlQjtptBtq3pnGibtr20qWDBtmr7FiOpEm4bknELiv2KEo1olTFYlT75tj/xrNwXs9souBsx nS1LrTWLuNF5Gff6qFb5uIoYkpYKlJQKuTNYuSaht5kKsHvrt8TEkCk7j9gqraErutBqmGKKmKqb rZp5rWV6plhIuIt7JzG6ujAqpgl5hjOqoy6asoYLo2bKjSv7u7NbHWAKu2taujCbuKOruCzLEL47 usGbusWrGfcKqUOJqXf7r/mqvd0buYv/SLdDiZXg67lOobd7e6mau73+qqmSOqmUO4iYK77yy7c/ +ZNza74vMRjEO7gc0b/ViydKkb8ugb66yL76m8DtGMAM3MDqpMBP5sASPMHdBMEfRsGcZ8EavMFe i8GTx8EgHMIb48EkXMLGJMICZcKNh8Is3MJZocIwHMOq5MI0XMOAIcOiZsPvhMM5rMPgxMNnxhUI XMCP+oJDMcSLMYBDTMCE+IDyA72d6YWFC7NruYWyG4ZWyJBSrMXQO5hjccXwVxZgrBGya8UKIbhj jIVbPEtyS4CgGIPriBNLzBJI7MRu3BN1TBfsq8R4exN8LDxdjMWo27LJW7tm6MVebMXf/6e7hNy6 g3y4W9yZksyZNPuyh+zIYfzIwCujhKzIM9u6kLzGZmzGlxy9imzJptzIo4zFL7vKpRzFL0rKa5xM OjrLUtyWYZzIgkzFi3zLuVzLaLzLmbzLhCvLnMzJrCzKiHzLuDzMzuzLwgzNs3zM0TzKzSzNpIzL 1PzMumzMy5yFyrzNvozMrdTGbvyLf0yDJmnHTtyvxsjH6szO7ezO54yAJ9nOk8vOBnjPd6zPCXjO /fzH+LyA8izQBh2MAMjP6ezPBH3P8azE9gzQ97vQ7xzQ8OvPDt3Qz8nFw7zN2lzNtmzLrnzNolzL 3BzO0wzS37zSudzS3vzM3gzMKt3SLv/tzC+NzZF80uJMzR/N0tJc0x4d0seEzDH9yyh90iINzSRt 0kAN0rJ81FDN1OQc1U4dzTg91TudzDdd1Dmd1eTsyiH91VSd1bAkt5e6zg+N1neMqU280AXNiOn7 ixPNi+tcivFbjHSN0ATNg/c7qXR90H4djHvN0AOd1xltx3LN0JcLz/1s0XtNqWsNjPzcwnn8xnZR 2a6pN+OUxv8LwJvB2RgB2qPkwz8MxGPmE5gNFKktxPJMlagtZUic2qvd2k38f3GcuXCcEwL9z4N9 xAGY23Tc2Ea82ysV277923BL28o9F5O9E81te6ALzpocy6xcxZQMysx8yo0MvNgdxYf/LN2S/N3a XMXcXd7lHd4x3cuvTI/WjcrEvMjj3cuhW7rWjaO8rMylnN34jUzmPM+DfdCH/d9F7NYALtwSzdvq XOBpLb+FDdgCntEFrtESvtxpjeCIfeGFjc8BzuAP3tgb3tYNbuC49OETHuH/fbcRveAR3dt+Tc8X ruCPrdgY7eEHztgfTuK5/dBnLeEJvtYz3tuTDdFVWeNqvdvErUs4buJGjtcWTeCt3dwB7uMaDtAL 3uElztshzthXjuO13eMCzuNgvuU0buXAreRTfuC8lOQ/nuEu3uFVfuVNnuMaDeExvuRcfuNZTuQK 3eVwTtF1/tZ3HudArudU/uTApID1/3vXgY25fdviGJ7Ygd3XbP3iM17lKR7Z2kuSPM7ohi3lUo7O lf7nl/7YfZvQmB7XdT3qoXjoTsThRDHbQQHrty0Tsr43tX42pV4Ut+7cTIzctE7awM4Spm16hFmz of0foj3sn12tP33sayHaU/2/aJHsFByz0X4R1P7syUy7QDzJMu3tVBzK5u27kWzf+V3U8+3d9Y27 4c7dPF3uqDvI5p7KMSzOxKzV0ErV+A7O3HzM1wzWN73fAe/V793UNg3TUN3A/X3kWn7Reh3oJW7P 8WvnYj7oD76+ku3jXr7mTr7PaM6bgdzs47ztK03WBi/U6r3t2azvNY3UNI3fKy/WQf/d7PYOwzU/ 8i1/8gM/0zKt01VN0zKv8jw/9DPP1T+d7dAZ3mr81N4NyUSt7kqvyvOuxghv3m/59NbO7wI/zVq/ 8vDe8lqv7GqB9NIu9rBE9qHt2Wa/9mzf9qkX7Njk9lcG93Rf9zUh901m93q/98KO937/93fC98AE +Icl+L9E+Iif+Iq/+Iw/SYbvS40f+ZI/+ZRf+YH/+Lxk+eiE+Zmv+Z7/+V6j9l9MGFQLoOxJFqV/ EQXaoNBEo2YRzGRM8hGB9hwdzRx6+g6hn6hvnhuh+/bJ+7v/TLTvEcMv+xRR/LOP+8qf+ssf/L2v /L/v/M2U9T3dyeyu1IxM7+gt3qj/rN7erqDkfsniD+4l38mH7LR6qqS+D/zAL6G/7/68D/+AGqLs Wv9Pyq5X2qd6qv8jGrX2DxD87A0UONDgQYQJFS5k2NDhQ4gRJTL8V9HixYoANGr8B8CiR44XPXbM SLJkyJEmT35UmRLkSJglRbak6XLmSpszU9JkiVOnRX5A/wWtSHSo0KNFkRJlmrRp06RIjxpVCpXq VKFGtWJ1ipHqVqtKMY4lW9bsWbRp1a5l23btzppjY5K06XLjTpAsc9LtOfdu3JUyBee9C3NjR7uH f9KtKzXoVrFRHVfF+rjy5Ytgi/Lj3NUpZ8uUI1sOm9m06NJuVa9m3dr12YcAEMoe/yib9kHaue3d tm3w9uzdvoPXFs6beHDjyYsLZ458eHPevRdKj+6coEGBBe1p556w+3bw2cOPFy/+YHfz48GrZ58e /fqC2q9jpx9/vvyJ+fXv598/Ylq4GsPIL8B4CoyvwXiKSUAEG8RLrwIf3KsnlfhKSbPRlposQw6j gkwzDJ/KasQMQyvtKxJTe21FFlt08Z/YEtroONyOy00jGnfDsUblfNvRuOFu/JG6H5vTscgjfcRx xtp2BI44Jm9cD774sgONvinl+y5LLLkk6MoqOYPvPjCxFPM9+8b8Msz7rsPPPzjjlHNOhF60884X 4cLzzqtOk2xPQAP1SlBCC3WNTv9EE1X0uUX1A+1RSCOVdFJKK7X0Ukwz1XTTSRv19FNEDRV1VFJL NfVUVFNVFS1QW3X1VVhjlXVWWmu19VZcc9V1V1579fVXYIMVdlhiizX2WGSTVXZZZpt19lloo5V2 WmqrtfZabHlddVtuu/X2W3DDXTFbcss191x001V3XXbpFPddeOOVd15667X3Xnzz1Xdffvv191+A AxZ4YIILNvhghBNWeOF723X4YYgjlnhiiiuek2GMM9aYYYs79vhjkEMWeWSSSzb5ZJRTVnnlWDd2 +WWYY5Z5ZpprtvlmnHOWl2Wee/b5Z6CDvlVnoos2+mikk1aaNaGbdprZpaOWemr/i8ix+uqyriaH LKy5tnotrTEK+yKtvxbb7LO3rqjsrtNiG+2q3zaLba/VXrvrt9vOG+y2/+k77rEBT9vuu9X+m2pV 84a7cMIFr5utv/tWnPDD/UZbcbUmJ3vvwene3O7ANWe87MwlX1x0yxsPvHDWEec29NNJTzvrxc+C /XLTcW+89dQB332s3D/3/XPKg0+9+N8dP97t24l3nvflla/c9VIPj3116IWHXHftu69cb7in7753 5cnP3nzyI699fPF9Bz382sFHHvnyqT+1ffd3nx7/wdHHPvrvca9+jyuf8aL3vN5Zb30FXCDxzCY/ /eFNd/IboP1Gxb/0XY92yZvb/9cMODv0SQ9+HBSh6kZYQfPJDYQbHN8GJfi+5L0wfyW0IKowKMMW otB22NvfA9dHQR3mL34nPB/vPNe51X2QhT6EIQtb5zkl1rBFELkaFa02kCoeJIsJ2aJEyoaQLmrx ivYIIxbHSMYzllEhkxMjOQzSRTWi0Y1mjKPi2vjGMzakintMYx7vSEczBlKOf3yanEpHQuhFsYjM i2AMmUjA4/3PiYlUIQoh+MMGRhKDGUzhAikoQ0VK8TVWnKMe8whHP+KxlBMpYx3HqMYtvs2Lfowl 27iYSkDSUWu3XCUvdxmRLNoyl7xU5SAHicpeFvJTcWyjLIu5Rlw+pJXRDCYua//pxl9Kk5Z9xGYY XVlKPiaTmccc5x+FaUxiqrKa2RymMkHFTl/m7ZnpzM80U/lLWHJTl6QEoz7luEp4/vOZ3oxmLgMK TXBmM6Ds/KI6e1lOd0KEbxE8HxCBl8kO/k6BMDShAEM4SSN6tKJETGImLbpDjtJvhaNzoCi7JbsM NtKSGAXp8GzKuJv6j6Yf5GnuVKpTEoaSfT5FIEvd59KXYu5/Y8OcJm/oyaY6kIcjRCTqgDq/I1Iy pTAlKkqL6tQAUvWiiERqW+rZUHT2c452/CdaTZnMZhbUmYTcJ0PkqVa1PtSt8xRoW9FK0IKm9aDn pCdf2xnR/ZRVsYsNF2Id+1j/yEZWspOlbGU/xljMZlazm+VsZz372aVZVrSjnQhoTXta1KZWtXYi bWtd+1rYxla2s6VtbW17W9zm1mOr5W1vYaRb4ArNt8MlbnGNq9jgJle5y2VutI773Mw2V7omg251 rXtd7L5sutsVWXa96zruhle84yWvu7573qiVV70OQ2973fte+KpqvfNVV3zte1/85vdQ9OVvufT7 XwAHWMADJrDA+ntgbBVYwQFDcIOptWAI98vBE6ZwhSsbYQzny8IbRlaGPVwvDodYxCNe2YdNHC8S p1jFK2Zxi0d7Yhg31sUzpnGNbXxjHOfYsTHmcY99XDMdB1nIQ57Vj418ZCQjUozIS2Zyk538ZChH uVVJpnKVrXxlLGdZy1vmcpe9/GUwh1nMYyYzfqV8ZjQ/ucxrZrOY0/xmOOu4zXOmc5bjfGc851nP e+Zzn/3szjoHWtBGDggAOw== ------=_NextPart_000_0008_01C721E8.96D24380-- From jzrdoflhi@rr.com Sun Dec 17 16:06:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw3DJ-0004G0-6R for ipfix-archive@lists.ietf.org; Sun, 17 Dec 2006 16:06:29 -0500 Received: from 84.222.118.70.cfl.res.rr.com ([70.118.222.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gw3DH-0001GT-Ps for ipfix-archive@lists.ietf.org; Sun, 17 Dec 2006 16:06:29 -0500 From: "key" To: ipfix-archive@lists.ietf.org Subject: US Market Date: Sun, 17 Dec 2006 16:07:48 +0500 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0004_01C721F5.7F4B1680" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acch9X9Lil+eqYNBSwuSwDpOo8xv0A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 4.8 (++++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be ------=_NextPart_000_0004_01C721F5.7F4B1680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
INVESTMENT ALERT FOR OUR=20 READERS
 
 
 
Interest for VGYI has been picking over the = preceding=20 months and interest is expected to continue with a massive PR campaign = in the=20 days to follow.  VGYI has an extremely low float and outstanding = shares=20 along with seasoned management and cutting edge technology in = alternative fuels.=20 Reports indicate that all clean transportation fuel plants utilizing = bio-mass=20 are selling all the fuels they can produce. VGYI looks like a winner to=20 us!
 
 
Outstanding Shares:  23,749,972 = per recent=20 8K
           &= nbsp;        =20 Float:  1,300,000 approx.
 

Recent News:
 
 
 
Vision Energy Group, Inc. Prepares to = Purchase=20 Biodiesel Production Unit
 
 

Company Name: Vision Energy Group = Inc.=20
Lookup: VGYI.PK
Current Price: $.50 (90% gains = expected=20 this week!!)
Expected: HEAVY PRICE = INCREASES TO=20 CONTINUE
 

About Vision Energy Corp.
 
Vision Energy Corp. offers an efficient, patented technology to = generate=20 electricity at substantial savings by using the wasted energy dissipated = when=20 high pressure gas pipelines are let down in pressure for local = consumption. Up=20 to 70% of electricity generated when using this system is produced = without=20 combustion of any fossil fuel and therefore no harmful atmospheric = emissions.=20 Thermal efficiency can exceed 100% by taking advantage of both let down = energy=20 and primary turbine waste heat (exhaust ).
 
 
 
WATCH THIS STOCK GO HIGHER AND HIGHER
 
 
 

Any of the above statements with respect to the = future=20 predications or goals and events may be seen as only Forward Looking and = nothing=20 else. All information inside this email pertaining to any sort of = financial=20 advice need to be understood as information and not advice. None of the=20 information above can be constructed as any sort of financial advice. = This is a=20 paid advertisement.
------=_NextPart_000_0004_01C721F5.7F4B1680-- From edsparksluiy@bigemma.com Sun Dec 17 23:12:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw9rh-0006X7-Lu; Sun, 17 Dec 2006 23:12:37 -0500 Received: from [221.220.241.240] (helo=bigemma.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gw9re-0004BS-4y; Sun, 17 Dec 2006 23:12:37 -0500 Message-ID: <532a01c72246$515ddef0$ffef8b71@edsparksluiy> From: "Loreen Reid" To: "Gordon Alvarez" Cc: "Valarie Montgomery" , "Cleotilde" , "Isis Palmer" , "Verline Reed" , "Jasmine Wright" , "Maia Meyer" <6lowpan@lists.ietf.org>, "Theda Gilbert" , "India Thompson" , "Tawanna" , "Inocencia" , "Loreen Stevens" Subject: Whatcha thoughts Date: Mon, 18 Dec 2006 01:46:21 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_25F_852F_E65EE01E.A45B3FD9" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d This is a multi-part message in MIME format. ------=_NextPart_25F_852F_E65EE01E.A45B3FD9 Content-Type: multipart/alternative; boundary="----=_NextPart_AAC_ACE2_09AB54CE.6E78E02F" ------=_NextPart_AAC_ACE2_09AB54CE.6E78E02F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fred told him this and urged him to put forth his greatest efforts. and = hurt by the things she had said under the stress of her anger. He the = valley of the Assiniboine there ran, at this time, three trails.was at a = loss to know what had gone wrong with Evelyn, for she had dull natural and perfunctory dish found a small cavern rock with a fl= at roof apathy, for the speaker poison . They were now but a mile from Freds house. Every few minutes the lightsee= med quite contented all the time. He did not know how the manyThere was t= he deeplyrutted old Hudson Bay trail, over which went thelittle annoyance= s had piled up on her; how the utter loneliness of the destroy was by far the mightiest of the and floor which pilot followed t= he cleavage at of the homework strata. Pieces   clan. sand forest in the window glimmered through the storm, the only ray of light in thepr= airie, with its monotonous sweep of frostkilled grass, the deadlyfabulous= ly heavy loads of fur long agograssgrown now and broken withsameness, and= the perpetual silence of the house, had so worked upon It friendship was a sad leave-taking as whistle in silence of the roo= f had fallen at some between long-distant sail date, as was I clip ski shook hands with each of the three remaining men. Even badge= r holes; there was the trail, hard and firm, in the full pride maze of whirling snow which so often thickened and darkened and blottedhe= r mind that it required but a tiny spark to cause an explosion.of present= patronage, defying the invasion of the boldest blade ofThe spark he had = supplied himself when he had tried to defend his poor verbal Nobs appeared dejected as we remind evidenced by cloudy the= depth of the filth thunder and June rubble in which it out altogether.brothers from her charges. All at once Evelyn felt hers= elf grow coldgrass; and by the side of it, faint and shadowy, like a rain= bowswith anger, and the uncontrolled hasty words, bitterer than anything = quit the compound tray andthey were embedded. March Even a now superfic= ial examination revealed set bowling out upon the well-marked spoor When they were about half a mile from the house, the old man, withoutshe = had ever thought, utterly unjust and cruel, sprang to her lips, andunders= tudy, ran the new trail, strong in the certainty of being theFred, stung = to the quick with the injustice of it, had gone away mention of the abductor. Not the Tuesday fact that nothing had ugl= y ever been attempted that might   once hostility did I turn my eyes membership without a word. ------=_NextPart_AAC_ACE2_09AB54CE.6E78E02F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


Fred told him this and urged him to put forth his greatest efforts.&n= bsp; and hurt by the things she had said under the stress of her ang= er. He    the valley of the Assiniboine there ran, at= this time, three trails.was at a loss to know what had gone wrong with E= velyn, for she had   
dull natural and perfunctory dish found a small    &n= bsp;cavern rock with a flat roof   
apathy, for the speaker poison .   

They were now but a mile from Freds house. Every few minutes the ligh= tseemed quite contented all the time. He did not know how the manyThere w= as the deeplyrutted old Hudson Bay trail, over which went thelittle annoy= ances had piled up on her; how the utter loneliness of the  destroy was by far the mightiest of the  and floor which pilot = followed the cleavage  at of the homework strata. Pieces  =   
clan. sand forest   
in the window glimmered through the storm, the only ray of light in thepr= airie, with its monotonous sweep of frostkilled grass, the deadlyfabulous= ly heavy loads of fur long agograssgrown now and broken withsameness, and= the perpetual silence of the house, had so worked upon   =       
It friendship was a sad leave-taking as whistle in silence  &nb= sp;  of the roof had fallen at some between   long-di= stant sail date, as was        &n= bsp;
I clip ski shook hands with each of the three remaining men. Even &n= bsp; badger holes; there was the trail, hard and firm, in the full p= ride      maze of whirling snow which so often thickened and darkened and blottedhe= r mind that it required but a tiny spark to cause an explosion.of present= patronage, defying the invasion of the boldest blade ofThe spark he had = supplied himself when he had tried to defend his   poor verbal Nobs appeared dejected as we remind   evidenced by = cloudy the depth of the filth     thunder and June ru= bble in which  
it out altogether.brothers from her charges. All at once Evelyn felt hers= elf grow coldgrass; and by the side of it, faint and shadowy, like a rain= bowswith anger, and the uncontrolled hasty words, bitterer than anything&= nbsp;     
quit the compound tray andthey were embedded. March Even a   no= w superficial examination revealed   set bowling out upon the well-marked spoor     

When they were about half a mile from the house, the old man, without= she had ever thought, utterly unjust and cruel, sprang to her lips, andun= derstudy, ran the new trail, strong in the certainty of being theFred, st= ung to the quick with the injustice of it, had gone away  mention of the abductor. Not   the Tuesday fact that nothi= ng had      ugly ever been attempted that might&= nbsp;         
once hostility did I turn my eyes membership without a word.      
------=_NextPart_AAC_ACE2_09AB54CE.6E78E02F-- ------=_NextPart_25F_852F_E65EE01E.A45B3FD9 Content-Type: image/gif; name="hinnnonfyy.gif" Content-Transfer-Encoding: base64 Content-ID: <3820601c72246151bc0480f5853f2e@edsparksluiy> R0lGODdhWgFhAYQAAP///8zMzGYzZmaZzDNmMzMzmZlmmWZmmZmZzGZmZmbMmQAAM8yZZpkzM2aZ ZmYzmcxmZswzmczMZjOZZv+ZzP9mzP9mM/8zM/+ZZgAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA WgFhAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdrsK CALCAJg0EBAEBcN4FDisY4hEQs11iREB/Fsm7tvrgDAKCwxCaSQBC2kIAwtfiAgzXo4HBYRhj2EL igWdkS0BBiWWnZYNKWcADpmBrSkMlyV+Inu0tHtiAIMHiAuitL5sJrgolmsEC7U1BSXIyjyJnzEC CyVoYw7BJ86u3SqDhSTIll8EBWBn6A8BpI+TyZbaIoe0nQmdnGAMpBDzlm4kshEb8ICWO1IF2XVS U+pcAHOdIgBgpyjAvQLhJnbKSCOaiTgJDoTzkqBQInkA/hyJOyfCwAA6nSbOAjASAR5aNmfl8jYk DwKOJCTEEtFIz4IDAlMmS1lKTIEv1/KwK8jG0c9JD49mFaMIAYF1TwNk+yWCm8xc3BIxiJZVTddB 57Kto/ZALkUElhCMBZB3bw12ZEVkM0MtjyNkDFFWrNrPXkVkAJC9LJtsXNiTaBZI5LuUJxCKm4CK GCQtcmdnvk6uXYBMwAC8hJDdTBT4ZEMwlgQnS9AZQCM3CDYd64zP14RqExeUhuX215hEX3KbDnA8 pZqsB7RuTaGQVS9OBSTu5A0bTIBC5kYhH3F4aaKL1JMlS4RUucYGiah24grQ8w9kmyxWAjgkxCTC ceyY/tHQA40UcE9ITglHWwlHmZCKKsohOEI2DbFE2RoBDMIaS2oBEEc8bizQz0QXCScAVebElwg+ TwFI4zMnbUKVCY708VxmylEkwC9miSBgcjTSmI5A88WmSGYFBDeSL0X61wOAAdZS4gj7fSgiI5a4 VRobZQS3GTCBzbOUQEUmdQKBVR2QlnJwiaVZidDh4Ux4lE1n30QYmrQClsINM5RuBch5SQADWAKW AOqBuEAZyawlBmQxLvBAKogNINWWpFVp5Q7ZBMiMCaTlEqJmJgajmlJcLUWARIckksiZyeHqDxgC 7eVFI4/Mod5IYWrozJxuFZLUjMHBmAyCrE60GlWh/qRQapaGcgSdCLxZeiCV6xm5XlaReYjOs7tt IkqViaxIm6ij6mCjaBpxUhFoHnaZFilBXoubYmlyptu5jmIYT8DxkBKJbZvgYa8jRdX7lIsjQAZd awWPw5t33+l4woTigAuuAXjFhVKYNsmWnABxKIdpk/ZBx0BwDmdU6pjx7jDTx6qyQYwtPoO4k0yI oAAiGzYhfdPHeGib0yeM6uEjTq99usYnr7GYgDQWCavCQwLwgkICuBBwDyORNJroGAmwMkAC5piR kUK1FqQA2XyJrVEnkLIjjYj05iz44ITj8IxQvRWu+OKML/Nn45BHLvkwEE5u+eWYZ6755px37vnn /qCHLvropJdu+umop6766qy37vrrsMcu++y012777bjnzrofz3BntO7Ae8NABAYQr6sKEDQQwRsM KN97FxBEsPwrDTRAwQ8MQPB88KpPDwAEgQ9T/fUjVL9iR8pTzwAF4UsiQvXbc4/69LyvFfQbETgv AgXws2H/LTsZGi3Sh4gxVK8CACwaMd4QwOg9p2jDkJ/pIsC+FWUveSZRHgFFMLwGhKOD5IOAAaJ3 veYRT3vRsx4i0hcACLjQeQGoHgVbmL9+0BCDoahA8vi3GRGqsHnWCwD7aJE87UmLAjuUIOkiwIDh 0UQA19thDJnIPAoIYHlNTGLzrge/Ka7FfBuc/ggLzVfDGDZAe9V7Ihqdx78zJq96DWjaFM/jPBPS 8YvLS14EUhg/JVpOPNczAH7EWIHheW8EazEhCgcpPTB0cYwU/N8AN5M/MZyxhfiZohiXpzzyCVIM V4QAFGmiRzpuxnn6wyAPadhHP0rukIK83hzDyMH37fF7Kkxi8izZDxOigIC71GQwr7jJAFRSBElU 3haHFz0sSq+Yx2QAFCWwR2MO0pWeGx6ILrlLOyICAlFkpAdpcknnSWCMQSQfB59pRlOaEQ9X5OUc WxJE8wnAAqiMJAsbqUv8NE97jcRm587DRBIw0wAl1N8IMCitiQhyekXMZf+AiCszYtF8enxj/i+V Fz0xohN8cFRe/vJXTjdW74tnlKj1zCdQ07VSFhEUBgRjCqiamscWRzvaWcwztbMQbacJ3FlLh0rU ohr1qEhNqlKXytSvnYd9TXxpDk7B098VQapNhRwmmciA4p2PCM0rRAM4Rk51BqFdRmhh+7L6hOYh 8H0qNJwkT5C/QM7Vo9sToCQEsFYdtFAAX11cDAO7TlxQkAXRIyzh3DqCVU7EhVoSAzhpMULzCNKI /jNiEoeWPUdGQGon+OfUAngeRJgVaIDamap2sj6f4dSnHLyk0AIojJvKgoEFbEIpZTG+EnhTBQ/F qiuaVwL4DS9710TmGUdKThd+1oxfnWJl/qO3PhZ6NY/+HKcJZGhKAIyQh9KzIXJxdUFSSu+MJKCu WgdbzVBcFKAaHIMJ81cIfIa3hR01pDFn2IcXmiexYpDeM422WtdWNbU37d1IT0vREpD0tCbYLeMY Wz4KQjK9l5SeL+d4zIWeQiZSrOMgKeBe6qIglsXUnhdWar0t9rYlAkCgDH2JyHiuUY3tFK35MqJI 4ypzlmi86FrU0M0AuxCwPASf0XZ8QDEAsZC9RekaS8hAkupqvvhrcmzBmT3lMtGB0sqiZV3oQprs sYKSVez67IdfCiA0zE4WrgooTE48wnUNWwQAR9Gr5+UVb5u4CjEnD2nlZ3xSuSr0gkRE/lmBH2sL vYJe4X0hGYpMQjq5zdWzPwFryz4DoJLJu8AgvalHN5NYoSgoZZPBUEr65kLVLJQFRavMURLgU6FA 7G6r0ydIC+jRo6JuAJStV8qHOtjPy7MoGSNg37jqgJkV9mwxPcxFJhIwnyCKJ7VnmVw9EnAPh/ao LNMX1jSKrx/BpGUpNaloTWLgkuGOLYmTV+dNflo8Ih2pfMcnRVoMmHp7LLU+DijDt04xhcIehjUT fosUnsmUMyTn8ng43q3eUN99FnAA3k1s50n4ezbO50hHql9ozFiEmP1n894gyin/M4nG9vAlNQ1S /GBAAB48tUjjSYcRGACwY/j3+Lj5/mM8A/3n/cA5AwkoyCZyGqPxfDEHo649aa4IftodnyZlovIu WvKQKNB3rT1qYT5bs+yaTbAekw0oDDC34TIUwbuTzW+P81PAH913x7FLv0pLxL4UyJ/BOXpLaJyn iXdFAPv2gPjDgwGqIwHfG0ZoxOxl0X5dzaTlQ1F1Bu6Sg+4S6fkE+WYPr6+Ild6D99w7wthKj/In XSFLNU0/jsp3RaWnvBHhuFHtpiCJdaX2p539T1wi0NiqkqEszfP2XADxhx53XnBLTUYYHhCRdec7 JqGsfcH72wLVBF34JMsGWtqA/DmQs8Jzm1oWGFMfFd2ME8uvDzr8083wL6Pkcdli/iO28ZKKFHwz pm+CR3JtdCYatWDTB2kU9GfQ5Xr39Tnhk2fIhHMQRgOo5lIRpFNDM1sDx19BtVoHNhM+UoIimEAy QWL+BkfElDoMJFR/0VfBk2tWYEwMYAHZczxsJUElVwXncWA7iE09hQXqF4RGeIRImIRKuIRM2IRO +IRQGIWsMwBUUIRSqAUDcABamIUHkIVe2IVg+IUD8IWMcABo8xpoaBOvgTY20YZu+IZw+IY+MYdX kRM/iAd6YClSY4J82Id++IeAyIdEU2CEOIjtl2A2lYiKaIW04zd3IBWvoQBoI4ljiAAKMIaegomM gIaY2Imb2ImgGIpj2IVeiIlh/iiGYaiFqaiKXMiFqviKsBiLsjiLtFiLtfgAs5gouaiKugiLuFgJ r/iLtNiLvSiMtniMyMiKW6iMywiGq4iKm4gAXcgILnGGbKiGbriGcRiHMjgRenOEWgI0VPhAh/ha PVNVCcZT6KiOgdiO7ugjeiA1eCgVloiHksgoeeAp9ciJn/iJlSiKABmQa2MH33iFVOiE/QEKBdkF RqgAT5iQ7rcjV+gbT7gOL9AGMMCI8uOQT/hSbYAjCtQzTXWQvlNTSgWRXbCQ64eIGok7HPkxDCAB iTSERYWSX6OS9/OHS0WSBRSTiBdVUdWSsGORBGk013iNZog2Qjk7L8kGMol4/k95eFfhLXZAlQR2 OjbJHSrZBsl4AA+AMzBFW0v5Az/zF2CJAzxJCz/ZeFEFPj8Jgz5zAHCzAAkwEUsTEEuRNKKTlUYj kSMAjJ1QCQ0hmKVQCdvTIIVwDwVxl0zwIojQJbtiA+rCJQXgl3whkffQO00ZZmv5lGu5lnolDkSy FPRiKz8VOnz5MQvZBh3Smh1SCWdJAptQD2DAmEuQDWxAAAygAI/AMuygfgpCAI1hE16jEXEAEATQ hZCCAml5eG55eJ/5k1GJAoOwBl8QQFtTDyYxBnrZDUvpIQr5MYHpmokymFHCAtlgEmIDIne5h+ho mzUgAfkSDg4gJ7+wCubx/kEvaJJ8kQ4A4DWDwCXhQAAG4ABUsQrMKWsjhHgGsKAL6kIG8JOYZQJu UjHX6Rra0CSiQJyW2QP74Bx4YwPIMDcl8REc0Z1/6ZFbOQHjCZiCaQ6C6SktwCqzYR8hERb/iQaV 6QAOQpdl4J84EKDzQJ9m4BwFwKP3UKA4ujeJQiGJExlkcZ4AMAFm4C7hQgKbeXiChHMLymQP2jzw +S17gJtz8BAJcZ5pABheMJYlwKOrAE9AOgM82hUm4iAYERAbUQ/0kKIXiZOMQpiuCYwy2gLOgDcT 0iSrsSpcsTXBwRWKJQNCyhdESqAiIAECcByR8BSqkBCPoBK9wApfUSCf/jABm/IL8qkMzWl5pOeW ltdVIjQkJNM7sJAReNAoYiAHfJISuLEuHgMECLoyYFAGM1UxKXCkDlEG5uEhBjqkv/mfZPGRfaoC WUiegRmaKTAIYTMCQ+IbAsAbTtGtv6AitCCXh1IDvCmgglEAlKoRIWEkvFIQUvqrbHAOj7CuXGKd 65oICSoLlGd5ZAahDTAHEWqtJCAA7iAKCJKmjukRlYkXevGkOpNamsIeYmAACDIV4sAytaGpPxWp d6oKVQoMBZKROIkTgDqYYaoCxsAeDMEohKAQs0EPGOEXN6AA5nKhTlEIM0sVa3Km30oCBVoOLhGi IyCsa9qsUmoCaSkC/nHApWNlsAbboHpgB2eAAHRwNuZQMoySpg4CjCj6GWawI9UwFjC7rFA6I206 sWzACh9LqusaqQCQmsPgpyUImImyhzDAo8/BGtnQhUcRHJvwBcHRqS6htjfADo9pLnk6AZvBEmar EKFatJuQKJZxCA4QCTyquEmrtDDZNgbruXNglRdZGs+Bju3XUD0RF8upqzY7D6Jwruuqt4+ZANTi HR+LpM4RLnIrCx06WnfgniL5BwYmCncQJYDxU58SmzGAC/tpkkdTpnH6LTeBh7PBnQzUPkt7Fm3Y RFdBk6OyphrxrpvqrnU6vhiCCLArChyzrgSgFwe6I9BalL6zQDIF/g1RkhOAkBVEywYlawPZq5Mn +L2KIAdrYaeCoR/Kspyr0CAkcA9UoqPSuJ1Quq6MS7ujQLJZYIbemQRLy5LpaIhsqgRtADcswyKl y7TcaSJOsbmm4RB2SqkDMKCBQaomsLuI0L9N+L/OCzTkyJ+XA7k406w5YMNs0KFQuJmywyiBI5Tx G54TSRQVmZFG/ITZi4REPK6k6IlazI9pqI3XqI10+DTzOMZW457A+45oHIiDyDuEeILnyJKnS45j cJA6tcOoVcdKdMVuECVpGI1cHIqkmMWlGMio2IrMeAAT0JWKvMjIqIu9CIxa6MiqKIyPbIySDMm6 iIuSXJ682MmQ/vzJr/jIjDzKseiKhiyGg2yKWxyKftzFbNjHaxjL20i9YUyPtcrCN4k6dcyB9buI iQjHwAzHMiqC68iObJzGyGyC8UiPthzGs5w01tjFnPiP1FyKoEjIo5jNzmjIh7yn7ofDTFjFR3jF 3vjEUIyQHjnFTojESNjE32zOFOmEpyK/YCUV0hLCvguXrsV+t1CzrACDAmRbJyDOEvCUGBCUIdw6 5IyRwktTKjuxWYEHAVMDD9IJFNAQKDEKqwuseqq8XUAXyUqXIIIPmwEgZHXOsnZB4ENmjYdVB4AG s6GaPfwxc/ATJnIAJGOGCc0HOzDPoDDFiGiIivg12jAZBAup/siBIA/LABdyArIbvkfrwt1oAnZa NQ5Bw8waGRHAuBPBo/uKCE3kazcIARhA1iuNeBhw1NqqJ5cgEsNQmRMB1CXRCGCxKXRZriyQpJV6 0jAwokVbnETRreEAEtqy0P37QOeIgitwDd41gmVKC4xqh8RrtW/gKzdRnaHwDOdqJOFApfnqENBa ohsiuvewnKIdqfVJnA4rsgNtAtlT1jd4Qdnja2XtQrF9V+KwI7Wyz5GREHjMFwrMMryQDrPS11tD oOyQmRRdCgkMN2SxCrhawHDj03yBwTzzWuVoz+hpH2IDGQ4L137zD8ggGwRaJO/Qc+m5ApFawiAr nJV6pKzR/q12Gg4XwbEVU64fy6RfwJshAdhkUAISYNZuBD60bdsFLtvKwA5ftRbukKS4IRFegxc9 ZxrXqQ+mYZcv8Lg9Er71W5ZckplisZxCHK+lOhq6q6Lc0YG//LXcYRWfIBAEQS7EPbYv+5sVOhGN UijZ4NGR2hk8+rYKAgbBsKzJOQ8bjSQZYbwUeyB2YwZX+t9BcUEj52tnROV7tEcFbkOyUK4lYryX cAjE3bIFMrlJDp4NPQhiayJy8LKQyRcFQBDf0c+qMM8UsR/IPecje5HqPFoIhr8v0BpFyxK42jdH ARC4GdhZOwIhOiHVqd4k4t4TfJ+XKh4swdVte+TyyReR/sDeS97bFTPRKF2pL3Re5yV6IwUBOHhG Smcoz7qrqtAy6FEQuDkY4GkejUAcZg4DP0otJoMHxmC2Xn7kg7EGvHkM1yEs5nAkcYviXTA1MzO1 GWm4x7EPe3wOx3Hnc2InGVEYGqEs4qoCXk0Luvmr93sORa6rIMushgsAm2LuhIG8GIEOjQvqod4S 4XXlAnblvrZH1WOwcVQMmTAZl8Ayft2kAuHZj/OxWwIZMyCs8poM5J7AfPELcKsRyMrh7NHZ1BK5 96rnoOATJJOyLKCbih4lZ/A25wC4xmAOJpEGjUIWjRI22enmchsAEpkga4CjDvALLGHUD7EQiEAN vsAh/mHyn77+D2VB7/VOTjJE6iNHUv0eq9yxNnZ4J4TwGzgvGS/CDtv+svUZ0lM9AsU+pOML7JjL DBdvILSAoMjNMX9CpaPBMYZtB3zuPteNDoQ+EkElC3e50yiQnGWwkE/NO7UlVRMQWjgXUiwItUMi ukbzNrMRw76xNS8RNfm4FjvPQHih0+Mq+YLwJMZrDlSB1Uux2QNwBktaLodBDYlSwvko83f61HlO zzz9GV/B4lpwDzip9OaKApnH+P3uQWyWkX9hVYfbhpJfLXJeYPrI8s0g0n8KN4VwE6cv2mE691eg zz3RClXsZFZrtTOj/ZlDN6KBuDqQ61+jzpvj9z/Q/v3m+Muhk7JLif1PLM7Li03U3QXqz4TsbMUq uowgMBwiOY6kMQypiozIOiDwTNu1fNc7vwfzD1hj/IrG45EYWDKbzic0Kg0AmFWqNRuYYK9V7/Lb FQO+ZTOael6z2+43PC6f0+v2gpoeOPBLfpPKCAuLzEvMTI5NIiJjjyNPUBCCJNHk5NHlUqbSVKen 5xWW6OgVl1hXWCrZqtpYmh1srOwsLR2e3V6mZZFlrwLNr0yOMIxwiwpysvIyc/IJQCBJNKBJNd8E n3X2Nne39zd4eHjBN/mBOR86Ot8D+3Z7Ovi6OP03ALdIdf5+X/+fNIsTB4oRPEaD2I1FNfjkmbOn /hbEiBInUmyT5+IZjGUGvMpYBhVIMqpAfippslMmJ5dW8mo545evgwWJGatp81gBWA8r8uzp82ct jkCHEi0q8UBDOTsdrjLq9GlRoVCnUnV6q06ABw6XMEDAqSrYsLGk6hRr9uy9pHGWuuHKwECArnLD oK1rdoIsVHb3Fs2J60AcBkTkeh2shC/ip2S3fkRTxytWtYmpIv37Jq5gwXENGJ47+fPPxWvHqKqz QECcSRsZVJUM8UdFv1gBtxWQwDbnzLcNFHa9JkCBAnCBC0gaIIGBxqBnIQAq+vIl5XQdLljQSjmA AhA8mmml1vedAsUrVk8OIMHVNQSCmwdAAPXv/sqz2zJIkMArAt71BczIDHdOAQs0B1x7a4hXhXx9 RcDGgTwF2N56BZaB3BoOwAcHXmuF4sUp4J0hwwILnvcAAgVolcACDywRHHBaWfjDe8llVaIArNEC 3CQDXBiRAOsRIKN1bPw4yY/uHeCAigbqpJVF9/232W2q/VCfjWstYKN806GHHZfdRTRBegXAMN5E CRCwAIUE3FfkGQQ8wKaFbsbxHBtNeFmFakoJMEB1ZZwJg4ABCFhFiAAsgMcKJQbgwKCntViLA80R ahGeZeT5kSvZvWeGmGwMCsAEAkwg4gRMlpGgQ7TVaUBuH+320VtUepjdeOY5EByTpUKjVQDF/h1H BHK3zlBAlbMIeoZwZYR6mXe/qVUAelTw8dECbZonJpJl3AoHnR5JFgYRczgwUIDNKRAksYZKWsCC ghYBAG9nUpGsrhKxWWEBEd56FXDBqVpGgHlcKeRAOLJ5roGzZvTvGbGy2sp/AOT3FoXiXhkXoQGc 29ymE1gnaHLiBSBvwOspfNlV6QKAMBtxCjiAyB8Fd9tv1bmSLcA2xmkecK51yx2l765VmaAu4gEc EdYRIWd2gx6HAIoUZJfcphElYOoZDjDK2qEAWFjFLafV6WgZ/LWBntjalcHyqScj6IZgrCZQJcSs GqCynuSo4YIAQW7q7tTuGe11TsfWYnh2/jrLlvXAjn7d6xKHNiRoerfmoXKoBIiIeBsZXtZYKqFL GseZrAkq4Jm8LQDXAgewPh6fVGzN6OvABVnLvWzUG2S2ahPOhgJ4hO1ap8muvOPiqbohgQCsNl/s cc2z6vscZ25+H6PNbQmc1MluyiioqFleS/BqqKzAjtoymW6JiZchQbW/iTnetmt8urPMPisVip1Y XMpsK1hyBF7NAGgrCIAMjAAE3CVgOhVaX3Med4sGnUpHI1uQ2dpgvJ4BIINts0yTbCOA5zHBACMc 4W1OtjFtXYl2TTvO6tyzgPUIKDglEhCKihULxPUMR22oH++0Ur7sLG5Y7uENahqCM2Jx/jB3bPgZ pp4gBh0uBw6MCk4MWyaiW+CsXyZag44OxavKNcd4MsMbwNzGlowwQAANOCEK4Xib5rltdBJDChAU uDdNVCISQjNWevpFRa9B8HhnpCA0AkSOM4knWQNgzb5s1C+GPfFzV5CkK/5YxdFYAQ5JQc7IyHQG j41ucpmCVRtQpRRVvg+Fb4SjbV6Jxk22pU6+uY4X7jOy9CirdZqggenU8MjfSKhzo5HSKuRCS6Kc SZQZwVpEkrfKy7TxhBAYoQlPKBy3LfNGwXGmzJzjSa70LxTh6iZQuFkLVnqSkmeAGizjGKC5odMo DnSK5yxiknryE1lqdOdHvIJC8YxQ/jy8UWc/qwjFUWShKQld5h7UWDiS/PI271HTQFLiGI045qGI gaJHQ+oGaa7FX+eIBzn8la/gsPQcKT3pAdqBDnjA9KXkgMdLY5qNedSjpz7dBj+oIdR/vKCoNJEJ QhSCAzE9AhJA6AovahAXIyiBEye56j5DBwZRiAQMXdULK+6Ey1X+8zqkGIlItMC/s7IVq26NggB1 oQkEFmEAP4BJAokRDEbUZCbN+OsJ/IAMgUyjBP3IRj608dPFMnYb5uBpPGAq2ZPOdKeWvSxNJUvT xzqWDxECoUhDSwuA0nJyuPCWdL6q2pBwVa2t1SoUhjgf0dJ2LLW9rQaXhNvdzom3/rtl52VI69vb 5nO4oSVpO42rXJAqt5vAbYtwmyvS4ko3ocgNLlMaWt1NMpcns8IYVe45yFgwIJD35BDQPvJcNwi3 E9tdDkg5ylGLeYgAjhkmM2+3y2LqJEDj6ZczidOKmCkJtPrUghSx4hUm/O+9POmWXsx6JwB9ypO3 w5RRbkesGfK3Dvna0yTS9bWP+KpwRxNlRA3srJJg5VAM4NN6cYvQOlBXtWEFK+lSZClg8ZhQPdqO 0FyABSKsYCJcZJK7NNHA8xTIAcPJA3rgE6m1xc99RmLTspClE3cu4ZEuaQl46bC1tNiFnkVhVB76 04b/wSYOAI0waWz8BqTIy2ut/jvTAf5kKBIN6osuKFHSHpBDiQSRWna2z8xUhh4UQbN0DKpSBglw Dhuxjcyz/c0MqtEIH5zTFr58JygltgQzH4doLJnImc6sSNOxVInBkSR74lBjtm4Irec1kJliKCgi pOtifiuO5ggEsl13EJqzCNKo8pflGH5N0n5KH+WqhMbb3YoA2/Ea8v5pkUyLQAe9WGCLq+wmkMnw HB8T03sW1bqrUYSDQ4GWLi24sipnq4fjqZgbIFzrhnby1pa6hNgMtaIyJo0Km/qRoAZSmU4x7XC3 KK+hIyCiQvsuy1lDTfF0+KkfwQl5W7ZIDIRRDd6sYCB2hUWAbITwL6JZUCGG/uG8sjiRSisFAS0n h4FUVCA+xS9PI86OpDJnHpqvgboRXi3oXNOra6eOT0lLGuvgkiwTCapdkQsZL4+thgSQy+BMQjZ8 xFQ0XAsPPUgZSXHqTQBeN+S60AU5TNshd3fwIWJ0IFKQ9oCi5GwLaedxqRoCPhH42YFRSLEhm4TD p/QxSkT5Q5aNuG482bbhObi8vJc0uQYECIA2JzXAj3RELrgsekDphhlvJEYOBqQ7Igky2WqqsOQA yGiXZiRUdRDgMSwmh569MpWA46Ptyud07pkl0R0WdC5ibVMAeJCXuyxXOgQCxti0QJ8dsqy23pkH THXKF8942anwsYlzuqPP/lXBPZHpXOQ7YlGT6H9YZYd2qaPZgYUC+LsHuquDHQ32JM6FEgK8xwAW B3qEWAooHjkgyS7ZUS0QXh3gTKGxyZZkBHAEToCxyY/gjMVVXltIQlPxQKe9163onwMeToytQf5x S07p1DmQiDp9xyk1yynN3PzJAdPwDny8B6PsCHosUt+QCGSEgXBw3YQcQHn5Ro0lHUOtlYOFhdtZ BGn9wAF0XkuRw/8l1Al6ko1ISXNMwq14EMBIjo6shyPZCM6dQbS42RMmVAqewQrW0i8VQh7NmG/B zAFaRBTWwhK2YRXtoQp22Eg4wSn4oRSO13gdhSGiU4rVQRxSykbV3yLe/sUkdhMgLkwlelR3ZeJZ vOHadBgnblIfhmJdrJEcPCIpOlcqgoYnrszZId3RZV5qdYT9rSIdjGI9RZdIXSKyNFZnLVZl1ZQv DuMwBpUx+gMgEFVfHcNRScxBMJVShWAkCMEuVCOYCdBbZWMUbBU3whZrIV1YiZUUzphGlGNXfVVr pdW+rZU2tqNJ7MKXVeMO7NUPGMNM+FUxIEMB/BVgKSNimQA2GFY2YAMxFmQ5RFZm/eI6BKNkQRY9 4JQu2qJEQhQkcgfmHR1GFqI3epUdTqRHfiRIhqRIjiRJlqRJniRKpqRKriRL8kVHtiRMxqRMziRN 1qRN3iRO5qRO7iRP/vakT/4kUAalUA4lUW7SWE0YUo6VaUUidphjUwKNfEFlehlLUfqWO25j/zQh gq1jVrbVvnklgm2kWGrla3UjWXJkWX5jOtpaRrYlLNpYnMXlLMqlONblSz4FArGUXu5lI/Gl8yUa YP4gtFwhYHaeFVJWTL3Um0BkZLkg3RmkwgmCZKJAohQVDJAcb/yZZm6agISgZ+5AV0BCaEYVLwzG VJmmaWKCE1jVVbamFGzSAVRHdfAlS8mmbd4mbuambu4mb/amb/4mcAancA6ncAaIbBrnbO4mci5n cjancT6ncx6KdCrSdFYnFl2nItEmdmqndiZiKTKKbFqfuekmctpm/nkSJ3mip3quJ3uq53k2p3TC p28yp3y2p33ep2yCol2cSXgGlHrxZ2+eJxYF53vip4HW54ECZ4EmKIM2KH7qJ1qMTHIq3jmc3IC2 TnZm53HKZuTEp4fS54fCJ4gOqIaSqIhu6Ik2p4rATIhSZ4qGaHS+qHnKZt+k6IUegMfAqI4W6Iii qIfmZo8SZ5DCKISexRbcJiNNSxXcSu5RDqj0GW6uiIMeZ4emiMYsAIvip/hcybnY5tnl6G0ikH0i xW2qyA+AKW9W6ZSuKYMWqVnAUHXsiQnozUfwZ+RohZ5VBzLYzOnoY+uogH/p4z7yHJaOp4/2ybzd wrmYGzmwaGxe/meeTWc6VMcBoE1OnAtr0BCHNs1K8WeIGacZTuih5MtxDmimxifVVKd1DmiHXuiP umqMKieQyiiB+uiC2qptuqlZxOahiMAiscgXoIij6IqkSeiKRM6KEMGbrM7I8BrHEAlSoN7R3Kp1 DAhswIx7FAeg8gpwROuVrmikztXfpIuEyuYk6FgReAwV3BAChZhWABo0iCmiMMC5yAiYJgeYsMif JBne3WkRyIsI7CugIMUIUCubTqmuhkW58oHkKIACCAUVCGve0YXNxCuOXCCY3qn79InHcI3F8uc+ IkDwVMcDOJ2dHWuR9KftfCvQJVIMBUzPkNLpJGdziI2j4UGX/iaHCCRSxpzLgjAcx0hdrkrMAMhL +ZzLlW5HAVBAzF7MLRDIEYEKr2Tpwf4oehqscSZsWDCSIpXsC3YBgJqOrjUscq7Ik/Kpjomdju2r 8LxqbR5KlxonAqFGylJquV7pz16FnMBstXSsoYQp5Rwp2+UsNKQDnlrHuWiF2OWD2tzmz/Yn7l1p yJitnuFsdbAGDXwRgFYt55bHchxpi6ICePZJvTbNudHQsQZPyo1MiHGNVnSsu9TmghZAl8om2EQt Fh3uuYXMoSwIsSKuipASp26qjqFIGXUo71bHgkDfy56ruZqu55ZtVqgbNLzsscIuolzu30ave+Lm kDooiC7A/rWBxuaaiAjoxeZGaskipzH86aEgQrmEmPuKyYPwXD3eKjncJgOAyQAGSijZzvsuAZ7l SHkwQck0Ka9+msnsq6OMLJHtkrEmrrHS1eqCabsM4OGyXby2XKDYldHOZpehHvR2LudqbWtsLtaI 7qFWrcHOqJCusI6O6oxCZ3xe56jS8IjKrqsGBw3RsAAbp/PFqaZe6Mz08HtiLQm/aJCacFWgMP94 weYm8cG2sBTjJ+hWMRYPJxNPxRXfsHZmMa0i6G0OKRnD8HrScAzPKueWsRKHsdW2sffiqnxuMVTI K3Xi8IbesXWKKoyyMRWDMSAHsiC3Jx3jZbuaXGYmyjC4/sBgFQMhmJwgRMNlBgIMUIM0RKYfpIAl 68NhaUNifTJkNpak6dQ6dF4VxoOPvEm+yBRlkcNhOt97rFQV8rBemuFK0TJgcqcu7zIv93KJYqcM a6h31kV+WEJofiYyJ7MyJzMI1kBmhuAz80A0bppSZVQPPHNmAgYPWHMKLMQMdHMxywDJ4UAib5oN RDM2O7M3S7M5L3JCZJoi0IDJ/ZkwYKY4E0NGzXM313NSZeFeaJ4nWWR6OSVTThhYuSVCm2WHPHHo NHRXPvRWdSU7uqY2yhU5zdVFF0FV6ZE1GvNUdfSCjaZUhSZU9YdJV1EQTDRFr7R7EeJWjiVaxjSc qeNM/mvkWyY0XN70OTol5k2lUtbJUwZ1R90lWCABSx81Uie1Ui81Uzf1J6C0lDi1VE81VVe1VUs1 VDPUFKj0VXe1V381WLP0Jg2hFHFVSmBVhzy0V0d0WD91W7/1Pn3uWTOYfdzHsDxZ+ilcE4zbXJ9E X1c0XGs1FBzNVXH1EpxdYK80VFurFWTnQKBHuxj2E1zR+36BeNjHxHaCx4CNfZgOQwu2FCDnfznh SwMHzYQlaA+2dDaAQ6fCxaQ2FFgbnjRQE6CZZCd2YX8uxjyBrgUBs0YIi8EeE9CQyR0KXm9j662O XR0HbV9CH5WE/2rCATXBStShJezrL/nPX8d2Z+LJ/momKwCw5lYz68laQcvhtmtmtRM+Z48UcUuV xBUVTxA7X99skyeUiM0VQPawlACgGfiwy20Lim3o0u4ZgG1jYZx60aIVsCLhXbJANxYYJ2sIK+sw AHged2j7irwwkoVDi7midzsuNjtCywA0kF7Wt6N8AqPYxw+gy18SNijQEK/V9zwJx3qUCASAAuXg CuGUC1Pt46CEatKYDOVwbXSDgm0LgIvM0Mf8JZ7tU43OJooIJku92MBkVWCvYxVFdWPLiHvwsC/V 4Vb/TcYQEanCthOsBx2NaqUmIC7X3nh79q2gzaKwh8t9ebLsS9gcypDMjEkgbXbwyl/OS6J1nklQ /p3tjWp7N8iRg3hug8a78PaT2bJwYHBJ/AlUBcppNNKClYTIeFGyYq+vfMJr00rkfOqp3/LZMTmh yEgSuRCEj4xWwEyAgM2rVa/VbXXzsNCnl/g3Ecp2u7Sj24lcB9Neyzl68FqKgwIC2GaVwkzS0HaM ywgeULjqzQucd0KnDPem/k0YCY/OisneAbBXHMqot3SQ3NA2MRJ/rM43BXsTAHid08hlo8mmk+uw P/pnGDUThCF6YDiaOwFLXY071rV+XNJKR9naPYGaccJKVIKXUaFfRzzUPBmLB4GFMPZWz826IkXw NPeZpJtbt3ZYazmkc3kYWJS/BDhcnbjGX1V8/ksOamvjeQQzFLBjRH92S/dNjXp5VrK1J0hsgBBN GLRevr+Vepd1Wmcjy4980x89FGz0UT9zxH83RT89lqP1lhs71Hd9iJN8eoO915c1KMj1IDb0V6Z9 aYO22ksL2t/82rd9WwV81o89Wjs6eu07ZHj0YPD9aWr0309Cago+OUk9Jxz+EyC+3WM1agN9WJI2 TLuW5Ct05Kel5W+I2TfzMnsbD6QzImTzN9MAOIuzZoJzCvDGQPDG6edHoqA+66v+Crg+7Mv+n6n+ 6xez7ed+MeN+6GdUDnSz67P+N/8+8a9z6O/+7kfzDqDz5n/mMYPmEJi09Ec/fkh/JeDHlGT//lyM 4GT4M1DbJfiHP0b0tFzG2Y3dtFqiI0fqvFY7fltbFfxftBI499/3kTWW9DTav+Dvv0mD4PP7AAgA 4kiW5omm6hggwQvH8kzXAVDjt/3q+t6D/YBD3O8oJAaXQOXOKAr6nkTj04q93qBabhbrjbJI2y2U jDKjTeX06g2Py9OuYczOy+v3/L7/DxgoOEhYaMg3l6hI18TUeAgJiGczmXPIUOOihxnZSelJuCg6 WpcUMIGKilAJuqlpiInpMvvKMxsbwPnX0JD5GINwgIAwYNAqKKF7DDnaPNcyo4AqTVDtQGO1DPwy jKA8mBUgfCdT2jTOhCeBISFh0CuDYz4z/vxTjH08xcTAydqI528PkiXOCr6B5mOaNFQEJhS4JsOA A2OUEhQImKdWtwG1ADE4EaCAsEof2Rx40JFGu5UMIEwywKqUDo7kBAEYhiwZvmySoBkyCJSRDgnT JtxQ0NCaEAILCoiUkoSAgF99Ynm72Y2inkpsBhRIGU8MDq9ge6xkicklPVtgfL6Q0HSBpiKUpALE B4NBu5oOBBQQkMAUnwQ4BW+9EzQxC3MOUm1B2lAAgRgFAgdYgOnvqgAWDVgEQPjTJFqlunmzRLUH jo8BKIwtmysKgQKouB3gcbZdydtrR89dHEMuMdZ+LDqqoZef3mQGkulieoDAbbpOphhg/kolnvYc ihMjfNG4tgjIEyRTtow5pIDNnT+HtjS6BU553b6ZYhWFtesANJHLpm1UC7zVkFsyIgy4jW+qRVGL cAMQ14dxqcWQHD+6NccPDNBJ9w9BHl63QHY1GRZWd0D5hENSZThAzWxLNVXZCwXMhoBFBVwngAMF QEiZVDvSMwxHmNB3Dw3eFEaPCAw0AEEEveCgVZIBVFNNATvMZUpuEJQEJTmb+aJGYQA4IFcPCBSw wFQACNAUA30REAEAaCaQwAJNRTnDakCsZNaQMeaFZmYvTGAMU1M5QKdEdS5gjI036JjedjtcY2JQ 30GmRhQTYKfhAtFNdeacmInA1I6V/qDZ5hHdkCOPAWUlMBuPMKwigpMRVHADAjD5AsAAACBlJQ4I zoAWGblEFNOQIwxL5gIPhFRZmgEg6hRTz8bIwAQhIjAqbhKYJcEIzr3AlJ1WhjRbnR85ZRECUkHH Lbzp/mVRAg/6AwABtFZa0HdTNlSGAgKXd+4NIuGwQLuhmjptU2WlGKKR+2aHDg0HlGTkDk42EAE3 Kc1kxikD7IDnELG4xCA35eDFADpImvKXuU+hugBTCKMs1Q2RSvrCcu3goFMPAoCKCZloGqDAAjpe BpOOTsn4tJxxRYundgrMmCm/o4ysw6YTUCpNzTUXLOeOOrZ7mV+uTjnVjYCYxgCW/gJWjVgmSjbA gJMfvbzymF+XwbcQtcgmwE29EcuAq8QE/sSMct3EwMFeOYXwZmTejFEAK4kQdA8FxPloxAtAAO2z jI7Z1AMIYweAsy9QxNSuNSQ9mdb9Ykk7AZRuKvZkMDQ7KvAusAmY6iHZp8dG/cTtGfJ70BoDBS8U qZ0mdhKgwMgvDNuEJhhj7ZY8TQDdPA84OOUUAjqq7dXQCYeYb/outi57OjLspSRxaxovI52nk2mw HFXmLwg7QGUYIJUaWUmBzusBUrJmu0T461/VmEDYSgUbbYhjVVgxAPXe1gYhvCdjU6pZNfZmGVvQ agDG4duXYCCBBAiggTGgUwJY/tMZHDiARkiSijA0wT0b6IYTnZuWMhYGgwFBhz8UQU+hmsKfOwWk VxCMoBz89SumaFFsD8GLpDKXvB/Kx4PPMh+JAgATFsSgGNQRB7moYSYEDWQWOjiAHVNSP80Bph+C QUIbx9fHQKYDE0U0XE30kaczAvI49luQFUUxwUHZaZIE0J4GbVGMA9DpAHTzw8WO5YK4caaT4uCE JkI5ET3QBCtlmUeNaHjJTdgklnl6JCQ/FgAFOGAAvKTl8+ozS495cBjDDMZ25CEMVw3Tg2tbJIUY F4Q85sOLn6AKvgwzEDCacZG2vGV1sjMQZyJynIf542FG5ARn4kWbgnihL98J/k9sdFMRbjlNhnAh i1xwAp/H6qcu9tmzqsQzmB0SZyMNelBEppObhxQkIPXBBXA29D4ODWc6zzDPK57SNBztqEc/+lHF gXSkJC1pVjgq0pSG9KS6GsYPW6o4lbaUpTKV6UxvWlOPitSkPI3bkT7q0/oMI6hEHapQjYpUUR4p F/ZkqlMzVMWMCmUFbRiDWM4QMrEgIjUWnegvwjkJsGpHrIlU50DPKgN+WkU+OAEmT+UTVamyYR6X vImN0IfXvObVL39Bn1/4Khm/WESwTglsZQIrQ6kkFjCAkaENHUunxtpQkwmgbGU3mQDPcDKznMyk qzgpjM5+FqY8Le1RkxrK/rauNZSghAYuTukTgAZUnnGI6xrkqtEJHSN9L+3oAOzIzN8egIV2tJcd NVnc4yL3ssitDJ2cq1hYSaZe7wqsj3zUVxtJhl14vets9Are8Ip3vOQdL4zQhD4YTe287E2vU6aG qvjGZb4MC0tWrSoQ3MIhkrEsAMq4ot8A31arX6BCgb85IrKSVURr6SdrZRGsmnytMQNwgIW/hgpK 5UHAVO0IV3jmBwBELo2Gm8LFOIziFM/zMv9YCJWoNCPHJayNPlBxVzoUEFjm4UZqxIECXHBHGwt5 yM/gyR2MU4SiJIUhL56f+YicMjuk0HMUyddUBuFfTQ3XgPwZ7kWsOgrb/kJ5zAYpa8P+4bWk1M4h ML7IWIUw5gnm63RCEMB0TrEAnlDHyCHZlR0HIJ0BrWYEwcLvQYKVWf3ekMwrPg5oCi2ETam5dgBg c4zH55kbOnLIbnnB1SqjiZjBxC8Oe2X86pBYcs0wCDyeAC+HKx1If88MDCu0CuBHANXh1lSMtiWC AXiESjd5RrTSVqmOcFfekBmLuW5dZrYLmBi/t22OU+DMnAKhHw1AAQbkpUgizKWmLDp2aXtBoqKw BQccAAehUaiRwzCC+cgDY/WgTwDrIIKrPMEcbFhQGTZ9EDh3cwt3LewNkHyHF89oNvoi1bF7YBGM GTHO88gZZpZWNlN9/vdc8+XrR8hkDBHDgMcDcEheT9yCKKQpZ0xxgbSY0q586RrXqitTnifwAAJg Is9vckmIFKDrEcxGTU5jTfou4xTVFTZYoYKW+sT9FzMsYABsUp0MreS0UbkhFxBo0sb+22g2TVIT 5XkEUwJk3yoBgc4HtzWnZcKASTaFdVIZlcnjBBdj0MQrEYvdD34UHacMl5d1uMr5bvAumCRNBDy+ zBngh3M5qe8rz528+iTjQQJIJM8kgNXppJvnKaHJK4jPuUuWhq4BjE5OxrBSeVgQLJy7KCQGA3te vG4rXmysY3/oF7rRy5pH/xvxXYR3pZvig/SgSTJBJ3KntQWDhN2I/kw+RMBfjSccOLWAUyCnDNIM KJIDcNuOng434g24isWvaVfwGwHkOyadtl3WOJWh7FcIIEMS2NkrEhEGje5fAKSXLxEHABJgJYBR SV/GYyHSFyyAazHneKxHAgwgALxggRyjexh4gbxQgR3IgRa4JPvSDJQBIcAWFU1GJSWhLVCkAzkj egLQfG8HBMZ0eEj3I2ziXK+QJs9SKrlkJ3n0Fbw0OQznNpCjcqXXFzLiAjnzehMAOmqieefzcW5m KmUngQJIGJInc1F4NpYxQORyHS5xNfnHGcGiebSnI2MiIzcge2pxLgRge/oUAXO4MRc4h8qBh3mI CwDQAK7RLyRi/oJLsXCDWGxz52Yjtx7cJWb6xV9BwFcHxE6MBHjjJ3jmsC/TcS8ueH9NQXQwYSoN OAa6wng7oGu1EwCFky+sIXbrYidWZy7WlyZxwjCFU3dUx3jrMi1K9xFU5yxyUhJZJ4Il0DMUQIcW WAGJ4CrOwGA+gHBBUCUwpgAiwGYPBwSlYgwOwCUyyGeq5iMbpkiUgTLBsGUctWgHIYEm8DivZyn+ phpBkB5X9W9Y5QUhIwUjwEK8FnBct4gk0IcnUgPAdgQMJ5Bs6Dha9AjZsGxycxdgNEUjBnvhlY0r gG8lwDWxsWIJYEVO90gGEJGQFEiBuAPvUg0mVB5Usl1mtY+4/tWIGpRlasQdvSZgAMcv/TiCj2WT lRU1CSd3MlYqk3SIlEBxEiVIe+ZVQyATtQWPa6AG97WUSXlV8ohRTDlghuaUEmRFeFOT5xVeakIO RFgt1TI2EeYhAud8D9Izq+VaTvVgaQlQuHAsugBR9jMFCAkVBRYGXUBgd5mXVcWXeemXUumUmVJV UEmY9+UFBgB2i2BgEjUGjhRCbfFNGMVpbGValYlSlomZmdlTIxVUHOVT8tGZLSALpzFUaqlUonSa s/CWormaaylbr/AK+8Qk/TRbyqBjydOZn9lU+GRPRxI3sdCRMMlhg5kCgNmXetmXi2mXi7mMStBV aJUHTCJb/mlFIWcJDa65mkp1na5FGqnVnXAVmsIpnuNJnnBgAH5YnumpnuuZnljJnu8Jn/FpY+cp n/Vpn/f5SO6Jn/vJn/0pCjTpnwEqoANKAhxJoAeKoPsJoAnKoA2anvTpoBEqob2mnxNqoReKYhCK oRvKoRlVoR0an4kJokOmoSPKL0VZUVChnHg5mMcJlaQDZib6n+gpo5bSEhHQdTmqozvKoz3qoz8K pEHKoy3RdUSao0ZKpElapFvCpC3hpE+6JVCqh3hIAcpRpQxwpVWapfywpVjKpV/qpV0qPVXaGsCZ nWfaGrMlPWn6Al0HnSHGnokTpe/ECWu6pmm6pvw0pml6/k94yqW5oKVg6qVhKqhXOqiHaqgMUAH8 sKj8AAFV+qhOGqVMuiWN2qSUqqiSuqRH2qNIKqSf2nUVAKqjSqqliqNbUp4BMJspWaMRZJiSmZRV lJwEtqLLOZcqGpcI5gctgTesGmBN4qutKqxSlQsREJw2hkYiOqzLOmRuOmYNcIzMKq1jtiTB+khd N63ZCmUtYa220xLaCq5Dxq029iThaq4p9q3oGq3nyq4CVq4c9q7tKq9Sla4xqazziq9X2a2KgQA0 mq//GkH1ql8wCrAFazsBECcBFgAEa7AN2x1otK8noiwOS7FB0TEKG3IVq7EF8agKy7AbC7KKgKqM +LHK/girIQsSslqc+3WfHUuyEeuAk6QmJ6IColiOJRAYK+AAwVhkjLYkCVsCEMAkbMAxYmYAQBui /ppRCwuzIkAmoeZ2owCKKNBsAHcZPCuM+6hzJdBwZLYx/qqqRRu0vKC0wii28skPHgsUaahyuhYq HdkCTxEFkHgZj8MCgFF6XHAmJQE/Mml8UdBu5eaAuwJmCBFvE6kkKLOwrhGqOzCyRLoFiroD0jOB uxe0G5ONqmorZsAJ2IoDc8iknLslfria1iliE0sGUIVuWJofZDkKLquSJSsK6ui0eVYnFqF1+WYn daI6qvdextCKI2A0gTIBDSCB6dV6LkdiXEs6EfYV/mWTJqhjt6DhMFz5I8vXLeiVuwDgJDewuRbo EkILOpYbti4RATMrArwgvmrAMeI7gUzSvVGQgRzzuRqYsOJLtiJGv8aKgXOoe4KZgSjTJGQbtv5b tokAu3LFtAbBtk67HqdDvSSgI6uwNL1YabSIvhDsfzUHvKQILRB8AqfTt5iRNKopJ+tGAllGQC6i LR+BHUdnM+JStLqXN06CK5tLgRiYC+obtiFTtEKLnprLvRdbKx3TJChDARyDCU4iPe2LsP3oprai vziqvxQgvlY8tPzYh2ErPe9grFycNwsqCmn7sgZBu2PyFe3HYiOQNI8yFetxhJ/hftnYbCKBZO63 /sYo8BVrHBKrgF510JKE9hFtDCeoswMDxF4+3AAWsIEIi6McU4xWTIeTnMV3EwFYDLR0+MTRqrkB wMhPIsQ4MMMXe8Q4gL8dsySKa7xLcowSQL8s8MqdPId++MpLcsBzkMDEeq+KgHEI0zFaB5C9Aj9J yGttfMZa1wL5N32cpwOAlQILuANaByKtl5hw/MEuzHlX6ylwVQL+i6M4DL79K8q6N8Dxmnu2sh8b KLZCa4cfkcS4IsodM4c3AMRPPMBxQoF+uCT6uxmVHM8jMM/AigMCAKOsXBCsy4gZ6wxPKyO4dnEW PB7DnGdMsXNKh4+csibNBgDACxMtFywgXAJu/sMoJQSXvQiDJSAAaUQmqAhyVqYej7K84yzPlzzF ffh16Uu2SyK2hNQAFxCpThK+Pf2oA/wCkKyo7tvJACC0uLLOffizO4zKAkC6vWDL/2wFO02/YtvD 3CvGizCysdu0v2Iu0kJodoLCsHfIjGcnXGknZVAuh6J0itfWLvC8AMRGKXx6Y/0CMrsKflfWmwHB zRIoCBMzqFvASl2uUvyzfri+5bvRfWgABA3LHcMLZgABAmABFAi0PSwBtrK5fEjKWwzJurfRM6Qk hXPZrpHKj30DXry+oL0F+Ju/zpDLSyu7kFRjwsgGadCUWfuY6NaiwqIGBpBGdWO4PUMGddDG/iKg MCEzHCChLFxyLPkzgSWRIXoy3SOApa1he4OqBt+quUccuYpb0HeIrRA7ArsScosrYhe7sJC8A+Mq AkfMyLcsBwgN1gfqSGRyrM8A0dpin6ttY1tCz9DKsfadkbdNoIlWEFQXMjH9nqq6y7gV2bvXtGSc 3yibqmHdHZIa1rW9Ygqu4SMetAjuqiJO4in+1Qqs0Cnu4hNo4geL4i+Osiuuy/vqt7UlmBx+smHG 4zSeAvitwBP+BoYnCsEsJ0jrDPi40Gjy43P75PSUK4irjDBRbyRg5Cpm47bN48dKluChxlMSdPTY Y8YijNactSzLeOi7shLUfrvmwqgIFHWS/tvuB+FXFLUxKkFCfuNSO4XLlymLwmNSg14GExdW7hQw gbuFg3RciYMRmV4YYy4l0XQsYDSrEHf4aJEpNyZ+QSsTkytJ6ICdsQWFXIYYg25iMWJlIEMTY6DC uABxkkA3O0r/dg9zNR1WuAXBsC7FzQY3O2+kgsxZ7rpxsOUhvq+fIzU7B3YMjR38rXpTQSNkIotl 0nKOlybu8gBiU4Zq8IOcEnVogjACwDXCPs11uy/LjR11oknpkdIisHpmnY3XE71xdwArfTQRyCYI 0zBXdz6OAxOZPh0SDEV18l6DrF5+7JNLOdZucnNxYvDOktKnGIM9aTykNtLEs9cwcgOk/tbfKgDi A0fkK1DIBaBrgYxuvHjCwn6KaRTr58iJMlRCyqYtV1YCdnvSIyc6Isg0tXuOhGYMq6Z1OTPoP7K9 CMMaJBxAIkAW6dHWaXjtfZ0ez/7mN9/R8CPSmvby0dvzhKYmhJF/uXa1A41XagAXt9F9n2clJXwZ t8EtpDPSohDyvjbjKvAUGo3yBqheU5KwAKR1yt54aYJcwp4wbGguasBrYl93+57HKjdrgz4C5QFA eax6x8N4pAPHZFBoE28wQIsZ5WEj1rcrwFdC6IV1cm4CGqdrEz/WJm/5fXa3y7s00nHHcza9hI8q HSzWN8FxyNv4IvvxCZ7ssphG7y50/sEi7nYhJ20DOi8/6C9vSKGjDCANwYzytFZ2PsEIwa8H+XPL 9UPfNuyXGRF5ilsw0h2va45nNCACaTUiF1E3aJeDAgJwjMov0rDVOrSC8iDMNjIHfbIBAkshAGVJ LEgQqEERAE4BBAugpGq7wKb/A0sQSrBoPCJLAUgvGSREAIVHqQDxOUSFBQ+g5a6+B2kUMFgIUNJF YhSYsFFNLxsdyCYS4BrjBz/oGUgJ/qAgnKToHW4hMHrNlYg02gzAZBkECMzALDDg2AAQCIRhLmCq ZSkBFUSJnkTZufR1RhIirmhqhj7UYGYVCC6UKZnSvNRY2mSR0owiOxUx9EFTV9Nc/ln7rND0bPsM JGCq0IQHTGcOjJubBIgeArSNlsRPm6QT8JbICCAkwBxAMlMAmL53Pgi8MKGngMGBBxIm1EagTcIm WUT0kAGDYDMuY2JwoeWASqh6iAwkIBFKUCYuEA+5wKbQ5Z1RE6LU4GKAIB8sIZ11kRHpBRyaz7IJ IYJ0aZAlAZlCjSp1qYthRp42vQrNG7sgB0yqaiKWq1ggK7zBGNtN1Y8VBsvSeMdiHA2m5pROpcok L9++fldF/CtYG9bBhg1DAHu4iNPFjh8zLgx5MuXKRhjgtaxEpubOnj+DDo00seTHmESjTq169eQh oU+zji17Nm0nEUo/llZ7N+/e/qkDwP4coILv4saPL24MGjhu5M6fQzfL+XPi6NavYy8RPHSD5tm/ gxcdwGpoBtPDo08furpq9urfw698PvQSxfHv45863nvl8fbzAxigE8rJFsFeAiKYYFO37WYeA/wp KCCEvjHAIG9LGFDBWXXNsVZXbNUVoYiyrdDAg8aZA4EBKkLQonkuwviig4nRKE2NNzo4o4076iiN jz8CGaSQQxJZ5IPSmHOkOUs+SEGKS0L54FlSnlWllVdieWULWXLZpZdZcpiWmNyQuY2ZY5oZJofc LNHAgc9ZSaWUSjJZ55FK+pgkkkImqaeRfxYJAKBCJsYjjofqWOOKL9Lo4oowY7b4qAEvPhppixAg cGmmLW6KaaSMblopi5+qKKOkLyJggaieXooqqaOW+mqlk2p66aMnjpiehyFaA1da2oQV7K/Drkns mWpWWSaay1qpbLNfQhvthrlSW62112KbrbbbcmtcCAA7 ------=_NextPart_25F_852F_E65EE01E.A45B3FD9-- From ipfix-bounces@ietf.org Mon Dec 18 07:36:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwHik-0006cC-Hc; Mon, 18 Dec 2006 07:35:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwHij-0006c1-ID for ipfix@ietf.org; Mon, 18 Dec 2006 07:35:53 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwHii-0001P7-1y for ipfix@ietf.org; Mon, 18 Dec 2006 07:35:53 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Dec 2006 13:35:51 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBICZmeG024397; Mon, 18 Dec 2006 13:35:48 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBICZltD023709; Mon, 18 Dec 2006 13:35:47 +0100 (MET) Received: from [10.61.65.178] (ams3-vpn-dhcp434.cisco.com [10.61.65.178]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA10724; Mon, 18 Dec 2006 12:35:47 GMT Message-ID: <45868B04.2010007@cisco.com> Date: Mon, 18 Dec 2006 12:35:16 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Lutz Mark Subject: Re: [IPFIX] Template ID as scope for Common Properties References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> <45780A37.8010905@cisco.com> <45782D40.20002@cisco.com> <457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> <458198A9.9000800@fokus.fraunhofer.de> In-Reply-To: <458198A9.9000800@fokus.fraunhofer.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4141; t=1166445348; x=1167309348; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Template=20ID=20as=20scope=20for=20Common=2 0Properties |Sender:=20; bh=z/PkXWCk9NbLeAhNj3njJ6pSbPFOshEX7j2dT2ali6s=; b=IS+MbLV+DZK6E/c2bZFp/Yqg4eywAqG+7bKQ8pVhojJXNL/e9T3YarGISTQdigyvfhwDDlNo BdrZKQ4eredcZqKguRiMKYu9avr5YHzcy5QPwEXM2yfw9DvQ7aPm6K1V; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Lutz Mark wrote: > > Hi Andrew, > >> There are a few issues with using the Template ID as scope for Common >> Properties. I am tempted to say that we shouldn't use the Template ID for >> scope for anything, except perhaps the template refresh time, or other >> data that is associated with the template, but not the records defined by >> that template. >> >> >> Issue 1: >> The Common Properties usually contain information that is vital to the >> understanding of the flow. So much so, that the draft implies that any >> Data Record that is received containing an undefined commonPropertiesID >> should be discarded. >> >> Now when the template ID is used then the Collecting Process has no way >> to know that this Template has further associated Common Properties. As >> such, it will continue to decode the Data Records, possibly writing them >> to disk, without knowing that it is missing vital information. > > good point. This applies only for UDP. If the draft allows > Common Properties with TemplateID scope, this issue has to > be discussed. It doesn't really just apply to UDP. The Collector has to be prepared for the Exporter to make mistakes. In several places in the protocol some things are highlighted that the Collector has to watch for and reset the the SCTP association if it happens. > We already had some discussion if one should limit this draft to > SCTP and TCP only, because on UDP the need to resend the Common > Properties does reduce the gain. We came to the conclusion that > the user has to weight what protocol to use and whether to use > Common Properties at all. Of course. The overhead of resending templates and options periodically with UDP is almost negligible when you are sending a reasonable amount of traffic. >> Issue 2: >> Some collectors will simply write all the Data Records, options and flows, >> to disk and allow reconciliation later. For current options that use >> things like the ifIndex, this is fine. Using the TemplateID will now >> require them to store the ObservationDomainID and TemplateID with every >> received record. > > I hope not! Of course it is additional effort for the collector to > support Common Properties. This method as well as the method using > the commonProperiesID IE. Why? Using the IE the Collector can simply store the the common properties in a lookup table (it will need to add some timestamp info) and do the lookups when needed. Some Collectors will do this today already for options. Overall, it's a more efficient way to store the info and demands less processing overhead for the Collector. >> These identifiers are really for use in the Transport >> Session and are not supposed to be stored externally after decode. > > Of course. > > If the collector stores the ipfix data, it has to store all relevant > data needed by the post precession application. There are certainly > multiple ways to keep the mapping between the data records an the > Common Properties without storing TemplateIDs. Perhaps, but using the common properties ID is something that will work with existing Collectors. At the very least it needs noted that the Collector may need to be extended in this way. >> Issue 3: >> When sending information associated with the Template, such as the >> refresh time for the template, then you would expect to send an option >> Data Record containing the TemplateID as scope and the refresh time as >> the data. So there are two issues here: >> a) Is information sent with a TemplateID as scope associated with the >> template or with the Data Records associated with the template? > > If this is unclear, we have again a new issue for the implementation > guidelines. I think IPFIX-INFO is clear. It defines the templateID as: An identifier of a Template that is locally unique within an Observation Domain. So the templateID refers to the template. This is pretty logical really and I don't think there is any need to redefine it so we can save a couple of bytes occasionally. regards Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Dec 18 07:36:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwHik-0006cC-Hc; Mon, 18 Dec 2006 07:35:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwHij-0006c1-ID for ipfix@ietf.org; Mon, 18 Dec 2006 07:35:53 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwHii-0001P7-1y for ipfix@ietf.org; Mon, 18 Dec 2006 07:35:53 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Dec 2006 13:35:51 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBICZmeG024397; Mon, 18 Dec 2006 13:35:48 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBICZltD023709; Mon, 18 Dec 2006 13:35:47 +0100 (MET) Received: from [10.61.65.178] (ams3-vpn-dhcp434.cisco.com [10.61.65.178]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA10724; Mon, 18 Dec 2006 12:35:47 GMT Message-ID: <45868B04.2010007@cisco.com> Date: Mon, 18 Dec 2006 12:35:16 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Lutz Mark Subject: Re: [IPFIX] Template ID as scope for Common Properties References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> <4575F2B4.4030806@cisco.com> <457620B4.3080800@cisco.com> <45780A37.8010905@cisco.com> <45782D40.20002@cisco.com> <457997A9.6010007@cisco.com> <457A8E7D.1040707@cisco.com> <458198A9.9000800@fokus.fraunhofer.de> In-Reply-To: <458198A9.9000800@fokus.fraunhofer.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4141; t=1166445348; x=1167309348; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Template=20ID=20as=20scope=20for=20Common=2 0Properties |Sender:=20; bh=z/PkXWCk9NbLeAhNj3njJ6pSbPFOshEX7j2dT2ali6s=; b=IS+MbLV+DZK6E/c2bZFp/Yqg4eywAqG+7bKQ8pVhojJXNL/e9T3YarGISTQdigyvfhwDDlNo BdrZKQ4eredcZqKguRiMKYu9avr5YHzcy5QPwEXM2yfw9DvQ7aPm6K1V; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Lutz Mark wrote: > > Hi Andrew, > >> There are a few issues with using the Template ID as scope for Common >> Properties. I am tempted to say that we shouldn't use the Template ID for >> scope for anything, except perhaps the template refresh time, or other >> data that is associated with the template, but not the records defined by >> that template. >> >> >> Issue 1: >> The Common Properties usually contain information that is vital to the >> understanding of the flow. So much so, that the draft implies that any >> Data Record that is received containing an undefined commonPropertiesID >> should be discarded. >> >> Now when the template ID is used then the Collecting Process has no way >> to know that this Template has further associated Common Properties. As >> such, it will continue to decode the Data Records, possibly writing them >> to disk, without knowing that it is missing vital information. > > good point. This applies only for UDP. If the draft allows > Common Properties with TemplateID scope, this issue has to > be discussed. It doesn't really just apply to UDP. The Collector has to be prepared for the Exporter to make mistakes. In several places in the protocol some things are highlighted that the Collector has to watch for and reset the the SCTP association if it happens. > We already had some discussion if one should limit this draft to > SCTP and TCP only, because on UDP the need to resend the Common > Properties does reduce the gain. We came to the conclusion that > the user has to weight what protocol to use and whether to use > Common Properties at all. Of course. The overhead of resending templates and options periodically with UDP is almost negligible when you are sending a reasonable amount of traffic. >> Issue 2: >> Some collectors will simply write all the Data Records, options and flows, >> to disk and allow reconciliation later. For current options that use >> things like the ifIndex, this is fine. Using the TemplateID will now >> require them to store the ObservationDomainID and TemplateID with every >> received record. > > I hope not! Of course it is additional effort for the collector to > support Common Properties. This method as well as the method using > the commonProperiesID IE. Why? Using the IE the Collector can simply store the the common properties in a lookup table (it will need to add some timestamp info) and do the lookups when needed. Some Collectors will do this today already for options. Overall, it's a more efficient way to store the info and demands less processing overhead for the Collector. >> These identifiers are really for use in the Transport >> Session and are not supposed to be stored externally after decode. > > Of course. > > If the collector stores the ipfix data, it has to store all relevant > data needed by the post precession application. There are certainly > multiple ways to keep the mapping between the data records an the > Common Properties without storing TemplateIDs. Perhaps, but using the common properties ID is something that will work with existing Collectors. At the very least it needs noted that the Collector may need to be extended in this way. >> Issue 3: >> When sending information associated with the Template, such as the >> refresh time for the template, then you would expect to send an option >> Data Record containing the TemplateID as scope and the refresh time as >> the data. So there are two issues here: >> a) Is information sent with a TemplateID as scope associated with the >> template or with the Data Records associated with the template? > > If this is unclear, we have again a new issue for the implementation > guidelines. I think IPFIX-INFO is clear. It defines the templateID as: An identifier of a Template that is locally unique within an Observation Domain. So the templateID refers to the template. This is pretty logical really and I don't think there is any need to redefine it so we can save a couple of bytes occasionally. regards Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From agvntll@tpnet.pl Tue Dec 19 03:41:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwaXF-0004f5-Cq for ipfix-archive@lists.ietf.org; Tue, 19 Dec 2006 03:41:17 -0500 Received: from cee204.neoplus.adsl.tpnet.pl ([83.30.180.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwaXD-00022p-7f for ipfix-archive@lists.ietf.org; Tue, 19 Dec 2006 03:41:17 -0500 From: "turtles. Thats" To: ipfix-archive@lists.ietf.org Subject: The Small Cap Trend Date: Tue, 19 Dec 2006 09:40:50 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0003_01C72351.C5183690" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccjUcUY+OAci/YzRcaAyP+XgfSYkg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <88808F796CE86A1.0C424B55F9@tpnet.pl> X-Spam-Score: 3.0 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 ------=_NextPart_000_0003_01C72351.C5183690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
INVESTMENT ALERT FOR OUR READERS
 
Interest=20 for VGYI has been picking over the preceding months and interest is = expected to=20 continue with a massive PR campaign in the days to follow. Reports = indicate that=20 all clean transportation fuel plants utilizing bio-mass are selling all = the=20 fuels they can produce. VGYI looks like a winner to us!

Company=20 Name: Vision Energy Group Inc.
Lookup:=20 VGYI.PK
Current=20 Price: $.35 (370% gains expected this week!!)
Expected:=20 HEAVY PRICE INCREASES TO CONTINUE
 
Recent News:=20
Vision=20 Energy Group, Inc. Prepares to Purchase Biodiesel Production Unit =

About=20 Vision Energy Corp.
Vision=20 Energy Corp. offers an efficient, patented technology to generate = electricity at=20 substantial savings by using the wasted energy dissipated when high = pressure gas=20 pipelines are let down in pressure for local consumption.
 
WATCH THIS STOCK GO HIGHER AND HIGHER

Any=20 of the above statements with respect to the future predications or goals = and=20 events may be seen as only Forward Looking and nothing else. All = information=20 inside this email pertaining to any sort of financial advice need to be=20 understood as information and not advice. None of the information above = can be=20 constructed as any sort of financial advice. This is a paid=20 advertisement.
------=_NextPart_000_0003_01C72351.C5183690-- From ipfix-bounces@ietf.org Tue Dec 19 12:36:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwisn-0001kV-6Q; Tue, 19 Dec 2006 12:36:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwism-0001kP-HL for ipfix@ietf.org; Tue, 19 Dec 2006 12:36:04 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwisl-0006As-5G for ipfix@ietf.org; Tue, 19 Dec 2006 12:36:04 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Dec 2006 18:36:02 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBJHa2vP006424; Tue, 19 Dec 2006 18:36:02 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBJHZttD026453; Tue, 19 Dec 2006 18:35:55 +0100 (MET) Received: from [144.254.153.27] (dhcp-144-254-153-27.cisco.com [144.254.153.27]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA10463; Tue, 19 Dec 2006 17:35:49 GMT Message-ID: <458822F5.8070602@cisco.com> Date: Tue, 19 Dec 2006 17:35:49 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Schmoll, Carsten" Subject: Re: [IPFIX] Request for Home Address IE References: <70524A4436C03E43A293958B505008B6642D80@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: <70524A4436C03E43A293958B505008B6642D80@EXCHSRV.fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3532; t=1166549762; x=1167413762; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Request=20for=20Home=20Address=20IE |Sender:=20; bh=oaKOxWT+yHTRxgD5YM2HR0q9l+PjQOO9LvW8OhrYg5g=; b=PTEXCr9XzB2UZbikmg8zwqQ5GZffgsdGA81IoYklu9nacBQao+nWrcjFMPhQcjw/Pd3fwAmR D3VaGptukrIBdkkzzTeSMhCIFyUSCTsdNrPW5uP1sKp09JtcgU93izeg; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Carsten I think the new fields you are requesting look fine. I think overloading the sourceIPv6Prefix and sourceIPv6PrefixLength fields is a bad idea though. It should be possible to send only one prefix length and have the collector know which IP address is applies to. Furthermore, you should be able to send the Home Address Prefix without sending the Home Address itself. I think you need to request separate IEs for these. Cheers Andrew Schmoll, Carsten wrote: > > Dear editors of the IPFIPX Info model draft, > > I hereby kindly request as an addition to the IPFIX Information model > to include two new IEs, namely "sourceIPv6HomeAddress" and > "destinationIPv6HomeAddress". > These are used within different extension headers in mobile IPv6. > > Question on the procedure: > If you agree to include them into the draft in the list of IEs, could > this addition then be done after the document comes back from IESG > review > at the same time the draft is updated to address the reviewers' > comments? > > If so, then I suggest to use the following text for the draft for > the two fields sourceIPv6HomeAddress and destinationIPv6HomeAddress: > (if otherwise then please let me know how we can proceed in that case) > > 5.4.x. sourceIPv6HomeAddress > > Description: > The IPv6 home address in the IPv6 destination options extension > header of type 201 as is used with route optimization in mobile > IPv6. > Abstract Data Type: ipv6Address > Data Type Semantics: identifier > ElementId: xxx > Status: current > Reference: > See RFC 3775 for the definition of the Home Address field in an > IPv6 Destination Options extension header with an Option Type of > 201. > > 5.4.y. destinationIPv6HomeAddress > > Description: > The IPv6 home address in the IPv6 routing extension header of > type 2 as is used with route optimization in mobile IPv6. > Abstract Data Type: ipv6Address > Data Type Semantics: identifier > ElementId: xxx > Status: current > Reference: > See RFC 3775 for the definition of the Home Address field in an > IPv6 Routing Extension header of Type 2. > > > I was wondering whether one should also define a "Home-Version" of > sourceIPv6PrefixLength and sourceIPv6Prefix. I think not, because: > > multiple occurences of an IE in a template are allowed, so I could > export e.g. > > sourceIPv6Address (this would be the source IPv6 Care-of-Address > from the IPv6 header) > sourceIPv6PrefixLength (related to the CoA) > sourceIPv6Prefix (related to the CoA) > sourceIPv6HomeAddress (the new HoA element) > sourceIPv6PrefixLength (related to the HoA) > sourceIPv6Prefix (related to the HoA) > > What do you think (overall)? > > Kind regards, > Carsten. > > > > -- > "The difference between theory and practice is that in theory > theory and practice are the same but in practice they are not." > > Dipl.Ing. Carsten Schmoll Fraunhofer Institute FOKUS > schmoll@fokus.fraunhofer.de National Research Institute > Fraunhofer FOKUS / dept. ANTS for Open Communication Systems > Tel: +49-30-3463-7136 Kaiserin-Augusta-Allee 31 > Fax: +49-30-3463-8000 D-10589 Berlin, Germany > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Dec 19 12:36:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwisn-0001kV-6Q; Tue, 19 Dec 2006 12:36:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwism-0001kP-HL for ipfix@ietf.org; Tue, 19 Dec 2006 12:36:04 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwisl-0006As-5G for ipfix@ietf.org; Tue, 19 Dec 2006 12:36:04 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Dec 2006 18:36:02 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBJHa2vP006424; Tue, 19 Dec 2006 18:36:02 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBJHZttD026453; Tue, 19 Dec 2006 18:35:55 +0100 (MET) Received: from [144.254.153.27] (dhcp-144-254-153-27.cisco.com [144.254.153.27]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA10463; Tue, 19 Dec 2006 17:35:49 GMT Message-ID: <458822F5.8070602@cisco.com> Date: Tue, 19 Dec 2006 17:35:49 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Schmoll, Carsten" Subject: Re: [IPFIX] Request for Home Address IE References: <70524A4436C03E43A293958B505008B6642D80@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: <70524A4436C03E43A293958B505008B6642D80@EXCHSRV.fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3532; t=1166549762; x=1167413762; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20Request=20for=20Home=20Address=20IE |Sender:=20; bh=oaKOxWT+yHTRxgD5YM2HR0q9l+PjQOO9LvW8OhrYg5g=; b=PTEXCr9XzB2UZbikmg8zwqQ5GZffgsdGA81IoYklu9nacBQao+nWrcjFMPhQcjw/Pd3fwAmR D3VaGptukrIBdkkzzTeSMhCIFyUSCTsdNrPW5uP1sKp09JtcgU93izeg; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Carsten I think the new fields you are requesting look fine. I think overloading the sourceIPv6Prefix and sourceIPv6PrefixLength fields is a bad idea though. It should be possible to send only one prefix length and have the collector know which IP address is applies to. Furthermore, you should be able to send the Home Address Prefix without sending the Home Address itself. I think you need to request separate IEs for these. Cheers Andrew Schmoll, Carsten wrote: > > Dear editors of the IPFIPX Info model draft, > > I hereby kindly request as an addition to the IPFIX Information model > to include two new IEs, namely "sourceIPv6HomeAddress" and > "destinationIPv6HomeAddress". > These are used within different extension headers in mobile IPv6. > > Question on the procedure: > If you agree to include them into the draft in the list of IEs, could > this addition then be done after the document comes back from IESG > review > at the same time the draft is updated to address the reviewers' > comments? > > If so, then I suggest to use the following text for the draft for > the two fields sourceIPv6HomeAddress and destinationIPv6HomeAddress: > (if otherwise then please let me know how we can proceed in that case) > > 5.4.x. sourceIPv6HomeAddress > > Description: > The IPv6 home address in the IPv6 destination options extension > header of type 201 as is used with route optimization in mobile > IPv6. > Abstract Data Type: ipv6Address > Data Type Semantics: identifier > ElementId: xxx > Status: current > Reference: > See RFC 3775 for the definition of the Home Address field in an > IPv6 Destination Options extension header with an Option Type of > 201. > > 5.4.y. destinationIPv6HomeAddress > > Description: > The IPv6 home address in the IPv6 routing extension header of > type 2 as is used with route optimization in mobile IPv6. > Abstract Data Type: ipv6Address > Data Type Semantics: identifier > ElementId: xxx > Status: current > Reference: > See RFC 3775 for the definition of the Home Address field in an > IPv6 Routing Extension header of Type 2. > > > I was wondering whether one should also define a "Home-Version" of > sourceIPv6PrefixLength and sourceIPv6Prefix. I think not, because: > > multiple occurences of an IE in a template are allowed, so I could > export e.g. > > sourceIPv6Address (this would be the source IPv6 Care-of-Address > from the IPv6 header) > sourceIPv6PrefixLength (related to the CoA) > sourceIPv6Prefix (related to the CoA) > sourceIPv6HomeAddress (the new HoA element) > sourceIPv6PrefixLength (related to the HoA) > sourceIPv6Prefix (related to the HoA) > > What do you think (overall)? > > Kind regards, > Carsten. > > > > -- > "The difference between theory and practice is that in theory > theory and practice are the same but in practice they are not." > > Dipl.Ing. Carsten Schmoll Fraunhofer Institute FOKUS > schmoll@fokus.fraunhofer.de National Research Institute > Fraunhofer FOKUS / dept. ANTS for Open Communication Systems > Tel: +49-30-3463-7136 Kaiserin-Augusta-Allee 31 > Fax: +49-30-3463-8000 D-10589 Berlin, Germany > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From cuswybqvw@christianguestbook.com Tue Dec 19 13:30:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwjjM-00054M-Qk for ipfix-archive@lists.ietf.org; Tue, 19 Dec 2006 13:30:24 -0500 Received: from [84.7.26.111] (helo=[84.7.26.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwjjK-0007r1-Oe for ipfix-archive@lists.ietf.org; Tue, 19 Dec 2006 13:30:24 -0500 From: "chosen" To: ipfix-archive@lists.ietf.org Subject: Hazel Date: Tue, 19 Dec 2006 19:30:17 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0000_01C723A4.1D80AF90" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccjpB2AUhuRdGoeRHyJU1B629aU6g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 ------=_NextPart_000_0000_01C723A4.1D80AF90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
INVESTMENT ALERT FOR OUR READERS
 
Interest for VGYI has been picking over the preceding months and interest is expected to continue with a massive PR campaign in the days to follow. Reports indicate that all clean transportation fuel plants utilizing bio-mass are selling all the fuels they can produce. VGYI looks like a winner to us!
 
Company Name: Vision Energy Group Inc.
Lookup: VGYI.PK
Current Price: $.35 (370% gains expected this week!!)
Expected: HEAVY PRICE INCREASES TO CONTINUE
 

Recent News:
Vision Energy Group, Inc. Prepares to Purchase Biodiesel Production Unit
 
About Vision Energy Corp.
Vision Energy Corp. offers an efficient, patented technology to generate electricity at substantial savings by using the wasted energy dissipated when high pressure gas pipelines are let down in pressure for local consumption.
 
WATCH THIS STOCK GO HIGHER AND HIGHER
 

Any of the above statements with respect to the future predications or goals and events may be seen as only Forward Looking and nothing else. All information inside this email pertaining to any sort of financial advice need to be understood as information and not advice. None of the information above can be constructed as any sort of financial advice. This is a paid advertisement.
------=_NextPart_000_0000_01C723A4.1D80AF90-- From ruthannbastian@atimetoparty.ie Thu Dec 21 10:06:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPV1-0008Cn-1t for ipfix-archive@lists.ietf.org; Thu, 21 Dec 2006 10:06:23 -0500 Received: from [207.144.85.69] (helo=hpr6hnr7qrqmsz) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GxPUx-0001qD-37 for ipfix-archive@lists.ietf.org; Thu, 21 Dec 2006 10:06:21 -0500 To: "tobit gabrielle" From: "cecil glen" Date: Thu, 21 Dec 2006 07:05:57 -0800 Sender: "cecil glen" Subject: FW: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_A983_01C724CE.47BA67D0" Message-ID: X-Mailer: Microsoft Outlook Express 6.00.2900.2527 Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.6 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 This is a multi-part message in MIME format. ------=_NextPart_000_A983_01C724CE.47BA67D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Spending time in thoughts how to earn money? STOP LOOSING THEM is the right way! You have been chosen to participate in an invitation only limited time event! Answer only a few questions and we can give you an approval in under 30 seconds it is that simple! Are you ready to save your money? http://volkbauc.com/re/ ------=_NextPart_000_A983_01C724CE.47BA67D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Spending time in thoughts how to earn money? STOP LOOSING THEM is the right way!
You have been chosen to participate in an invitation only limited time event!
Answer only a few questions and we can give you an approval in under 30 seconds it is that simple!
Are you ready to save your money?
http://volkbauc.com/re/ ------=_NextPart_000_A983_01C724CE.47BA67D0-- From image@tallerdeeditores.com Thu Dec 21 15:55:07 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxUwV-0005mF-4o for ipfix-archive@lists.ietf.org; Thu, 21 Dec 2006 15:55:07 -0500 Received: from ppp-80-47-126-77.lns.access.uk.tiscali.com ([80.47.126.77]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GxUwO-0005ec-C3 for ipfix-archive@lists.ietf.org; Thu, 21 Dec 2006 15:55:04 -0500 Received: from your-e641889c92 ([135.172.100.134]) by ppp-80-47-126-77.lns.access.uk.tiscali.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Dec 2006 20:55:14 -0000 Message-ID: <000901c72542$41ed79e0$4d7e2f50@youre641889c92> From: "History Rules" To: ipfix-archive@lists.ietf.org Subject: exclusive benefit understand can Date: Thu, 21 Dec 2006 20:54:50 -0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C72542.41EB08E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.8 (++++) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc ------=_NextPart_000_0005_01C72542.41EB08E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C72542.41EB08E0" ------=_NextPart_001_0006_01C72542.41EB08E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Upon surrender old displaying, tab duplicate vintage pioneer code! = Trademark ownership notices that. Are complying quality standards. Your = of this subject web sites terms service. Sponsoring chapter part annually cost renewing, includes, donation. Lists, eight weeks either. Grants you royalty, free revocable located at = site which. About department attorney general. Kit, limited content for editorial purposes. Indemnify hold harmless, against, claims demands suits. Remainder placard mobile, own lease, rent equipment moved highways! = Terms service as well following. Awarded purple heart rated because injury. Longer disabled, letters quotdvquot entitle? Lease rent equipment moved = highways such, fertilizer. Active personnel veterans surviving spouse = eligible remarried determined residents. Which may include screen, shots drawings trademarks logos. Decal placed = rear click image. Reserve according branch however! Highways such fertilizer spreader collect. Mca item under veteran, = active personnel veterans. Placard mobile, own lease. Rendered images or promotion products. Up drivers choose, number ranging = designs? Discharge forestry arts culture collegiate education government museums = parks. Present official unit commander? Lieu file minimum, prepaid, = programmed amateur radio operator. Services through, print television. Persons highway patrol academy reports consumer. Branch, however no = longer disabled letters quotdvquot! Ridges forest transition foothills, = then, prairies. Of this subject web! Feature wheelchair symbol, also = licensed physician advanced care! Of this subject web sites terms service as. Entitle privileges been awarded purple. Longer, disabled, letters quotdvquot entitle privileges been! Silhouette = skull written across. Granted derived solely from goodwill will inure. Initial producing, lieu = file minimum prepaid programmed amateur. Graphical browser supports but = accessible most browsers. You royalty free revocable. Museums parks sports recreation wildlife = animals youth, groups qualified. Original were during, same, year, motor = example. Surviving spouse eligible remarried determined. ------=_NextPart_001_0006_01C72542.41EB08E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Upon surrender old displaying, tab = duplicate=20 vintage pioneer code! Trademark ownership notices that. Are complying = quality=20 standards. Your of this subject web sites terms service.
Sponsoring chapter part annually cost = renewing,=20 includes, donation.
Lists, eight weeks either. Grants you = royalty, free=20 revocable located at site which. About department attorney = general.
Kit, limited content for editorial = purposes.
Indemnify hold harmless, against, = claims demands suits.
Remainder placard mobile, own lease, = rent equipment=20 moved highways! Terms service as well following.
Awarded purple heart rated because = injury.
Longer disabled, letters quotdvquot = entitle? Lease=20 rent equipment moved highways such, fertilizer. Active personnel = veterans=20 surviving spouse eligible remarried determined residents.
Which may include screen, shots = drawings trademarks=20 logos. Decal placed rear click image.
Reserve according branch = however!
Highways such fertilizer spreader = collect. Mca item=20 under veteran, active personnel veterans. Placard mobile, own = lease.
Rendered images or promotion products. = Up drivers=20 choose, number ranging designs?
Discharge forestry arts culture = collegiate=20 education government museums parks. Present official unit commander? = Lieu file=20 minimum, prepaid, programmed amateur radio operator.
Services through, print = television.
Persons highway patrol academy reports = consumer.=20 Branch, however no longer disabled letters quotdvquot! Ridges forest = transition=20 foothills, then, prairies. Of this subject web! Feature wheelchair = symbol, also=20 licensed physician advanced care!
Of this subject web sites terms service = as.
Entitle privileges been awarded = purple.
Longer, disabled, letters quotdvquot = entitle=20 privileges been! Silhouette skull written across.
Granted derived solely from goodwill = will inure.=20 Initial producing, lieu file minimum prepaid programmed amateur. = Graphical=20 browser supports but accessible most browsers.
You royalty free revocable. Museums = parks sports=20 recreation wildlife animals youth, groups qualified. Original were = during, same,=20 year, motor example. Surviving spouse eligible remarried=20 determined.
------=_NextPart_001_0006_01C72542.41EB08E0-- ------=_NextPart_000_0005_01C72542.41EB08E0 Content-Type: image/gif; name="restrict meet.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c72542$41eb08e0$4d7e2f50@youre641889c92> R0lGODlhhAJYAYfoAAAAAXQMCwSLAHl3AAAAfoYAdgOOf7nJtMLRv5jJ/TMtAVYsDYkhDaYSArQo BNcaAgBKACk3ADE3DmRIAIVBAJlMA7YxANIzAAtcDBdqCD9lDGhmAIdsAKlXB71oDe5rAgCECi53 CTV2AF94AHt/AKF8AMCGB92GCwOTACCZAzmaAFeWA36pCp2uCc6YDuqeAACzCCnACTS/CWHKAIrE BZu0DLjJAOG9AgDnAB/oAD3nAFjZBHPjBpzRAMbTAN7fAAYAMSMATkUAPWYAMY4ISZQAOMQBNekA PAgoSi0hOTQrPVgYOIEiMqgrQ80nMd4fOgA7ORE1TEM0N2RDTXE/NpI6TsBONN5BQgBfNxhiMzdq TmVeRXdtAZRqS8VnP95XTQB0OBtzNEaLMWV9RX54TKJyMrh9N999SAKlTSKWP02dTFSmTXyiR6iU R8CsRuGhSgCyQRPEQki9TGLJPH+xNaTDOM3ARN66OADkRR3jRDXYQVPUSYjoOZjkOMrkMdzkOAAA jC0AiEYAil0AeYMAjKsAecAHgNcAewAocSIhcjwZfWQZeXcXi58kgMgZe+sSdQBBdRlBfkRFeF1E cnQ9e5M4eMNFeeo4hQ1jiCpmeklshGFYjXZljJZUhrpeje1kfQeBex+Ne0t9fmNxjYd5gp11hsl6 gN92gQCfcS6dcj2ghWWldXqoe5SZhryah96oeQK5iRa5cjK+e2nOena4i6vGfcS4eOzKdQDdcRjV gTHfiFXqfo3RiZ7gc8nqcu7dgAAAsyAAyjcHsVwAxoQAyZ0FtMEAxOMAzgwpvyQSyTsnxFEoy4gZ xpIexcIZs+MszABEuCU5wEc7sm43vH03tppFurY5xN87swBgvxhjszJUyVFUtX1tuahsxMNbweZe uwB5xS2AtEKGvV2Hv36BsqOBuLZzuuR8vAuZwh+UzEmbvmCetYmfwKmZt7WetOupvA20uxbNyze1 ymG8vI27zZiyv//185mplXqNi/sACgD/Bvb2AA4A/f8A+gL58v//+CH5BADa5X4ALAAAAACEAlgB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHOnQnsmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWYJLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cONuvEq3rt27ePPq3cu3L1C5gAMLHky4sOHDiBMrXsy4sePHkCNLnky5 suXLmDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buDsLEJBwN0jfhoFLFp67+MZ8 yPP9Sz4Q+XLlzZUnny5wuvPn1qFjv76de3ftBLNH/7f+faF379+lk6+eHTr6gr53y5f/jzhH+xXn 4//NO6N++P0x9J9AA9Y3H0EHEhigcQwKlBNyJiV3EoQQTpiPPRWilCGGF1qYUoYVgtjhhhtG2CGH JqokoksknpjihyeWKKOLKe1WowAo2TiUjjzxyKNRP+bkI472zBfTkEUSmeSSJukYZJNK+iXllFTG FKKEKLaIIowsujjjlluWuNKKYHpopopYlqkmmF9qSGOOUTIJpZFy2qjfnErqR+SdTD55I5x45kkn n0nKV2igghpaqJ+AnsSoS3YKWieOjD5a5aWYLlXRddQ9x96nnhb0Xnjgoeccd5yChxCq7qkaKqgG df/6KqzR1UqqqK4qaBBx9Bnoq669/hpfgPgNq6tCvPImnLEIEtsffdAqCxyzvgaL7IL7LUTtttIm OFC2Ddb24IgXUkjui+2ZOB2XZ6aYnZvrohkvh9aVKWaY58K77rvsttvov5MG/GOQSP65KEwDUyop wZL2uafCjkIMpZyQxmnpSk4urHHEAGfq8cdGbdoqe6yyytB5pap6qnoKvbfyrbjCHHOoprr6cqwq 5/prszwD6+zOCk77s4EJetsbtt0eaJ+ezzbt87dJR6ttsQtOPXS1Py+LdLhcS5QqydrJOurMtNZM s86zgmoy2WmD/bXMtrqM9q5VA631ztQCiLe0UAf/XTfdPFOtN+DC8v304AhlCy7ix2Ld9919d53b uC/S6+bl/dpLI5mce/lm52j6W3mWm38eY+mZd0wxkhlLPPGSrTvc8OsGO8wxwxzbDvvGEz/qe5R+ Psk676vHCfLxyEO17+me64slv6LXO/qV82Lu7rvQZ27u8vVq6e+9tIdfsJ4UH4zo+eIbv2jCiq4f aO4Zr59o/CwxjX7w5Lv//v7hJ+///wAM4FQuNkDgqU+A9TtgUQiIwAYiT3JwWZxYkgUaCXrEghB0 jQM3qBMGOsWDHIQKCENIwhKa8IQoTKEKV+ixDLrwhTC8DQtnSMMa2vCGOMxhXvjBD3vwkCg//KEO /4dIxBJehIdIJAgSl8gPJS4xIUx0YhIjwsQmSpGHV8SiQKq4EC5usYpW9OJAojhGLf7DjGd8IkKw qEUyftGJbyyjHNtoRYQQgAB2vOMdDaLHPQ7Ej/8AZB4L0sc+5rGQeAxkIgXiR0QukpCC1CNBCglJ QzLSkYeU5CUp+UdLKpKTmlTkJjnJR0A2EpGX7KQqRxnJRwpSNjoRog97mBJZnkSWtkSJEHFJy1y+ xJa8vCUtZylMkwSTJcAcpjGVScxlFtOZyxzmMZupkiD28prPhGYzk7lNZqbkjisBp0nEOU4CnISc 4iRnS9SJEnau05zthGc55wkTPcZTnujEpzztwf9Od35Tn/RUST4Des9z7pOfBxXoQBEaToDSU50L JWgRV1IRNKaxIBa1KBTDWEc6wnGja6xjHM3oUTkeRKMYFelFR6pSOpYUpSG9aElXGseVkrSJN1XI K0U5yUS+8pQ81Wkoe+qQn7rSp49MiCWXmlSgCnUhpkTqQXaaylI6dZVK1eRVifpJqQa1lFyNYU3H SlOygpSmMy2rQWCaUY6aFI1sVelaW9pRt35UjWmlol3LCtcpKgSmVQ1rVY06yoZ4UrBPFexWs3rK xS4WrInlKVWp+tVOOjapVvXqZJHqVMp+1bMQbGtKR9sQMYrRIaalK0tNatYyqvGjb60radmI073/ SiS1sE0jYFk7VcwStrKNNaxXEZvVSoISlb3tqmSbukjkEheSgcVkZS3LVFH+trh7bKwnsyvJVh62 lbbJSS7Hy0xfIlOa2NSmTXZZ3msiUZfKNO9KyFvLJcK3vtC0bzflO1/0qpe+MOEvQ/9J4AEbtJz+ LLA7E6zQAj80oQ1FKDjTedAE9xPC94QohC28YXj20cEsoTCFQ2xPCWPYwBqe6FAAnE31uuSY01xv ep/J3hYL+L44prF/cczeGrf4lzvmZo51suAKe9jI82QwgkscT5lcuMkGdsmIB/zkCEP5nQH1J4et /OErk3jJEjWoiE+sZBW7xCI5JS1s4xpb1u62/69ulu1qWztW0a5ZzmitK553q+Y0a5TPdA5sWMEb 3eFCVtDTHaRiDV3c5WI1qogFbVAfW2hEF5q5UG0upQVN6EpjdTY7YWJ/+/ve8+p3lqempqlLLUxW q9qaqSa1q10sZFTX2tVVnEmu4WveG7v4n4UUc5GZjGIMp9jLUkbygU1MbGRHOdgZLvJLUuzIaAu7 xPlUNpYRvGRiH/va+/y2mVMi1nKb+9yjGbe6183udm8Q3fCOt7znTe962/ve+M63vvfN7377+9+O cbfAB07wggswAAFACcIVjvCFn6ThEE/4SiLu8IYzXOIUx3jEU7Jxk0Dc4w63R8hF/nGWZBzkEv8n OcpLTnGOl1zlD0+5Slq+covH3OYkp3nNL45zmBv850BHyshDTnSZg/wlI7/5xY8+85QXPeZQR3nU fZ70qS+d6VWnutO3HvWsMx3rRp960qv+9K+XPehoT/tPhq5xl7vdJVlnuc3jznWfN/3mbbc73MOe 87zTvet8B3tLvP73vb8d8GIPvNoXX/CKIJwgj/9H5AcyeYFU/iCXt3zDNR/5zEs+AJQH/ecTMnmI a/70DfG86UfP+oKUXvSeD33sUW8Q1Yue9LenPepfH3qA+z4zGYd97luve8xT/PSm7/zxWc97hPD+ 8cp3SMaRD3rlR3z3t5/957W//c1zfvXcv7z/+IWve+7//vxoyQnbv85+vd/97h+vON87Dvazy1/+ Kzf5/DWO/6b3/P5G53WDl3eHp38FCHP0136Mt4AE53i5F32QN3zhN3zYV4G1R37ll30a+H0Z6HwU yHzeZ3u0V3njFxEQ6HofGIEouIIgiH4uKBjqJ3P2F3YCqIAI6Hf7l3g6aHYzaIDvl3M22IPtV4N2 138/OHY0WHdaZ3UM2IROyHBQiHc5uHcdR3b8J3dR2HcAyIMymIA8N3dbd4VgmIU6Z4Mu93InJ4U/ +IVZeINP+IZwGIdyOId0WId2eId4mIcq8YJ82If/poeAGIiCOIiEWIiGeEN+mIiKuIiM2IiO/xgb hxiJkjiJlFiJlniJmJiJmriJQvGInviJoBiKojiKpFiKpniKqJiKqhhwnNiKrviKsBiLsjiLtFiL ttgXq5iLukgZt9iLvshuuxiMwrgYv1iMxjhEw5iMygiDx9iMzrhCyxiN0jiN1FiN1niN2Bhvz7iN 3BhC2fiN4BiO4jiOZdGN5niO6JiO6qiH5NiO7rgQ6xiP8jiP9FiPZvaO+JiP+riP72iP/viPTcGP AhmOAgcAN2GQAJmQPwcADMmQU9KQDkkTCImQLkGRJ2GRMwGREbkSGKkTHemRG6mQClkRDDkQJRkX AFAQKfkQK7mSEeGSEAGTCiGTaEGTAymOJ/9pEBppkhD5Dw0pEBrpkjvpk0N5kjmZkyaJED3pkwSR kjv5k0xplEC5lEUJlU2pk0TZkj9JlUQZlVIplVnJk0eJlAfRkmE5lWR5k5+IEyF5kRQZkQ1pD3Hp kHEplx1Jl3BpkHnplirxkRaplygxkSaxkXr5l3IZmId5kYk5mClxl2/JmIt5mIT5mCEJmIxpmI/Z EhNJmSJJjxSRll05laIZmiU5ljrplEKplaB5mlAJk055lUwZm0Apm7PpmrT5mknZlE8Jm2aZlLbp mypJm7cpnAnRm7WpltcImqZJmloZmszZk8u5lDE5nL9pnFEZnLaZnUOZm7A5m7EZlMMJnLz/aZRV aZO8eZXmiZzJqJypOZrk6Zyl2Z7RaZUsSZ3naZ/omZ/iqZRYmZvW6Z0Aep3deZzFOZMBipvqOYo5 MZl2yZcN+qB4yZd5WZgO+qAVqpiIiZkOKpiKiZGW2aBv+aGROaKRyaEaiqGX2ZiLKaIfyqEqWqIk +pGd2YwWsZ022pxdCZ5ouZXtOZo8WZbSGaSlKZb66Z9DGpaqSZPg+Zs52pq66aTjmZpjKZSsGZ5c maCOWBVteZAyqhddWhRfyhNhOqNk+hRbWhNnyhdjKhRrypZl+qZXkaYZ2aZaWpdNQadwmqd6uqd8 2qd++qd7iKWCGowGh6cLamaGCqhzWKPS/0kS7NmoKpmeEyGTkBqcO1qgxWmVlaqjjYqUNkmfX0Gl g5qIy+mon9qjI7Gb3BmpB1qWltqqTBqgrfqdsjqgYBGrowpvbOmXIWqXcwmRgwmsvlqXGtmYvVqs ECqsyBqsfQmjKJqhHBmtiMkSd/mimgmZLtqskjmZdJms3Bqi4JqZkKmosXimDGqn6Hqse2mhgamu f0mh7VqhW8qi0zqtfqmt9Yqvzzqs95qYIqqthDmiAbuvktmh9mqt5OqK5qqu8Sqv8JqsHImsbRmh Dcuu1GqY+yquBLuiQYmwdkqtbvmu/tqvJ/qsGAut+ZqtJJqwePiZp/qjnuqaS9qj7HmarP9KlkEp qUQanmKpqeappDbrqphqqwIKtPi5qpxKleR5pauaq+e2qxEroSJ7ocxatQvblx76sFUrkSm6seP6 pdWar/o6tgKLrQCLsiarrx66smTLspp4rpuptZXJsFbLq1hrrBbLoFv7ovQao+MKsh6rtmZrsBk7 uAdLuGmLuN3atYb7t27bsiQppNAps5HamqgKqmmJs0m6ubrJmlMqqlEKqrX6pJZ7lD17ugOauUfq ndBZuVL6nZ+LtE4rb4V6FInKQrf7uLp7qLarbrm7u8B7F79bQsMbvMZ7vMj7MbO7vMzbvM4rQ0Ah pwNXvMkLvJGrtJELpDrqETmrs9nbEJ//qr08WqnP27wx65wSsZo+mqreexHqS7qqyRAIWr70+6Oe +7mcu52sCr87mr/vq7mlu7QBzLnoS6Cvyp/EWb/P+6iiaZr0+b+U28Axi5qomakW7LMwS7MRXKRE a6n6q8DmW5UZPMKda8H226T7+55KmZ7xWcIo7J7tq5wGKrQgjI8+QbEgSrdUi7chC6wTu5l7y8M9 jMMWipcS26Yfy7aO67XV28R4C7dSK8RRu8M/XLeaObU5XLFEvMOAe7Jtu8ROXL1zW8QPu8XSO8bM WsUQe7EN+6ttjMPrGsQY6sV0LLZh3MQdS8bBSqyOKaM/zMc8HMd3264+nLXKKqx7LMfL/yqxBIvI d/zIRSS9XAvJlNyEkpyRlZzJaLesmtzJOFHDoOx7njzKpFzKphyP1HvKe+qyItG9IOHKH/G+RCu6 Wbm57RvKCSrLGqHLu3zL37sQRTm0AorLAwm1xsrHiJzHUzzEezyhRlyRhuzMcYvM0qzIzgq4jKvK x6vGOQzEervMevyxv6q1UvzE3wzHQEzFJerIf1uYSazNbsvN6KzHbOyweZvOcprPcqvDgnzFKRu4 CAvPCcnKLtzCEnzCQdu/Bm2/KgykrrvQ8EnB2Au+YFmrH5zAxDyqmkvCL1zALuzRG82cJuyjEO3A Lwu+BozRFp3R+WjM9gzFvurPL521Vv9cz3W7z4mst2h8thgbtl4s0Ambx0e8oZxczkP9xnJMtR37 x9T8rulMyN+KouL8zkDtj2TByyjpy8DM0iBMFZfsF18dE6lc1adc1FVi1mStzVy91vOW1m4ddGwd 1+j21nRd13advHKd13q913zd137914At13c92OoW2IYdXoSd2EV02IwNS4r92DnU2JI92ZRtw5B9 2Zid2Zq92Zzd2Z792aAd2qJNypVd2qYx2qh9PKa92qzd2oSa2rAd27L9hK5d25ox27iNi7a925WR 277928A9brw93JIR3MYtiV16u1RNFGOtFMu9E82txHZ8p2bKpdFtjNdbn4JhtFoNoDH/TMMz3N2T ustCK96syxHfrd1bLb+jC8zkG97p259GirkHvL4ePd63Whu+bN5jwd3xPZ2f2d5rIan8/Z/ui9Lq jREGvt5Nu97ibbT7OasNHtIHnt+0Mb/xW8uuW5tfGbv26bMC3LOUOrlSqqRb6ZVoean5KbpP6eGV i7oVDLtTKr4q7pvjS+O1TMEwfpYaLqs6zrpOGsA8vuKqe+M13uAqrp1GvuE97uMqjeFYSaVJyuFH fqnkq7Sm29BB6hnQDaOZGaZlXMRenqGc+c8/PbKI67eXKa4qu+aNvLV9K9VeXrIF67g9La0uurZz DOfNGrB3rsVLHOb++uYDa69lbufS/5rNJqqxzhq2aa6iZ96ide7m7Xy2hfvPa9y3101C9OroIEvn nY62k17pkU7qdnzoag7pp27ql562a0vnAE2yYFzpg07ooq6yf37rjdvnqz7mjaysul7riL7nAT3N bP7mdR7qiXu4w564x57rJ3Tg1Wm693u0w3ztUD7irTvhsHrRUv7iowvlHoye3i7Aq8vhWC7ftNqf r/vQvTntJx7h/1md/WulO4uds9zt7y3v9s6zswrh4e7d3F601r69/mmrlHqfsinRFS0b4n7wB5zt HCzxEU6cuLruKU3D86vwE8/uHGygAH/t6t7v417f4VvwKC+c9J6dHL/SF2+dG7/VLP8P8bhK7yZf 3vu+8Px+8SXv5Kkr8BkfGl1+rMRer4ur6L4OoqKe9PPK6oGe5l8eraWe9GWL9K+Otnq+64PL6H9e skc/6rh+sERP7IwO9paO9GKr7BBK686e6GGv546O6nGu5j+d9cIu97POQS77uhlu3yc+80A+4+KO 5XyvvaGr8Sp/vh1fpfN9qiXu85KL4wksn48qs/CO7TWu7dT+990Zn+HL8w9c5fWe+asb+kyO0Q/M tOdd34E/77TcpJWf+dw55QJO3A5v+7i/GPyd+xlx3GLt+8Af/CDD+8Rf/MaPnK/vFrvfFcsf4Jwh V6WlEdBfUeS4q+w8FckNpkzskUv/4cdg3ObYLKa/L91+0UsBVk2hZkxA4U0su+lJ4f55f8NxiudO gafwzxTmv17p70PrH7y8ChAAANizN1AgQYQFCw5ciFDgQYUQHzJMGHEhw4kXMTaMiJFiRo0KQ3ak WJGgQYgiQY686PChyY8nT6ZEmVJjTZc0O1aMKXMkzpkxM64UiZCfUaRHCSq1d5TpU5P8pBqVqpRp 06ZVnU7FytWq1qVgs3Id+7XqWKpe0YYle5WtWahe3ZqkW9fuXbx59e7l29fvX8CBHcJMiLKuxI0l DftkPFinysIcZ04uOriowciP6T7GbDmz48ihIffcSFhyZ5+LeXpGvVMm6dSiS2Jd/5oUaW2otRPG 3U1b99ekV532Fu67a2/abaNmtX3b7XPkcnULpl7d+nXs2bUXnti69WrG3isrJkweMmjZni0L/awe fGzz7dXPtvjaNP3z9tdXXo25tH4A9xvvruGGw+24Aw1E7rYDnZsOweYalBDC5B6cS0EKraoIOgen m2s7EEMUcUQSNzMtwPfYQy+ol/oL7b/6WFsPJBUDxK+xxLpj0SMeW5SPRwHBI6+7xOzyTyUdzfOx NCIJPI43BQs0Li0LjdPQyikx1LKsqbRSC0susSwuyw2jY/DDEtNUc00276JvSCNlhNO98l7Ekb+e YsxPvPhOHM3P2b6rs7Hz8INRUP89XezsTdFiyy8vKaH0LVInixvzygkzFHM5Ti0l7tMOGaxyUlHb NPVUVPP6Z1VWW3XVVQBejZXVWGd99R9bc8W11Vp59RXWXWlddVZbdy02WGR7HZZYYYtVdlhogRXW WF9zffZZZH+FVtdgj43W2WyZ9VZbbretdlpmw53WVX5YbbfVd/+Jd9V45323XnnhzZfee+nVd958 621X4H39tdffggN2d+B/9d23X4cRxhfhWyu2+GKMM9Z4Y4479vhjkEPGeNyJor21XGIfMnlZgU5W N1mVs00W3Zat7TZmcGXGteRvY95ZWZ95lvXXoGn11uebWzbX4nJ/TjlopWF2Wtv/iAGe2F2ss5ZX qoW55pfhrxt2uKqHub6X7K/t9VpisxM+e22It/ZaK62vFvluvPPWe2+++/b7b8ADp3plwQs3/HDE E+8YYMUbd/xxyCOXfHLKmXa5cswz93Jzzjv3/HPQQxd9dNJLN/10tDNXfXXWW3d943Ffl3121emm /Xbcc/c4Vd579/134IMXfnjiizc+eN2TV3555pt3/nnoHT9+euqrt/567LPXfns2o/f+e/DDF398 8ss3/3z001d/ffY75v59+OOXf37667f/fvzz139//vv3H8T2BVCAAyRgAQ14q/8lUIELZGADHXiq A0ZQghOkYAUteEEMZlCDGzzf/wM9+EEQhlCEDuRgCU14QhRScIQrZGELXfhCGMZQhjOkYQ3ll0Ic 5lCHO/yeDX34QyAGMYQ8JGIRjXhEzAlRiUtkYhPjh0QoRlGKU8ybE614RSxmUYtb5GIXvZg9KoZR jGMkYxnNeEY0plGNa2RjG934RjjGUY1fpGMd7XhHPOZRj3t0oRz9+EdABlKQgyRkIQ15SEROkY+L ZGQjH5hISEZSkhdzZCUteUn7TVKTm+RkJz35N3CA4x+h5BspSfnJ6FEnlKusSCgT4spXguMusCQI LFdJS1raw5W3zGUsWVlLXrbylgjBpSx5uctg0uWYxfylSY5JzF8+E5rRlCU0gf85zGs2U5nVvKY1 penMZPbSmsKkZjLtkktbYlOX3FznOtUpzHaaE53GZCcy2wnOZn5Tn8/8JjnH6c5i/jOdmMROQP95 z4NuE5gLZeg8ESrOew6UoQ+tpkTFadC69BKjsRRoRevpUW9+FKHxFGlGP8pNe06UowuF6Egp6tK8 WBSlIA1pQllKz4aWVKYwNWhPZ6rSiUI0nzSN6E9zStCEhOyUt7olq5a6qqcyVZSjFGVUTTlVqFYV q1HNalep6tSpWlWrX/Vqq5bKVbNilaxgfdVTT/lWtbK1rWq9qlQ31tSswnWtey1rXed61riW9a5h HWta9+pXvrIVr3qVq14RK1f/xW6VsIblKmCl6ti4+nWxkw1kYFoK0IR+dppEvSlHNzpOiRYVnu+8 qFFNulKbOlS14FRoTWmrF3ViM6VAfalQh1rbvuiWnSQ1rWtnSVPZgjamw91taokLT94qd7ellS5p kQqYlu4UtscNLU5D+k5flvO3xWUuP8352u7e9qjZdO5B05nb8650oPZM7mjbO1vfxvecxn3uTcG7 X+FuV7TbJSl8yTvMfha3v0dFMH8xqdTAepWxkL2YZSlL17Gita8ZxrCrrurWwD62YiD2cIg7nNiu opXEc7Uri8kK18dW1sQunrBhP2bhyF4YxSOW7GFPnDGxfnXFKZ6xhl+8Sr7C/5iwOP6kho8p2B2X mMJC7nCNbUzlDUsZsTKGsouhzOXGRhjLXkaxiiP85CPHeMZSLvFmW+wxJo+ZyF3mcY4pbGQ225nJ Ij5ynakqYiXnVcyotCyJgwzkH1t4wma281oVzVkwRznJPfbyo21s6T43OrGGlmxhy7zmO3NWzld+ s6MpvehBX5mxh9YYpjP9asgyOq9ZFnSt6dxJXgr2w0hGc6n/LNY9m9jNscarqX/N6x+TWdBi7vVm i33stIK42L0m9ZZ37WRhI1vVzh62n8GK5GhT+tbhljaoWz3tKud62WquNGDBHWpS+/G68/bscOl9 b8CgEpB41vcf8f1vgAdc4P8DJ3jBDX5whCccgv1meMPHqHCIR3zeDqd4xZEocYxnvJEW53jHPf5x kIdc5CMnORU1fnKU27HkK2c5+lL+cpjHXOYzp3nNbX7zgbdc5zvvIc59/nMP8lzoQyd60Y1+RKAn Xen/O3rTnU65pUdd6pl8etWtjripZ13r27t6173ut62HXexjJ3vZY/h1tKdd7Wtne9vd/nbBmV3u c18T3O2+drrnXe9753vf/f53wFvv7oP/euANf3iCEF7xVkd84x3/eMiPffGTp3zlLY/KyGfe7Jfn fMs1/3mxd170JAd96U1/etT/e/SrZ33rXf962Mde9rNXfOptf3vc5/6LtOdcfe99/3vv6V74KQd+ 8Qc5fORn3PjL93fynf986Efff8ynfvWtf/2+SV/72+d+973/ffCHX/xBx375zX9+9Kdf/VIcf/vd /374x1/+86d//e1/fxquX//753/rAwIAOw== ------=_NextPart_000_0005_01C72542.41EB08E0-- From risks@bcno.net Thu Dec 21 18:32:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxXP6-0008RO-TD for ipfix-archive@lists.ietf.org; Thu, 21 Dec 2006 18:32:48 -0500 Received: from host154-196.pool8289.interbusiness.it ([82.89.196.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxXP1-0005Ii-I5 for ipfix-archive@lists.ietf.org; Thu, 21 Dec 2006 18:32:48 -0500 Received: from alain ([149.103.179.99]) by host154-196.pool8289.interbusiness.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Dec 2006 00:32:42 +0100 Message-ID: <001301c72558$482e92b0$9ac45952@alain> From: "Code" To: ipfix-archive@lists.ietf.org Subject: stating changed retain Date: Fri, 22 Dec 2006 00:32:30 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C72560.A9F2FAB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.3 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e ------=_NextPart_000_000F_01C72560.A9F2FAB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C72560.A9F2FAB0" ------=_NextPart_001_0010_01C72560.A9F2FAB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Failure commercial losses even advised. Acceptance indemnity andor rights. Prepare publicly display perform sublicense distribute. State above = nothing herein. Of the project is, bythe. Result out, inability, loss = goodwill stoppage computer failure. Licensor copyright owner or entity! Verbal written sent its systems. Separate agreement, executed regarding. Systems issue tracking managed purpose discussing improving. But not = limited files object. Defend hold, harmless incurred asserted reason end = how apply? Is bythe software foundation made available. Legal union acting, other = entities control. Trademark, do pertain part includes text file readable contained. Trade, names service marks, product required reasonable, customary. Copy modified carry prominent notices stating changed retain trademark. Mailing, lists bug database charter. Then licenses, terminate, date filed may copies. Indemnity andor, rights consistent however. Andor rights consistent = however act, sole. Indemnify defend hold harmless incurred asserted = reason end. Alongside addendum additional, cannot be construed modifying statement. = Lists bug database, charter patches building! Reproduce prepare publicly = display. Stoppage computer failure commercial losses even? Fifty percent more shares iii! Disclaimer, warranty applicable law agreed provides basis warranties = kind. With purposes definition means? Download, view source code = repository general support mailing lists. Character, arising result out inability loss goodwill. Made available, = under following? Kind either express implied. Origin content disclaimer, = warranty. State above nothing herein supersede separate agreement. Any resulting = from mechanical compiled generated media types work. Yyyy licensed = compliance obtain see specific. Date filed, may copies medium without meet. In indicated notice included = attached example. Advised accepting while choose charge fee acceptance = indemnity andor. Improving excluding marked designated writing. With purposes, definition = means power direct indirect. Making including but not. Agree indemnify defend, hold. Theory tort negligence deliberate grossly negligent acts. Jul about us = home. Bug database charter patches building releasing wiki, related. Nocharge reproduce prepare publicly display perform sublicense. On derived which editorial revisions represent, whole. ------=_NextPart_001_0010_01C72560.A9F2FAB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Failure commercial losses even = advised.
Acceptance indemnity andor = rights.
Prepare publicly display perform = sublicense=20 distribute. State above nothing herein. Of the project is, bythe. Result = out,=20 inability, loss goodwill stoppage computer failure. Licensor copyright = owner or entity!
Verbal written sent its systems. = Separate=20 agreement, executed regarding.
Systems issue tracking managed purpose = discussing=20 improving. But not limited files object. Defend hold, harmless incurred = asserted=20 reason end how apply?
Is bythe software foundation made = available. Legal=20 union acting, other entities control.
Trademark, do pertain part includes = text file=20 readable contained.
Trade, names service marks, product = required=20 reasonable, customary.
Copy modified carry prominent notices = stating=20 changed retain trademark.
Mailing, lists bug database = charter.
Then licenses, terminate, date filed = may copies.
Indemnity andor, rights consistent = however. Andor=20 rights consistent however act, sole. Indemnify defend hold harmless = incurred=20 asserted reason end.
Alongside addendum additional, cannot = be construed=20 modifying statement. Lists bug database, charter patches building! = Reproduce=20 prepare publicly display.
Stoppage computer failure commercial = losses even?
Fifty percent more shares = iii!
Disclaimer, warranty applicable law = agreed provides=20 basis warranties kind. With purposes definition means? Download, view = source=20 code repository general support mailing lists.
Character, arising result out inability = loss=20 goodwill. Made available, under following? Kind either express implied. = Origin=20 content disclaimer, warranty.
State above nothing herein supersede = separate=20 agreement. Any resulting from mechanical compiled generated media types = work.=20 Yyyy licensed compliance obtain see specific.
Date filed, may copies medium without = meet. In=20 indicated notice included attached example. Advised accepting while = choose=20 charge fee acceptance indemnity andor.
Improving excluding marked designated = writing. With=20 purposes, definition means power direct indirect.
Making including but not.
Agree indemnify defend, = hold.
Theory tort negligence deliberate = grossly negligent=20 acts. Jul about us home.
Bug database charter patches building = releasing=20 wiki, related.
Nocharge reproduce prepare publicly = display perform sublicense.
On derived which editorial revisions = represent,=20 whole.
------=_NextPart_001_0010_01C72560.A9F2FAB0-- ------=_NextPart_000_000F_01C72560.A9F2FAB0 Content-Type: image/gif; name="describing.gif" Content-Transfer-Encoding: base64 Content-ID: <000e01c72558$482e92b0$9ac45952@alain> R0lGODlh3AFcAYfoAAAAAIIAAAByAHJyDAsAgnwEgwCNeMy8uLncyafM40EVA10uAHgqDKAYDcId AOoUAAY3ABVOBzk2AGJOBHpNAKg1AMUyAt02AgFZBC1UAD9oAFlXAINbAJNdAL1pANFTAAuAAByI ADZ7AGFyBId1CquGAL9+AOSCAACuAC6UAEmoBVifAIupAJySArmoC9OmAAfEBiy2AEfBAGC3AHzH AKuyAsfMANPHBQzhACnbDDPsCm3rAITrAKTnC7vWANXVAAAOQhIAPDkGPGsAQI4MOK0OR7IAN+EI SAAgNhMWN0wXSG0eTHcbPJ4dPL4mRdotTgtDQB1KOkY7NlRHSI0+SqszRcs5ONlJNwBXRSFbPzlc MmxkM3dRBZZcRsJYP+FfSQ55RCGOMTSKQmqIO4uJR6OHS7GEO9KAQgSmMSSRNkiiSWKhS4CuSaSt MrKiN+qXTQDEOBzMPEm7N2nMOoS1MqbJPMO1Pta4OgHtPy7ZNTHmR1HWN3LfP6TeMsnpRNvTSAoA jSsNdUYAhFEFfnEAiZQAh8gJfOEAdgAnjC0WhUwXhlwqe4QUeqEpjcsUfdgjewA7dCEyd0cycmQx hH83dJ5IdsZAh+c1ig1tcRpfg01ihFhefohojahjh8FUitJhigCDdRGMfDR/c1yBgXd8g6t3g7Z6 h9SFfwCbhSefe0Cne2Kpd3yscp+lccaig96qegS/hyHEg0DChlazcoW9hpzDhsG3iunEegDteRrm jTnrfGXsfYbaipHReLbrhuDWcgQCuigAtEEKzGMGy4INzaECzbwGxugOtQAqsRYttD0qx2AZvHYd uJ8lxrMkueUYuABHtRFMtjNKxWQ2toRGuJFNxcQ2s+40zgBbthRrvk1oxl5axXFYuZxcw7JYt+ts wgB0yxJxwj2Ew2x6sn+CuZGKt7GDvNuBwAWUwC2tuDOiyWOfw3mgvJagtcGdt+CpxgeyxiDIuka9 zme3tXfBx5K8y/Tw9aiurItzgPoACQD/AP//CQEE//8K/gD//f/5/yH5BADSzy0ALAAAAADcAVwB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8eF9kKKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8qPQIMKHUq0qNGjSJMqNeqzqdOnUKNKnUq1qtWrU5dq3cq1q9evYMOK /Ye1rNmzaNOqXcu2rdu3cOPKnUu3Ls6xePPq3cu3r9+/gAMLHky4sOHDiBMrXsz4o93HkCNLnkx5 Z+PLmDNr3sy5s+fPoBVXHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLlx26uPHj yAHnW57v3/KBz587b86cucDq1LFDt36de3fv35uH/49ePaF36eOzo8eePbn790t1Lg/JnH4+e/Px 388vkv9I//kFuN99+qE0n4AkIWhSffb9R2B/AzoI4XAUVliVgAdGWKB/BZbEH4ARKrighhx++OCE InaI4okmWujiiz4hWJ19GJoI4oQrgsihfjaKuGOGDULI4IwSBgnjkRRuJN2STDJpnnjTbUcQeehN CWV4UlqZpZXcVVnldF+udyV8ZJa5l5PdYRklQmJquSZ5BoXZ3ppZfkknnFum6eWYZvbpZ0Y5zdii kezxeKODg2bIYJGK1ofdiDk2CqSKgyJp6aWYZqrpppx26umnoIYq6qgk/WnqqaiiKoAAGq26l6up xv8qK1M4rWqrAPasmpOuNN2KK0+8xnTrSMGaNGxItoqULLLFkuosVRzB+o+0F1ErEazWYpRtRNhu a5Cr4LIa7rSszmpuZjsF6yuz7A577Lq58irvr8bSO6+9y+br66/wxsvvsiWpS29KuhaMq8HxPquw VdGWS65A4z5sK8QOd0tQt95SPNC4EWvMsbggexzyxAdRm/HG5X4sMcnntpxYuvi2+2/Cys5M87sA 11uzvwjXnCzCPRv888DEEt1swDEDffDSCzf9VMMoiyz1xSGv/DC50lpr8dUaRx21ylZ7XVC2WTvc tdQqn+zy2qGV3bWvXN9KMclyn8313CbTrXfaILP/LPe2cGOdstmCD15x2YSzrbhfpgmc2tFOR04q 5JJXHvnimGeuuUKWd+75553yIzo/PI1OOuiddmT6QKavLpDrBsH+j+wM0S576wThnpDrrY8+O+2/ i547P68Tz7rvsSMfvPHFH//78MUL//zm1DO0k+ghYT+S9iJpz/32pHOP/fcpeX+6PeZ3f7r4659P Uvrqg5+9+/CjP/759YOfPvvx2z///PxDHeq+R0D6ue8k94tfARF4QP/1r34BfF8D//dA/BkQgKOj 4EsSqEH2kU+CAhzgBfunQZS0Tn0ZJGFJTKdC86WwgxO0H/kK+EIHUrB3/2PhSk4IQ/mVL4YhdNoC /1sIxAresIgmyd/+RmhDBvowh0x04P3ap0ITUtGGQ7RiEC3FEelJz3nQm15BvGg8MoIxec1L4xfN qEbmjbGMbvzi9OTIxjkyr44KYeMa4+jG6vlRIqWrYQkxyMAX8nCQ+jugDnsoww8mEoQkpOEIJYlE DBpQkI584hY3yclOevKPoAxlqjxJylKa8pSohIsoV8lKPxKAAAd55SsNIktYDmSW/8BlLG2Zy1rK siC+/KUucenLXdryl7dEZjKJGUxeLlOXvVRmNHlZzF4KZJbNdOY1j8lNZDJzm88kyDC12Urj6OSV JUGnPdQZEnWyE53sTKcsSRJPk8TznQRoZz5RMv/PdeJTnyJx5z4BehKBBnSgByVoPed5T4TSE577 XGhEJ6rQgf4zlb2R6EgMmlB/1vOhGk1JQzv60Y02k6AVLahDTYrSkD4UpP1EqTxrKVN9BrOjL60p RnHjUn/KVKAlTSlOVWpSX9q0pNn8qUVjqtODMtWoPp0pUJ+6Uqf2E6oexWpWWdrUndZlI9C0ZjLB OVZrhvWZ0DwrMJ05TrIiBJuw/GZZxclWco41rdpUa1jhWteE8NWtaJXmXNtazuScc6UcFWpUkUrR odoToRcNKkAhStKlKpWfjY0qVxOrWM3Ks7OV3WxVvToasFZzmrSUJmHnKtbWvrWvZD0tXWcbTrr/ 7tWubmWmapVZTbkCdq2xrSVtb4tX1hb2uMhNrnKXy9zmwoe00I2udKdLWuda97p60UkAAiCS7Y5k u94NCXjHy12SkFe84QUvetVrj/Oal73tZW96y7te+r5XvuWdL37h2138fte+/Q1vfPk73voWuL7/ 5W98qesiATs4vwAWcEkkPOD1ove9F+5vhhds4Qdv+L/35TCF5wtiEUPYJCTmcIklPOITZ5jFAGaw aTay3YHU+B83FkiOcRyAhOyYx+TtMY8LcuMc/9jGQgYyeHWcZB83WclFfnKUkYyQ8Vb5yUMmyJGp zGUmeznLX8buH4Ms5B2bGctIXjKU1UxeJqvZ/8tWDnOQ4fxmLcd5zlB285mVbGeFxDnPYDbInrnc 5j6LecxJnnKXA01kKfe4xoqm8qDBbORHR3rLP4Z0pOls6EBvWdBldrSTO51lTTf60GXSLn09rOIP YxjE3k2xhlsta1bbOsatNrGrZa3rWaPYxRTu9a5dLGwZv4jVCH71r/07a/cie8D6BbZ93XvfFEeb 2DAmMK4DvOoDJ9vX3C6xioNt7HKb+9zoTre6U4Lqdrv73fCOd2HWTe/Lyfve+M63vvftkXr7+98A D/iM+U3wgpNF4AjnlMEXru+EO/zhEI+4VBhO8Ypb/OIYz7jGRynxjnv84yD/ycZHntyQm3w3JP9P ucpXzvKWu/zlGDm5zGdO85rb/OZxgbnOd64VAAAgIj7nudAL4vOi46XoQXdI0pOOEKYLxOlKR/rP DwJ1ilR9Ikgf+mF04nO5dD0mX/+6S8Q+dgCshOxqQTvO16KRq2f9H1Jf+tvhLnej0/3pU6+63u0u d7r/XOp4D3rdB5/3vRP97XwfvN8VL/jEF/7qAyF85O2udc0Y/u6Nx3zhCZL5uy9+8lRPPN493/m+ i970m+/85EWv+dE3fvOaT/3UWw95zsNe9ZXHS07UHnazd/33vje7PXoP/JAQX/gsKf7wg2985i+/ +c+Hfu+jD/yikwTt0z++86m//ekv3/rRR4n/95W/9spgX/jFTz/6ma/844tE7SNpv/PlL33k0z/7 yL9+/rnP//fbf/3hJ3bk53/Qp38FOIDhV35NwRGA93m093dzl3V9N3qgd3iUF4GIB4GuN3uSt3iP N3uBZ3QTyHgcmIGgl4GvB3urp4Gkx3q51xVrAX/Jt39zIYNNYYMzgYMKOBw6eBI9mHbgRxU/uINE WIRGeIRICDpDWBtLmIQ+IXVPSINQWBJN6IP5F4RUGHzwh4NI13y814Vd6IUFqH9ViBPe54RWUYYw 8YVjuBNQiIBiSIDxJ4V0OIcGmIXPF4YmoYY3IYA0iIYn0XYgSIEp6ICOV3eHt4Gl53gVaHtM/4d7 IWh7iTiJktiIFJiIhdh0H1iCmXiBiud3l1h7L8gRu1eHeUh89cd/bHiKAEh29JeF/5eApyiHduh/ euiHdIiLtjiFd4h/c9iKV9h97BeLgLgSgmgQqNeIgJeMFjiBrbeCgxh6steMkHiJlnh5yAiCTieB 0TiCLBiKKHh73GiJo9gXUMeMnpeOLaiO1piOuHeO0RiJiyiJkIeNbqeC6riNItiN4piPJUiP/1h7 oliOY9GAy/iPK7iO7AiPFRiO7eiBq3eNEEh5D0mNDhh7H1iJFCmP4viOh2iI+0iOBOlcA4l18Vgm JTmSFmEpfKgSLekaL1mEKjmTNFmTG+cUMf9ZjDr5Em/4hynxhXpYE3Fnhj55h7S4i1qYkzsZHOe3 hj6plLVIlGcXhlhogFC5lEy5f7xIldZXlW0IfmA4lHsYjOunfXEIlrmolU8JgFj5Gxthgs/4ehXp jhp4et9YiQDZj5n3iPG4kfWYkTaJavOIjn8JjXT5jJT4eXypiNUojXj5mHMZmLLSE/cHjEcZla4Y i3AYgMMohwPoh1YImgdoim2pG4LIep+oj6HniN+4l32pjSFpmCD5kA04m/qYkpKZmw2Bm5qom76p FHNndSf5m8RZnKNYmsgJFca5nMXBm1EXnBURdxmRkrfpmBDJnJMplZRZlDnInU45lV25lrP/mJyi cn5m6YVbSJbo+X1BGZXft57sWZZnmZaXSYCbSZ6bkpmpOJ7paZ9amIr9aZXj15miSYa7OJbV5534 eST6yZ/z94e4SH7qN5a/KIz1F54zaJkUWp8LeikNWpltSIsNOosBSqLE+JnECIudmYAj2qGZMoVc OZpeyaIYCqAQSpbbF5/weYZIaYue6X4uijpXGYVCqaBB6kntyRZJ+p1HykXY+aS616RSOqVUWqVW uoBQmqVgcaVcKhJa+qUw2KViOqZVCqZmeqZo2hlkuqZs2qFp+qZwGqeE0aZ0WqdLKad4uhF2eqR5 2qcXsadB6qeCOhGA6qKDeqiImqgaUaiM/xobNtiEM3qDRloWkVqk2vmTk0qkIVSp7kkXTSmLmBqi eGiU4seWPBGTbFiFPEoTPTiEOtiqpoopDDickMkXDMmOCsGbzqmRtMoVAtmr2RiZEFGSuLmrvYmr zDWY+8iPmxiCnKiXGIiIzmqB1wmK1DiR2GqtJwidoFibGwmSGSmt3OqQ25qt1Nqt0TqtkbiQcHmI j3eRjMms1fqtrKSsIrmtG5ivccmCHrmvk5iMtyqXh4mJ+KiQrkmJrjmNjYmO+IqsB6uQ+mqvvOqP 6+iMANmO3oiY5TSPEMuaFTuN/sqwB4mx0OqXIEuI/NixBoutKQuRi2mQLVuNqrd3semNEv8Licw4 johpeBa7stW6sfwakCl7s0H7sfpqjT2bsYWpsUzrrxPbtBerjHdJskfbsFTbkApbtAxrtA/br1Eb sCdbWJ64rAWrmCD7iS7bkYBZmw2LtihLl0lbtASLsvBIglibiR6Lq6hHs2cbrmpLsqhZs7LHkD3r tNzqJ43qFkMaQoqaGMYqb4lLno07uQWhpJkah5H7Saepq2Wbqy3bgmNLjoxoEY9LusBKuYjxuIXr ucFatREJuIF3EaUbnaeLukpRiio6mu/JixUKn2MIh6+IlGgJpF45vDdKvGL5nqCauZ6Klvv5ip8K vCcahMGLnmF5ofv5oyH6oQTavcw7cR3/QbQ+O7H2OIgdSLh1ebJsO74Sma8J25i2G6Zu+KCqyJbR m6O/q5acaYUmmr0yOKCk6osT+r2UsZXUG6Oryp6iqqMMDJqfKqOxmqRASoZlaZnut7gEXBLxu8Ec LKgZfKcdHMKWN7sijDmluKRpKJ7zu8AfDBvH+BckvJolfFx8u67QyJepybMOucPSGbvouq7rO8Of ccI1Wn14OMBGPJ7++bzAaMHBWL9M3MKo8cJY67Dpa7Tq2rZyO7NXbLYRK7dC7DJga8UPeLSFmbPq e8Vdq7X9GMacgbsUvMBI7LwHaoe+uKOa+aB3HKP9J8VIiMF+DC1uPMiEbJOBjIZBEcND/6HIUfcZ ctQQjzwRkSzJffSkjMy6c/uvvcrIogi/e4FHaBRGEgHKFDHJLIeTl7udowrIG+qSqZwW+cMSmbRD V2QTs4xzMCqf84mKvTiM6qeWSfl/Tay/8lfBFcyKmEt2CbTM4dPM/jNDKaRDS9TM0ZxBLnTN7WNB 2dxI2mxJKFTL30xI3HzL9SbAOSqh+KvASiy9ujuhxeu9IBrFPMrMz+zM9PxESwRFRyRD+lzP+kzP 8LNA+ezPmpTPHLRTL/y+a9uszfi2Tau043iP0jmyPtuBydM7y7M6vRPJekQ8ZtTRYiQ8Hw1HGV3S IL08dpTSj0xHJC3SHl3JLQewsHmYv//qjA/7tP36l3Dp0GXMrm8EOxgdPcqzRyrd0iT9PEQ90s3D 0mGk1C691EYN1U390kgN0ywHs0BMtjaMl4VYuBwb0Sdp02Trt3RbsHV01kdd1WS0R8jz1FUNRroT 12091ymN0h190rxD127dcJdajOSMlVT8pMBTyIQ9kod82Iid2IqNcoWdpov92JCNOo092ZStc5F9 2Zid2Zq92Yxa2WbK2aAd2rLq2V8q2qZ92hVC2qq92heH2iHH2lDq2iAH27Rd27Z92++xE+Cw27st Erzt2+AwEr1tEsM93PbA28EdEsbd28hN3M193L8t3NEN3cod3MjN3NMt3c8N3cat3cv/Hd3XDdy/ /d3VDd7brd3And7hXRLr3d3lTRLhfd3JTXMbsdsHwdsDYd/5DQ4Jgdz7LRD6rd//YN8Ezt8FEeD8 XeD/PeAGruAMfuAJbuAGIeAPXuEEgeALTuEALuEb/t8aruETLuD4/eAYDuEdDuIj3uEXzuGGjBPu Xd3UHeMwfhLP3d3Yrd7WPd/pTd03LuM8Pt3u3ePsPd82ruMyXtzJHeRGfuQ5Dt9LLt0x3txCruQw TuVIPuTlpxEgTuINzuFbvuAWzuUenuIrPuL+reInTuHXveFfbuFqzuIi3uX7XeIrnuEpfuYmjuH+ HecmLuZ1Tudz3uZguuVrHuaCzudj/z7mhC7neP7mDI7ogd7fEu7oda7iKB7hIQ7maL7pbF7i+A3p nS7nZQ7onF6TOkHlVa7jLw7lO37lqe7jM37j5B3lTQ7rQu7krP7irg7rtI7rM77jwP7rU17rum7k Rd7qxv7kM8cRa87nzY7nlR7pgS7qH37mdN7ojP7spR7mj87ioR7phf7t3d7lZg7taO7gXE7mmj7u bj7pex7uMynbH4fbxSnvHkfvxGkX5z0T+27vm7Lr203e/c7dOW7eOB7r2V3eRA7kAR/fCS/sCz/r V77q/i4VDY/wB7/q8v3qCI/kxY7xrr7rHI/evV7yE6/sFQ8VNa7qtf7jvO7rw67wKv9x7D0u8MnO 61Le8rS+8S+f8lEx6yOP3RTv3Um+8MFO4yxP8MAu9B7/5Ezv402/8j7fEszu7n9u9eZ+39kO5oK+ 6QUO6eje6VrP5oZO7oXe9fgec6ee9CXv8kMP8kb/6ykR8sRe9HLv8r5u8hG/3lPvElUP4W9e7ts+ 7YS/7pKO6F8f5+/O6WCv7tfu7WlPin0/+ZQPGZGvm5Wf+ZqvSpcvmZv/+aB/Fp3v+aGvbqN/+qif +qofFKVv+qtv2K2Pbq8P+7FvbrNPkLV/brdfjrnf+75fE7t/nL8//MRvjMF//MhfHMW//Mzf/NSV /Frn/NI//dTfSdB//dif/ZRd/dz/X/rab9ndb0rfD3PhX/6ZP/7on/7qr6jm3/59v/4r5/7yP//0 X/9tCv/4n//xYf8CpP8jBxD2BA4kWNDgQYQJFS5k2NDhQ4gRJU6kWNHiRYwZNW7k2NHjR5AhRY4k WdLkSZQpVa5k2dLlS5gxZc6kWdPmTZw5de7k2bPhP6BBhQ4lWtToUaRJlS5l2tTpU6hRpU6lWtXq VaxZtW7lmtTnV7BhxY4lW7HrWbRp1a5l29btW7hx5c6lW9fuXbx59e7l29fvX8CBBQ8mDLTsYcSJ FS9m3NjxY8iRJU+mXNny5ZCFNW/m3NnzZ9ChRY8mXfozZtSpVa/+aNr1a9ixZc+mJV3b9u3RrHXv 5t3b92/gwVHjJl7c+PG1wpUvZy4W+XPo0aUnDQgAOw== ------=_NextPart_000_000F_01C72560.A9F2FAB0-- From nuyilmu@columbia.com Fri Dec 22 08:10:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxkAX-0002xJ-9o for ipfix-archive@lists.ietf.org; Fri, 22 Dec 2006 08:10:37 -0500 Received: from [221.203.234.138] (helo=[221.203.234.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxkAV-00040M-FJ for ipfix-archive@lists.ietf.org; Fri, 22 Dec 2006 08:10:37 -0500 From: "Drug testing" To: ipfix-archive@lists.ietf.org Subject: Status Meeting Date: Fri, 22 Dec 2006 21:10:33 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0002_01C7260D.9E2AE4B0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccmDZ4q5Gxqmdy+TaiglOFSBIDl0A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <2ABAF0631162619.6DCFFE3276@columbia.com> X-Spam-Score: 3.6 (+++) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 ------=_NextPart_000_0002_01C7260D.9E2AE4B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
TTEN Continues Explosive=20 Growth
 
TTEN *** TTEN *** = TTEN
TTEN - Ten=20 & 10, Inc.
 
Current Price:=20 08
Short Term Target: .50
 
TTEN recently = announced a key=20 development which will enable them to provide Value Added Services to = the=20 55 million wireless subscribers of ChinaMobile's = Guangzhou=20 Division through its joint venture with IEC. China Mobile is the = largest=20 telecommunications provider in China, and the largest among all = the=20 overseas listed Chinese companies on the Hong Kong and NewYork Stock=20 Exchanges.
 
TTEN is made up of 4 = operating=20 subsidiaries:
 
          &nbs= p; Tech=20 10: WIFI and=20 WiMAX
          &nbs= p;=20 Mobile 10: Music and mobile entertainment delivered via Internet, G3,=20 etc
           = Dream=20 Learning Center: Digital Media Learning=20 products
          &= nbsp;=20 Ten & 10 Network: Sales and marketing
 
Telecommunications is globally a = TRILLION dollar=20 industry.
 
TTEN could see explosive = growth as a=20 newly trading company - 500%-1000% is not = uncommon.
 
 
Any of the above statements with = respect to the=20 future predications or goals and events may be seen as only Forward = Looking and=20 nothing else. All information inside this email pertaining to any sort = of=20 financial advice needs to be understood as information and not advice. = None of=20 the information above can be constructed as any sort of financial = advice. This=20 is a paid advertisement.
------=_NextPart_000_0002_01C7260D.9E2AE4B0-- From richendrawylie@love.km.ru Fri Dec 22 09:11:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxl75-0000c4-IH; Fri, 22 Dec 2006 09:11:07 -0500 Received: from [122.4.21.96] (helo=love.km.ru) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gxl72-0005nZ-K9; Fri, 22 Dec 2006 09:11:07 -0500 Message-ID: <2c3201c725d9$58bb2860$b5124db9@richendrawylie> Reply-To: "CLARENCE" From: "CLARENCE" To: "MINDY" Cc: , , , , Subject: CLARENCE Date: Fri, 22 Dec 2006 14:56:23 -1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 4.8 (++++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 CHARLENE, Our attorneys just found a loop hole in the bank laws. Using this discovery, we have been successful at totally eliminating peoples creditcarddebt without them paying another dime. We GuaranteeThat we can do this for you. Contact us at: 561-282-9476 When he removed his hat the last piglet had disappeared entirely. He's worked too hard, I guess, said Mre6m5 i do not have marks please no more. reply to hear less and the add. is post office l2 zero zero in a city called orangestad a ru ba From ago@fabtech.com.au Fri Dec 22 14:47:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxqMq-0003SA-JM for ipfix-archive@lists.ietf.org; Fri, 22 Dec 2006 14:47:44 -0500 Received: from s0106001731958047.vs.shawcable.net ([24.81.234.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxqMn-00030J-Ft for ipfix-archive@lists.ietf.org; Fri, 22 Dec 2006 14:47:44 -0500 Received: from VRQHKLFS (unknown [126.108.23.73]) by fabtech.com.au with ESMTP id 5B605091AE06 for ; Fri, 22 Dec 2006 11:47:58 -0800 (GMT) Message-ID: <001301c72602$0b0bc7e0$00000000@noned2748ff55c> From: "page" To: ipfix-archive@lists.ietf.org Subject: include arc visibility lights Date: Fri, 22 Dec 2006 11:47:42 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C725BE.FCE887E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.4 (++) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc ------=_NextPart_000_000F_01C725BE.FCE887E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C725BE.FCE887E0" ------=_NextPart_001_0010_01C725BE.FCE887E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Oklahoma familys escape from dust bowl join migration fruit. Basic = seamanship covers, licenses, passenger six pac. Price teens occasion, see guides. Passenger six pac, ocean operator tons = subjects. Snowman viewsa, giant inflatable frosty falls victim bored. Dailyhaha retarded fresh badjocks crazy humping frog. Include arc visibility lights. Will not give, freedom carry paying passengers vessel. Make, better everyone please note unable respond directly submitted. Series comment just speaking, fast june. Trailers music and viral or. = Like update editorial back cover recognized ultimate tests boating. = Based click link rss feeds recent videosthe. If need question service well provide comments. Contest best of videos = movie weekthis monththis year. ------=_NextPart_001_0010_01C725BE.FCE887E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Oklahoma familys escape from dust bowl = join=20 migration fruit. Basic seamanship covers, licenses, passenger six = pac.
Price teens occasion, see guides. = Passenger six=20 pac, ocean operator tons subjects. Snowman viewsa, giant inflatable = frosty falls=20 victim bored.
Dailyhaha retarded fresh badjocks crazy = humping frog.
Include arc visibility = lights.
Will not give, freedom carry paying = passengers vessel.
Make, better everyone please note = unable respond=20 directly submitted.
Series comment just speaking, fast = june. Trailers=20 music and viral or. Like update editorial back cover recognized ultimate = tests=20 boating. Based click link rss feeds recent videosthe.
If need question service well provide = comments.=20 Contest best of videos movie weekthis monththis = year.
------=_NextPart_001_0010_01C725BE.FCE887E0-- ------=_NextPart_000_000F_01C725BE.FCE887E0 Content-Type: image/gif; name="Philips.gif" Content-Transfer-Encoding: base64 Content-ID: <000e01c72602$0b0bc7e0$00000000@noned2748ff55c> R0lGODlhvAGUAYcJAAAOAX8ABgiHDnaMAAAAhHsAjgB9iLK5us3csqi96TokAFMmDnkVAJEbALga AOQhDg41DC1EDTZMCF06AHZLBp43Bcg4AOBOAABsACFfB01iCGVnAIZSAKRhB8NgDNRlDgCBABl/ CD6NDGiNCYKJAKOBALN2BOyMAAmmBhOZBUSYAFyuAHukAKOnALygAN2RAADJABWzDTzCCW6xAInC AKm6DbzFCuPLAwrdCxHpAEzhAF/uCn/YAKTiCbzUAdTeDAAAOi4GTjwASVUAPn4ARZ8MQMEAPeYA QwYrOiApR00dNF8iMYYnSZYrTL8RSecYRwlBRR46MUhJQ15OOIM6SatJMrVHQecySgBuOCRnMUtu SlNTR4NiBaRcOM1SNupYPwqATh+IP0dyMVV+OIGMNZ1ySMCDRON3RgijQR6bRUatNWmWTnOaPaaV RbmjMuOsSgS1SynHMjzHOVnATXy8MqnJR8q8Ttu8SgDbRBzdQz7sNGvTPHbkQqLTQrrsTOrbMwAA eBgMfUkEi2AOdXsCeqQAgbYHdusAeAAaiyMVdTQhhFElfX0Uhp8ojbobjeMbjQBJeCpMjjhKimpI doVGdaFOdcE4iexMhwBReBppi0lWdVpei39uiqZljrVkgdVhcwCAeh6AizFzg2OLeY1xdp6CiLKA cuaGeAOVhSyYfUmodFKfcomuf5eSc7Kbi+edfgDLeyjBhEGxeVXFiojEha66hMbCjuzFcg7ZciLg dUPigVrpc3LWiabVf7LVgNvZggAAxisAs0YDvmUHy3gBvKoCyMwAvtsHtgAutRwctjIVw1MXt4Qn wJIVtsUuzeIgyQAztx5EsUA+wVMzsoM1yKw6y7Q4v+pLxQBXzCJrszhqt2tbuoBpsqNdyLxhs99g xgGGuhGHtj6OwmZxuoh1sqmBsrGKytN1zQCfuRWsxUeRwmSpzH6YxJ+YtbmizNinuQC5shy8sT3K wVfAzovBta7Nxf//85mnsnGBf/8LDQH+Bfz6BQkA+P8A/ADz8fP/+yH5BAArt5UALAAAAAC8AZQB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFNutMeypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjM1UqXcq0qdOnUKN6REq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiN1KXcy4sePHkCMjTEy5 suXLOCVr3sy5s+fPoEOLHk26tFLMqFOrPmy6tevXsGPLnk27tu2Uq3Pr3s27t+/fwHMu/EC8IPEP /44rP568uHHnB5cjv029uvWlNY+/1K49ZneX37cT/2cZPrj584XLcx/vnT149+8/xEdPvz7d4dAF MmcePb9+/81NRxB/1xVo4IEjEfgfcgoOCGCDARoEIYIUVmjhQ9ItF2CGET4n4EAQTnjhiCSO2OB+ AC4o4YMsfljiizDOlh189qwnX3s3zideji2VZ9+PQJaFn4soughiiysaKWKMTDYZ24nFiRhiigou 6eSVWIoGJYMpduigkSp6meWYZIK25YbSoVmkhkcqV+abcMYp55x01mnnnXgaFOSefPbp55+Aopbn oITKFuihiCaq6KKMNuroo5BGKumkVhVq6aWYZqqpppR26umnoIYq6qiklmrqqaimquqnm7bqqlSr xv8q66u01qqSrLjmquuundrq668h8SrssMQWax+wyCaLkbHMNqrss9BGK+20FTVrbaLUZqvtttx2 6+234IYrboXXlmsufZuke+6n6ba7CUvtvhSvu/HK625L9L5rT778quvSvf/6ay/AMBEM77z9vmtw vfXuS69M/Bb8ML4CN4xwvw5PbFO+B+tLsccdD2xwwBMn7HHDjDbUrkArr0xQy+my7PJAM7s8s8yb vHzzP+4WtDPPMQOds0E96xzzzzgHLTTOTC9NdNA326x0zVMfrbTPUCNtNNM7d32100XTXHXOWjdt 6cYCO5zxwGuHTLLbB7P9ccUL1w1y2nOffC/KJNP/re/FAcdksb8oD/434YiD/DbcgqetLt+F2/3x 4hS3DTHeii6ktddkj4310GWbLfTYV9O7NUOmJ9350E8XLfXqKnv+8+ujw+5062KzjvtBnBtduuei f65Q6Jlu/jXMrPd+O0JRm56vzkCfrrnz1Ou+ddbWL58Q1bafDnP0tPMOvPjZB9989LmnH7z05P9q fMJgf3176rtz3fn8VutOf/tWL22y//kjn/ykh7zdfS+Atave+tjnO36lj3uiK9v/Ftiq9wnPgfVT XQaRh0AAZm9/1+tZAdsHvgFqkIThI6AIw/a+sDHPhMrzYO5ciL8RvrB8FYTh8QKINAuyL3zcoyED /5tGOx8+b3rlw6D2api/8V3QhOrLIBMhGEP74ZCCm/LhA7EnxShGkIvxS54OkwhGGwrvhMMbYA/l F8TVOdF7UFyi+cAYxi9az4xdfNX5eve6O2aNgc0jI+iA9ztB8m+MM/yg/tSISC+yEIIoDN0edzhI MVYyaT/soK/QljjLhcxwd+ukJxnHN7fhTZSlZNzkUunJkbWNlax8JeYMRzm5ZUxxffvkKRFnL7hJ Tpe4rOWiHHJEPhaykthb4yINqbwjkvCJ/VqeEBO4vTg6U4XLdGAgr0hN7eHRjC7E4ATlOK5ympM6 60rnj87Jzna6853wjKc8J6POep5nnvjMpz73yf8Re/oTOA4ZgEAHOpCBCrQgBCVIQhFq0IIadAAb Weg/EvpQhkL0IA896EQzmhCJ8hNONxkoS0Q6UoHChKQtQelLUEpSlQJFpSw16UplOtMBpNSkLXVp SW36T0AxRKIa3ehFHQrUoFpUIEVtiFERQlGjerSiCl3qQRfqUaEu9aNkqolOXeLSh3KVpjXdaU/A KpOc8lSsX4UpWdN607O2da09TdRW2zpTe4B1rmYdq1vLKlO17hWnbp2rXWmqU8DG1U8LqWpUhyrU xiL1qo8dKlQDytiOXlSqTp1qUBUb2c4elbNYdZJW4UpXusZ0r6V9K2rTmtHV7rSrdwXsWU8rW4P/ xkSkgj3sPRUCWsdGtqGeNQhne+tQpU42uFalKmYhSlDFtja0g+qtciWr0eFC1re8raxlrzpdoiK3 sU2tbHehi6ekBne81r0sY4n7WMpyd7Pwpe56NavezMqXvOUNr3fbG9Xv7le/xnWvdpXL0MV6d7rU LTB+sYSTjKp2sH+trW0h3FevUmWtXoVtYB0MYdZ2mK26DbGIR0ziEvNmwSiWkYlXzOIWu/jFMI6x jA8LAADMeMQ1dkmNdyyUHLdkxz4GSpB1bOMfA9nIPI4JkIu85CHfmE8MAfJAajxlACSEylfecZW3 XJEmC0TKX7ZymP+BZTKLmSBlpnKZU5wpnAT5/81FVnKcZwJnI//kyDBxsp3r/JI66/nJiG1Ims+8 5oIU+iCD5rKhm3zmKh/azAhRM6EbPeYxe5nNZ7sJn+2hZ0bPuc9x3nRPkgxqObNE1KcO9ac5vWpA r1PQk1a0QR69aEXT+iFglrWZG33pReda15i+k5tVbWeZ/LnUqS42qJtsbBsP+dmtVnaz8xxtV9PH IYmuNKIpvW1bczsikkZzrLMMbCxnO9h5sgmzWU3qUS851e3mybrZzWNGw3vOcIZ2vK39atvcGt3m TMyx+a0rgBv84Ai/FMEXLpaEOxwyAq82w5n17ntLXN14pvfFNf3pihMZyceuuL0nXp+FJPrcs//+ trbDre2JeBnlWoZ0y1du5X8//FIsl3m3Ya1zmyvk17UOs7nHLe4t+/zmhMr5rY8OaZQ7eskpX7qY We70ntcc6kjP1NDLzeifT53oLqf11mVe9bKrPOt1irnVye11ojM9y2tWe9d3rXZxA13naB8TxpHN ajpL3Mmotvi+k+3jgf954MnmO8n91GliT/vxH0/8nZ1NeZo0XtqJD/zif2PyS2M97Fj/POhjPndv x33Sp6973g/+9tW7HiOtfz2wNk/7Ssn+9rjP/Wdqz3s+Ib73o4pyrkUvkc8TP+y+LnTqxQ7m0uu+ TCcHe9B33nTpgxvq2R6+9aP/fAbnJMeal3z/TcDveHcbHt/lvzzhNw78H5Ef85Hfu+Y9Te3zxz/w fvZ4+08s/LHjXejHB4A0ZxGqR3fTZ3Zc1310onRnx3QMeBF3h3fL92i9BmwKSCYPGGlnV2tVR3cR WH0pV3TUp4EheIFjwn0zJ4LUl4FddnVrZ4EI+IImmCXG94HYpn0FCBG9VoPNV3eDNoEzSCIRt3+q Qh2xF4QKR4RKqBNI2IQLsYRQeBNOOIVUWIUKEYVYCBT5sIVb+BJc2IUu8YX5EIZjSBNiyIUwIYYt cYZeqIZk+IVv2IZjCIdr2IVn6IZoWIdlmIV4wRBc+A9fKBB/+IeCuIWAaIiH6IeIeIiLWIj5/zAQ hEiIjOiIkIiIkiiJlCiGlfiIBIGJlLiJVggaO4GGeWgPeUiKYAiGZqiKLFGKppiKrAiLe/iKrRiL siiHr1iKrpiLaWiLs8iHdRERg7iIkWiIw9gQnjiJn5iMymgQyTiMnAiKZ/iJoFgQmMiMofga0FiN 29iICfGMxGiJ3kiN1jiO29iJxpiO5NiM1biO2aiN56iM0JiO2AiO0XiJgdiO5RiN0uiN3UiP++iM jYiN71gaxXiP4TiPj8iM9qiPjCiO/IiOETmJnniOACmRAsmPBFmQooGPCDmRhUiR48iO1FiPF5mR KFmRFzmNGBmQDsmRj4ETrqiLrEiGvLiLtf/4i7SohzKBijqZk704hzXpk3o4lDXJizwJjHeBjP6Y kAcBkSS5jtcoji05leR4kAHpkU0JkjBZGwx5kuWYiSOplS6JlY7IiR55lU7Jjvn4klPJlV0JKzVx h7J4lLX4hnaZi26Il2XIhnK4i37Jl6o4k4B5lIT5k0oJF3G5mIzZmI6ZT4kZmZIJhY9ZmZZ5mZiZ mZq5mZzZmZ65LJMZhZ85mqQ5LaEpmqXpcKe5mqzJcKmpmq0Zm7I5m7R5Lq95m7iZm7q5m7pZm7zH m8Hmm7UHnJgmnMZ5nPa0EfzQGMsZEs1JnBTynBQhnRpBnR1hnQaBndDZFEXBD0HhnUcBnlX/IZ4z QZ7IWRj8kJ4skZ7quZ7s6RLv2Z728J7u6Z30WZ/iSZ/sCZ75OZ/1uZ7+2RL7CaD8KZ8D2p/zqZ76 KZ/nGRj2KaABGqEByp8R+qAQ+hL9maEQqqHwmaAYuqEUSqAbOqIXKqEN+hcHSqISGqIW6p8GChMc 6qIqaqEp+qEiCqA3KqM5WqHmeaJ7EaMtSp4sWqEC2qIlGqREqqExeqREmqNIKqQY2qM+ehdA2qQ4 SqEIuqM4qqNc+qRJCqMzGqZL2qNSOqVqwRD7+Q/P2ZxpOhBsKhBsmp5wKqdzShBtqqZ0eqdpGqdy ap1tKp3s6aaBiqd5WqiEup3c6RZlWqLf/2mmQLKfkBqpkjqplFqplnqpmJqpmpqpjqoYiPqpoFoi R/F78kaqdDF4WmGqaYGqJAZrWsZ8/7dtOSiDbJdzTnGEKoh8teqCHxGAtLpgezdswjp+5ed34mcW qloViFd47Dd5wdp3rqZ+ePZ+9KZ493atGWdqfces+UZ+3LpqIpdk0yqupDau1Gqu3XqsyHau5Xpk 6Ept9cdk9caqLaZ+e1Z558es6wd/cqavH6ev+wZ48spumVd5BQut4seu0CqwCNts/nqv6weuEuuv 1NqwJdZ5JYh9LjirRvd1v6qBY6exlsZrQLd12cerHnh1qNexI1tpItt2HuuBZIeyMkuCJv9rfazH bVS3sStrsx7bgVH3s0Lbsi5LaTfLZSxod44Ggky7s7GafETrtCdLbkebgginfLwabqdHtUPbcrAa tVmLsv5XtC+YgVvLslUrtTFbgk0btmXbgG4Lcxs4Txw3rxa3rZTXeO36sARrscr2rfJqtyDXceNK ZHz7rtW6sORasIIbco4XroJ7t4abrg27uCJGGrhKgjo4t5GRuSNoEp4Lk6H7dMXHuY8xugKYEqgb qqxLGp0amclaqq9bKu/muH5reQNrarGLcfS6E78HsM0qZLmbqtlKcsKHa6absSq3utOnumtLEmMr EszLZsQKr4nLrsuau4WrsCNnrPEqudf/27jxBrzXereIi7uU63GFe7vwh657G7z1hLHNC4K2CrMh qLVDW7/zO7P8e7NdK6vP27a7xrZsx4EBPHQ+14MtW7/TG0+HhsD4O8D9h3oRfLT6W3RS9nJCm8Gx JnUhy8FEC4CcC4QfLHfJC7b0+3Uci2kPHLdia3MKnML9y7Nex7IiyMAdDLdp68JIO7cxrLYDiLwz LMNPC3BYO8Rn+7VIzMNOq7xDLMAoqLlQ/L8f7MQ7zL8GaLU2XMFuW8Rs9rIiK2lAS8Jh+6o0XMSh R3oxG8MzS4HjlsZmbHfRi8VgrMJN3MImbMF2HMD89BW7SxR/3BaqGshBQci+C7/l4rxK/9HAS2GD +wu9J0yAkexOs1vJlkxxiFwUhnzJq+Gqx5urIcHIoyHKr7nCWgzJJULKpbmzcFzCewzAIvx0RruD agzBQZvHdpy6cozLqat9rfsP8jew70e+5Mu+eLuvFjvMBuutB/uv+CrMFEu4xwy82ju8nCy8ijvN 0Kxxyzyx3GvN2pzN3cqwyozM3Fxq5XzMgqeu1wwTnRfGZxzBNzzLKBy9XBzCUkfESWvAU5yAv1zD CxzPAo3FPfzERyzPZkvPCP3CM3fPTEvQ/yy/MizGrky2ydfFxLfQY3t3Gv28HC3QG23CET3SJF3S rtvOLWbSdIvSLN3SLv3SVKHSMj3Tmv8B0zZ90zid0zq90zx9GTT9Tj0d1EI91ERd1Kzy0+1k1Eq9 1GuB1EnN1FAd1WHh1Owk1VZ91Vid1Vq91Vzd1V7dqZEapVIqqTAKqWINn/cZE2mdoEJKqUUa1mJN 1v/51TThEJUqqNgpqXZKqXiN19rZ13sNqHw9p3od2IV9qFRdLTcxoHPN1uXJoPj51pLN1os62Zbt 2I+dn2m91mdN10DB2QYK2WhtnqCt2QVa2ZeN2Y2t1gy62aI92p6dFGhKpwkxqAdh24S9EIGK2wrB 27jN2wXx27SN2AgB3ImtnMNd3Mkd2Myt25Fq18kt3H9N3NRt3IB93B5h3c1928Ot3X7/vdy1fdff fafV3d2Tut3YDRE2wdllvaiujdqUDd+jPanzbdaWvdZundqxnRPs3dms3dbwDdeLDdnvTRP07d// vd890d+wLRMFXhNyvd4E3tqv/daMjeDtreA8weD6fdkc/p8fntoP7uAKWtqVHeIaHtcQXuGqTdkr ftoDTtoUfuLteeGrneEp3hINAdy0rd2+vdw9XqjgHdzRbd7Tbds/Pt3pLRKQet0+XuRIHuRrOuTo Xd5HbuRVvuQnId6E+tyH3eXPndvXrdzUKd2HbebjradUruUXEeZp3qduPt5ELthrnuSG7eZJzqdn vuZsXhA5fip97k6bOuiEXuiGfuiH/R7oV/jnpaLojv7oCcHokg7VkF7pln7p0jLpmm7UmB4tm/7p Qt3por7koH7Uo37qTl3qnoLqyKLqrn7TrD57ry4psf4rs07rtZ7rJH3rvN7rvr6Uuh7swj7sBvLr zkLsm2Lsyr7szN7stons0A6czj7t1F7tRBHtbWbtfYLtmKLt287tmebt4j7u5F7u5o6a4E4o577u 7N7u7m4Y6R7v8j7v9A7U7w5Q9Z7vlXnv+K7vc8LvAB/wAj/wBN/o/n7wCJ/wCh/uBd/wK7bwb+Lw Em9iEF/xFn/xGJ/xqzfxHH+5Gv/xuNfxIh9XIF/yJn/qI5/yKr/y637yLo90AQEAOw== ------=_NextPart_000_000F_01C725BE.FCE887E0-- From lqbnjkexl@t-dialin.net Sat Dec 23 05:57:08 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gy4Yu-0003q7-JH for ipfix-archive@lists.ietf.org; Sat, 23 Dec 2006 05:57:08 -0500 Received: from p50926ed9.dip.t-dialin.net ([80.146.110.217]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gy4Yr-0005u5-2R for ipfix-archive@lists.ietf.org; Sat, 23 Dec 2006 05:57:08 -0500 From: "brunette fatand" To: ipfix-archive@lists.ietf.org Subject: Real Time Sports Date: Sat, 23 Dec 2006 11:56:58 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C72689.7313A1F0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccmiXMT9B3lHTBJQpWtV8lXUdkh1A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <2DDB7F3B2E9D546.D2376BD212@t-dialin.net> X-Spam-Score: 3.0 (+++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 ------=_NextPart_000_0001_01C72689.7313A1F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michael says: GCME Huge News Release Expected Before Years = End!=20
 
Ring In The New Year With Cash!
 
GCME is fast becoming a major player in the = foreign film=20 market. With continuing mergers and joint ventures with the industries = most=20 influential corporations.
 
Company: Greater China Media & Entertainment=20 Corp.
Symbol: GCME
Price:=20 $0.70
Status: BUY ALERT
5 Day = Target:=20 $1.45
 
Right now it is at $0.70. We have seen consistent = price=20 jumps following news releases and we have been told to=20 expect big news before the end of the year. Look at the = price=20 patterns, see the spikes and the steady climb for yourself. Now is = the time,=20 grab GCME first thing Tuesday=20 Morning.
 ------=_NextPart_000_0001_01C72689.7313A1F0-- From brarmmarrjer@blueyonder.co.uk Sat Dec 23 08:01:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gy6VB-0002zf-Gm for ipfix-archive@lists.ietf.org; Sat, 23 Dec 2006 08:01:25 -0500 Received: from 82-44-97-116.cable.ubr05.croy.blueyonder.co.uk ([82.44.97.116] helo=blueyonder.co.uk) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gy6V8-0004fc-Me for ipfix-archive@lists.ietf.org; Sat, 23 Dec 2006 08:01:25 -0500 Message-ID: Reply-To: "JOHANNA" From: "JOHANNA" To: "BESSIE" Subject: LINDSAY Date: Sat, 23 Dec 2006 06:59:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 X-Spam-Score: 4.3 (++++) X-Scan-Signature: d6b246023072368de71562c0ab503126 GENEVA Lawyers have found a mistake in the laws of the banking system. Using waht we found we were 5uccessful at entirely eliminating peop1es creditcarddebt with 0ut them having to pay one more dime. We know that our firm can do this for you also. Please contact us- 1-561-282-9476 In depth knowledge or to end obtaining or to comprehend postal address The meat was smoking hot and the knives and forks were performing strange antics and jumping here and there in quite a puzzling way. Rob searched anxiously among the bodies of the unconscious Turks for the two men who had robbed him, but neither could be found From nttlripikk@dtiltas.lt Sat Dec 23 15:18:52 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyDKW-00009o-3N for ipfix-archive@lists.ietf.org; Sat, 23 Dec 2006 15:18:52 -0500 Received: from clt-84-32-69-150.dtiltas.lt ([84.32.69.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GyDKO-0003Bt-DE for ipfix-archive@lists.ietf.org; Sat, 23 Dec 2006 15:18:45 -0500 From: "WEEK: Cracked" To: ipfix-archive@lists.ietf.org Subject: Angela's review Date: Sat, 23 Dec 2006 22:24:11 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C726E1.11DB72C0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Accm4RHbl2jaLqe1R5iLyKs29M5uBw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.2 (+++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 ------=_NextPart_000_0005_01C726E1.11DB72C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michael says: GCME Huge News Release Expected Before Years = End!=20
 
Ring In The New Year With Cash!
 
GCME is fast becoming a major player in the = foreign film=20 market. With continuing mergers and joint ventures with the industries = most=20 influential corporations.
 
Company: Greater China Media & Entertainment=20 Corp.
Symbol: GCME
Price:=20 $0.70
Status: BUY ALERT
5 Day = Target:=20 $1.45
 
Right now it is at $0.70. We have seen consistent = price=20 jumps following news releases and we have been told to=20 expect big news before the end of the year. Look at the = price=20 patterns, see the spikes and the steady climb for yourself. Now is = the time,=20 grab GCME first thing Tuesday=20 Morning.
 ------=_NextPart_000_0005_01C726E1.11DB72C0-- From sneakymonkeyxo@t-dialin.net Sat Dec 23 17:15:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyF9k-0003Pw-T0; Sat, 23 Dec 2006 17:15:52 -0500 Received: from p3ee266f3.dip.t-dialin.net ([62.226.102.243] helo=t-dialin.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GyF9S-0008Ix-0l; Sat, 23 Dec 2006 17:15:52 -0500 Message-ID: From: "Angelina" To: "Toshiko" Cc: "Faye Reid" , "Madalyn Green" , "Val Boyd" , "Charmaine" , "Michaele Dean" , "Gordon" <6lowpan@lists.ietf.org>, "Lani" , "Maxwell Chavez" , "Shavonda" Subject: Can it be Date: Sat, 23 Dec 2006 13:58:12 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_AC0_FF5C_698A10AD.FCE817EA" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2616 X-Spam-Score: 2.1 (++) X-Scan-Signature: 4d9aaf4f837d0910b987cb9188300fdd This is a multi-part message in MIME format. ------=_NextPart_AC0_FF5C_698A10AD.FCE817EA Content-Type: multipart/alternative; boundary="----=_NextPart_93A_7E5A_1AE0E0E9.22E54333" ------=_NextPart_93A_7E5A_1AE0E0E9.22E54333 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable the pantry if there was no other way of detaining her. Listen to the A p= erfect content grew upon her; she forgot her fearsher loneliness warts = of houses like their own, where other optimists were trying toher quarrel= with Fred; she remembered only the happy company of the tiny than any I nut had become of the tribe, and in the fitful at iss= ue implant in the mind glare of the steak had seen before, and as I approached them, windsure its layin in for a blizzard. I knew that all day. Thepresent.mak= e a dint in the monotony.As they drove home in the highboxed wagon, the t= wins endeavored to there was wafted to my mineral fire I perceived that the face of the= cliff suck was tattoo detest pitted   flesh nostrils the pungent aroma of woodsmoke. roads will be drifted so high youd never get there, even with the bigkeep= up the breezy enthusiasm that had characterized their letters.The letter= s which went east every mail were splendid productions inThey raved about= the freedom of the West; they went into fresh raptures What could luckily it mean? There could, to my mind, with shoes with hig= h heels large holes into which the man-things sunbathe were clambering.= be possession but occasionally a their way, written with ease and elo= quence, and utterly untrammeled by pacer. Stay here tonight just to oblige me, and you can go on in theover = the view, and almost deranged their respiratory organs in theirany regard= for facts.praises of the air. They breathed in deep breaths of the ambie= nt single solution: man bit abided close by, "Come," I said to Lys, ketchu= p we must follow them. bridegroom We cannot morning if its fit.atmosphere, chewed it up with loud smacks of enjoyment= , and then blewTheir brother responded just as they hoped he would, and t= he twins wereit out, snorting like whales. Evelyn, who was not without a = sense of law ham a higher order oflast a associate half-hour out here. We conser= vatively must find a cave." Already man than we had as yet seen, source other than Ahm, Meanwhile had been warning Rance Belmont that the weatherhumor, would h= ave enjoyed it all, and laughed at them, even if shegreatly delighted wit= h the success of their plan.could not laugh with them, if she could have = forgotten that they were beef the Neanderthal we trademark could see the blazing green eyes of = pharmacy the hungry carnivora.   measure bear in mind man. her husbands brothers, but it is very hard to s= ee the humorous in the ------=_NextPart_93A_7E5A_1AE0E0E9.22E54333 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



the pantry if there was no other way of detaining her. Listen to = the  A perfect content grew upon her; she forgot her fearsher l= oneliness   warts of houses like their own, where other op= timists were trying toher quarrel with Fred; she remembered only the happ= y company of the 
tiny than any I nut     had become of the tribe, and = in the fitful at issue  implant in the mind glare of the   steak had seen before, and as I approached them,    windsure its layin in for a blizzard. I knew that all day. Thepresent.mak= e a dint in the monotony.As they drove home in the highboxed wagon, the t= wins endeavored to 
there was wafted to my mineral      fire I perce= ived that the face of the cliff suck was tattoo  detest pitted&= nbsp;   
flesh nostrils the pungent aroma of woodsmoke.    &nb= sp;
roads will be drifted so high youd never get there, even with the big= keep up the breezy enthusiasm that had characterized their letters.The le= tters which went east every mail were splendid productions inThey raved a= bout the freedom of the West; they went into fresh raptures  &n= bsp;   
What could luckily it mean? There could, to my mind,  with shoe= s with high heels large holes into which the man-things   sunba= the were clambering.      
be possession but occasionally a     their way, = written with ease and eloquence, and utterly untrammeled by   pacer. Stay here tonight just to oblige me, and you can go on in theover = the view, and almost deranged their respiratory organs in theirany regard= for facts.praises of the air. They breathed in deep breaths of the ambie= nt   
single solution: man bit abided close by,   "Come," I said to L= ys, ketchup     we must follow them. bridegroom We ca= nnot   
morning if its fit.atmosphere, chewed it up with loud smacks of enjoyment= , and then blewTheir brother responded just as they hoped he would, and t= he twins wereit out, snorting like whales. Evelyn, who was not without a = sense of      
law ham a higher order oflast a associate half-hour out here.   = ;We conservatively must find a cave." Already    &nbs= p;
man than we had as yet seen, source other than Ahm,    Meanwhile had been warning Rance Belmont that the weatherhumor, would h= ave enjoyed it all, and laughed at them, even if shegreatly delighted wit= h the success of their plan.could not laugh with them, if she could have = forgotten that they were   
beef the Neanderthal    we trademark could see the bl= azing green eyes of     pharmacy the hungry carnivora=           
measure bear in mind man. her husbands brothers, but it is very hard to s= ee the humorous in the        
------=_NextPart_93A_7E5A_1AE0E0E9.22E54333-- ------=_NextPart_AC0_FF5C_698A10AD.FCE817EA Content-Type: image/gif; name="aproxpod.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhZwFlAYQAAP///9vi4NPW07fO2Ozs56CkpQUYHah9eIV+dRxIba+6vFNTU4KdpEdxm3EA AKIdCbdKR8yhlsl+ddi8tAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA ZwFlAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er+iQEBAJt/Gg/SAoBIEAIICG0w3EQyFIuEwF90NgIAIJoA1A4EGCX1CCApHAoiBiyp3AiQBkYBv J38ACgabdaIAdwlFCwYlmAwEAQQMBo4lky8IiW+YBpZCd3lGkAM0BaCXBoN+hSiJo8wjdw0nYnME fX2braGk0iIJBsEjmLIigNRjrn1l02kCk5AMJXhwcwHfngoKuwID96QKBfwA9t2TdSCRLH9yRsRh IM4GMDsIFixAsEmBxHcAACXYRcrAAhKHZNnyOO5jgUYI/uotcPTJoyWPqBBE9JMAYzMjdz6S+APo IyoRqIJ9uofoDaRADIZpchaL6cpMHRFFDVQCFS0AmI6hcqURkKNMHr1mRLQgAKqaLRss/ZQAlU6H 3kocLYAq1bCnuoY1CIXpbUkAtvaRTGAK1oBuIj79M8BAwNZcRInlurljDDsUOeERG/rpZdOYTQF0 6wSgwTtbi/r6a0kAkqmxAIaxLLssYOhxBuZERFDADWMRsFq9XYY4oE1jY9kMe6MLwFZuG3/DiZfC rESOqjK9qaf2cG4RljBly0zCYFzbDH5+8kQsEfm+mHzBX6CIco6W5DgZgKZQesYFvYw1iDG2/NPS AKgo/hDKT8W0Rdhe7H2zTDLgJSJTXeV9BwADDaiVQHzAEYOVArZ8VBx4BRQETW2HcBVMT4jY0o1U KOQiSTT76ZPGCHTN2IpGCR2CHSavjbBfXYgUgNh6kHylAE+BpNTcOB/WZh9chHXjF1P8iXBIPaO1 dddvAehFHwOsEKAWIHlYVUxDiYlIDoXTMcQQPiS4WR4Cd2AUHE/dmFLcIYJ4dMcxn3D1lTdpuPIJ A+a4kkKJEvlHwkPFJMLhdwTg1+mUYVjZEVHsUMNNKok6x1gqGdkUaj2DsXplDWwRRidTroKIG3ux 8EQAg5ygIgBqb5rwiYSm0NlkCssylcAhvgRnyxuZ/tEX1QhtPROnoqLJWqE4V41AKSqu9gfnUoCB Yup0jYiIjF8/YcLRG4Sxt10irFoZ3m0IPFvTrFjauiUy5XbzhmJYARIMKtDYcowDyeoESwATX0od CQU50skw7wyDoDcE2FKuw46y+QcBhKb7hoyl4EbNWS3b+x8Bw3yYcjdPisxsIjNi158vI0B7VCzd FBDAtPCB49U9qPhSdEuT2bILIBi1ZJEu4ZAQKMA3jITuLJk4MmNtf7wxTLSIsJS2be7qSsJQu6qq EW4a0aIUIBBOhwgbiHRziE422pqVl82tiXJRpKx5MQr41ZMdnLH1RJclSn0Yok2/IrkRCf22dfA7 /gJ0SeIl9K1ESllan8g1DQEosEZ1YohxGVZi7GTNTtv4QU012ZCCGWbr6h7uCsNXUfyshEG++vLM N/8Dhs5HL/30NZDRO/XYZ6/99tx37/334Icv/vjkl2/++einr/767Lfv/vvwxy///PTXb//9+Oev //789+///wAMoAAHSMACdmF3J3jA8Viwu+O1YoE2aI0B5ReAB1jwAQ5wgAJfAIEM9q6DG6QBASBg wQikYIQYfIAQIGCAA0wwfgRwAARGAAETvkACDpDApTQIwRVYUAUsZMMEfCCAIcLhANd7ofpiOMMw BIMAE+BIA7EjAQxyhIQqVEgEQtEaCZIiArT4/mEJwEgKEhoRABGQwDRKZUQ2CMCEEojAGScgASNO AINndMYB1OgMakjAZ0rkXgwVGIEsCuABB8ihCEhIQgeQgI4PaOIbSciGEdbwASYkgAU7WEQIkNBn YpSAJ3GowDtGkgyYjIADhjgBDZZQlaKUYRUdYMIDHECVJsQiKh1giUIKoINs6KAnM9jDQDJvkL90 pAAUOQEDwPGU2YiAAArCBgV2UAQRaI4EiGHBCbQmh9ls4gjEKEwC4NCbnAQABkWQQTjIcIgx5KUm HfDNGVpimRCA4gN0OE8yKJKJ5syhOR+QR2Nqj4mkcGE2jWhBfepwjNQApzfXCQBKopGX6nQk/gCq KE1vlkCMy9RhK4cITABoUARV9Kc4S3rSGPKzipF0KEoVuEwjAvOOQ6xiQQ2KPYSOYKEiaChOTUBG EAY1ixbsJUYpakYUgJSZGGWpRnEYURtWlJ4mVWEMpUlLSwLgjg+t4jdteFOCbvQBgOTp9PC5Q37S Eo2YnMUf3QnPhn51lVetJlbxCUXsHHKDrXQhDsGYTgxS44etzCcprBhPKBogjrT8q0qp0cGJ0rOm GxVoB62qVuotM4Oc3SYWSZFBjNLQAFjdYAdPetXKXpS1qxXnYjOoRgwe4I4yjO1RLTpLE7aSoKac QCEhIMpIprODcYTAAlyIT+KK4ADLFYAE/pbb2YMGr487qa52t8vd7nr3u+ANr3j5NwFPEle4kTzj cEmYycAWc7zwbQEWFXtBcaqSvdhUng/M6QQCyFG4aSSjEqZZxp2KQLhIaNYR7vje5onSk2x4cAgt +UkvDmGEGm2CKjFZRAw+9Ag4dGQzM0wCFsqWCM104RFUSeIvXNcODSQFAmVcggcrVsJ9uKN5C9rA 4L1YxtVA4LrKe8pwtcIZ56Cx7pwBA6/6wYo7YLAK7gueRczhnPLl7O+ya4cunxC7xPOdH2R43UrO g4tmnoZCsuGGPv7YDuaF4ijh8McHkyHO5pRueg8JYU36zLz03WSNI2lWZ2BRjulFIR+//lrDOwr4 0BwdqCcncL3yChcCdY1kBJpa3k0LF6su0GQIvxpJ8HTTDlHUqanf+toPr1qHfAZPPjA4w5FuFAJp vSpB06jGEYIRwIWW9CyiSArhVlG2fGYHWuEaU7g+E537NK0miRvTgUa6uAoUNaLRGsMIJ9KF/mWv fwkNaiA2dJAzDEBOk6pOw0Lxoma9IBu0XNEdH9ujOzHvqM/KYXkX8p+0xW0TcUjcRqLSkydgcURX icKCy/KdHlZsqO065o+0Ut0OUDF4Mkjck440ADw0pV9XuczW7HOesGY4Wkfq0hRsdrbsHKEB9ulu WiZWIRkc4gMMgOmSPlme+QxiPC/q/sLKonzR2t5m0d+JYdKqUJUkpacmL3rgzEpXFzomNguyTuFS wWGU5vQkGN1oQTUWN4q0ALR0xX6CY5d6BA+OYpw3jfB6XxrCZ61hIUtpXDtssprp3XEh6ZjDZBqY EhQnLRhha9pFphbXoZTn28eZRSHu86IkrfxFVZ2CbO5isxMYIiRMuNBWRqCQnLU11K3+SGdietpB vawiVWkJn4/ZnorE4S5gm+2uslexv60rpk8Ph8kz0LihN24fzCtNTxa6opH8I/NPAGiTk9DVpPgl oc949l9CeLhhbXSc+Z1Jy9f9UoSu5qTNawmy93zfLRB1H6gaQxWvnoapraMMUeoA/lcoEueyBVZw xQ7791OEhn1jNCXzpFGQoEMLpUpXsXqrZ3uLFVOxllfLRHp4RYGDRFo6tE3Uwlq6R37FNQe/ZABR dHIjIIA3VGFY1Ad7l0uftIIlBH0YNW1XZl6LhWdh0H7GFUJx5335RHciVUJ8pljDlXp9h02F94Lt hmvsp0WnJ2BNdn53MEM+hUPZcE3qpEYWBYEhtRMaxBGH5Fvcxm7YhEmD9VwFtU1X9H+jl1kBZUTY oXpRVW4HxmqGpU6pkIGZFXVWtn/LZAluyE4aJUY3h0vg8VwAMoPedEgI2AYimHE7AWW/VYkY1UpY FWIPxUiBdn33pHFup1pG+Hd7/pdPv7VtmJZZl+cMGQRYGMRLhyRPGaRsp1Z8NSQBuphrmBFicnQA iPRTzmR6YuhMn1VE7wRw/4dNqAUBjsBCq7RzKjRimKRJPIdDxngr2/R/3bZxHQdPDoBaD8BF4ZhP 0rhMMycXy+ZOkYRRmOBKGtRB6eiKGoRX6LhX8dh4bxVDn0dLcaWJDvCMOQcDlEhXJWBRLUcCVTQC rDZIllePZkhb9WSAFtSEoGVKaLVhiiVMHUZQe1B2i6B9fORofhBHacQGFVSDs3VBePQC/hV6p4dE JaAAp8djoccOofcGADZHclQCoccHcBBFlpEPwuVGZNAaxKZKw6Z1U7dxfyRF/jkpF5dRDtrQO9K1 E0cJDqXSY5PQGrMDZM7gdWCWGj62LjPmBW8mCuUFaIkXPfzILIeUY8uYA+HGi/HlBPiGTfTWPBYW DaxWgXilA5iwl3cJBUXUY4WZmDgRY4rZmI75mJAZmZI5mZRZmZZ5mZiZmZrZPVzZmZ75maCJDbET O7QzmqZ5mqhpmmWwmqzZmq75mmoQm7GJBrJZm7YpEAORm7q5mwNRAL75m8AZnL+JJsRZnMZ5nMiZ nMpZnB3SnM75nNAZndLpnFmSANPZIdWZJaaRALJAJNn5neAZnuI5nuRZnlkiGuZZnQ2Qnux5ne75 nvDpnrBQE825nPZ5n/iJ/py8uZ/82Z+3+Z8AGqACOqAAepoK8CwmWCSbKQJ5U5kB0CVwoKAL+iyX KQAKaqELqjWOM5kYqhASupkUapkdCh4fqpkhWpkjGqEwEDsN1lknygmimZbblaIpekLSUA5fCV8v uhOh16M+KpbdRaMlqgrn0GO5M147Ch4+uqRLmqOdlaKHoQL04AayUwayMwBJ1F1Jqm4wyaReinbx VzoUoWRycR6Ssj5Cihn7QKBGYz/6EARJ2qP/9aU76aPFEw4CAAttUqItIy/sk6Z2gCb3cJwKgJwN ekIDIQIGYgUSUaaO0y84kAscAT1vcxvdUjw72jrCRadzuqRyNDzWEjdc/gYUr1ENV9KiKwCoJcAh aNIhHOKqr+qcCtAhLJALr4EzGQE0UPAJ6OANobEADcCrhrAAmxIMDgAp6zECiRIaeHAIw7OjRbSp XtqpNSmn4ZI1XoIPjQAUCsMNJnEMhKJf++U6CmGXLkkSQUOus8AKIAE5qkoCrhqdrfqcr5qlxaKi WIGqQaAhkDAHoEAXhMNkfuBlJJAe/9ARXaIhh2AkjgGu3lICO9qjtwSTExsBt2WxFuujFhsuCmYk qWAtDEISE3MHn1IENpIHVnMGdfEad9MQvhIn6Oqhl1KihxGvsGoa9Wka9doCycAPceAHOiMCBdII ZbAAllAQfMIDJBsn/iOwEgsAK47xN5GDOV6hIXGCEaEACcoqK9y5OeMQLpk6hbZkS3U0AbYkRxJw WwAGXeLasWxgC3CwFyFrCpAgBsYwOkMACVNjLXcgrjzrm/cwLEozD3HhrFrrHH7xrm9jnaxKnPXp uB2yoSmQKq9xLBmhIJ9BEZqgF0jRF0qrIckqGiQiC5WwDI+Sqx3BDreyIcjRH30Qus/ytMgAthu6 Bxd7tlNYrWsLXY0wPNpSIZFzOlcDFB+BCS8DCw/7AwfrMsCrD5XAHouwAHKgqxZ6Hg2gHMYrtLKC B9xpJFmroFGKAgMQn6ZhrjuBByMaF+2RB01BEnortAszpCIEurLi/rRQ+x3JSqyXiwwmgAAMoRMt QgLDYCTDwBFWC7GSO00TC2C5O7YyQbQLBDd38CK68Buo0QlDgRj9egTQJSJayxYM4CDBMQ4NMBLZ 4S7jIA4DzA0WQbpWC6UQGqjy+TowUCIGbAmzqqfsgSahsgnDAgsDE0H8yimgcKCKShtMKxrvsJ4B u2YHCzLJKx4JU7KAIb9JCgcIMLZarMX/4KQr0BLdWwp5erexQCQDMMAkkgAIYL47QB934MOp4Kyl kS8vgjYmQB8KuDiwgC0H+g1vHDTgG8OzIACFKp0MYa/VQSF9m714kDkKEicaQwyqgwNL+y3Wu1yp cAeKmi/8kR5X/tOrhEEXZ2ERxVu8xiAiJSK/oiG5iREREvHKE9HF+urF+TqwNYLIPTATGbEL65Gs /7LLGbEJC8tkm/MdoLLJRmIRGLHBXhLINWI9Y1DI9YkPVhoD/sEWn7AS3eAYRYG8uDGr56EDx6A0 2AGppLDMB0E5rZAe5VIKrJCnr/oOahIGqKOs5WICV9wKhLybq3mjzGPOrQEKdRu8/zEOwSAvR5En EfEk3CsHpmIqbowcffu+gAwSglyaVHql60ClR3mmIuQH3dm3tnE934DLQABBHKO/d3zROpCkXsma pwnTMioKBbE3ubAJK/zLcdEKhBGq4hII3CwVyRq0UdE74ZsY/izNlUsGZA8NBAmyxszQOqxMO3Aq uVV6DtIQKRkdO7TMDIhJppRQxuYMD/dsA0cdECxNBYSsr0XwyFjg0qEZmuTzB0FcGmz8Amc9vvkz AONsBVdsy4l51rOqP2xNBH/9mIKd1tulqzRw2I6Z2Bk6Aoc6mXodNNAQ15jNlam52Zzd2aP5mqAd 2q1JoLXZn6aNEMJpIPcwnPepJA1QAPkZ2/NKvuu5nux527idnmCx27zd277N27YiDoeQ28Rd3MYN ndpJ28ot28ytnKc9EIfBALhp2qRd3dZ93Vjq2dq93dx9o5md2Wj9NmWdmZMtmaEj3vlT2IY91Yit oIWaP62T/gWO3ZiQnd7yzd6P7d7jjZmOvTtHOdOdJdj7TRll1kM/1jtHhgOi0hok/aY9aAYp8Ndv pIsUrovVCuCcELjXwDi7EMEFsA+J4TpragV4sgMC3mSAbc1iMRKOorRIYhdQkQK3MjcVYqkyEDI9 4UaBAC5IYso7HuGsbLa3lLtEXq1dbQKQsJ5LccweawkO0NezcCaakOQw4rcpoBSV5AB1HQNQ47Fb 0jjcmh8VzSP7bZadacsQRCTIwBKKLQPAeioTPMFCckJW+xsDzMiMDQPACt3Cmr3pYiSGMbsokKTS ZZJFHmCnR+FydOQd8Q2pMtXv22YosMIKwxuiMQj1EgO2/lCooECfyavpDVApzNEYarG1ZaALEUEG wtrMAjzeZsbUjGmCEEQsIZPikg4eRVpJPuykMYvEwGzj5zsCBZHM5/HGliC7ZpENsO0JpPOr12C1 EzERA+LHB6yhs3Do2E7kFH54rFsea1APGUM4jjIHHlOpSfskAJIRdLvlKAAsYqEq4yBm8o7m5cEA UK0rmMAjRcKdoOIuZ73s0ZBm5TDw61Imaf4b750ZpdC6XhMWUHMAPsI5giAp7dcUxUMhK5wRCELt R5EeIoOu5CLmHts7/kEANYEmH3EUyQPkcmHoFj6FL2/oRH5byvCh0/IfhzAI/VotrgMqgNIQorKi 0yDm/h8svYXw7myT8QwaGqGg9EjyDsQqO1b7766uIEodY60B1S5QCMv7E9bCJPmyKKuRL4yNH28h 0iuA8dtrEU9UujhszFBfucmLvNTuKns8DnlABkqPzxtaXnEkSooO+LxW4bkLAUAJNh8qxc2xDO+7 H60SAPVxKXVxHKrcAuEgIguLMH7zvLw6GRBrKdTEI6wywWPxNQGhoACf4Wug1NkH2yZdqdIr7Kwi vT/Rt8OOuCNAnLeBMiAdGmgf1qJvJCERKoerJCm8vx3Rv1/BHHCS8f7B5Ag8C8QV+LoIaBVe4cA4 EVcBt037IgfTIY4/0P+CvKBiOnD+FzXgpwqLKqyi/tOqOwfDXB4kohPEItlFcjGhy+pkvgKts5X+ fRIgMAAjWZokYRgKiRiAgBDFmzLsaDBjGggr6YcDAAGp4Qn1Ii0QgMXCaAj0AktabpcaEBLLUaG5 0zWNBN7AQFgDraIkKfEuHR6SOz6vl0Ag0EVBAJyVE4AVm0BPSgKAgoGIwcJPokEhkYFATsOIlRrc J4mVIEBCYSQAFlFBTqbOyMJXY8CC4NRAlIkLiSsAQ+zIACMJww7oiICCgDJygcKZMZzLaMqKQQIB LJWKivYjgAuyyvNPpcCC8BO3cYoJ7CaPSuYP2JLr2jmsCY3KgMv2S5pG23AUASXnhIAHdvbg6aNQ /uGCAwpGfUqTINu3SOQKeFEA64YKjpUYPMsYKcG7dAZWQTuRZsUCkgm84MpH5J03Uk1UlNhXClYk F1EGHLDyxxNPl+h6FYMWQEEBBAgKZGo5aAgBBc4CJChAgAElAVYSPHU2gsECAgEsqSXgAsmAAVXX nSiJouXKADTs5sBl9e+IgycCQHDwoA9iCA/+QCkwgGJLqCieZT2TyAiPZ0+TZJ2LGbAJj2hnvmqK bEQyMPdguJhzzBqLAQUYIGiwSsCqAA2IPWOptAQxaGs4DwcN+IegBa6NM28Ox4unE82cQxNcN8JD iFAgSLxM/Tv48KBgwVqewzz1YMCbchbOVzwJ/keY4NOvbz8wejPKtGqVK7b4fQEKWFFqSVBBn3rD sDcggw06KKB1JaxB2YQVWgjggxlq+F2CZy24IYghilhChJmZYcIZF144IostArNUcC7KOON9ZNF4 Y2A4GiPAUo4w0ACQQQo5pJAzGXkkkkkquSSTS26T5D9RSjkllVVaeSWWWWJ5pJZdevnlP0g+2SSZ ZZp5ZpkNHEkkm0EykAB7BTQQF5112nknnnnqSWcAffr5J6CBCjoooYSqeCiiiSq6onhz6vgopCYM kFIvSER6Kaak5JcppxsqQGmMnYp6Y4l0fTYqqsx9ut5fFab6KnylwmFXW7DaasyqCgonwAS9/kYw QTLv3TqsQZtKKKFa3hG77KTAWXpCrxP8Kq0Cvk4g7LLZampqZhWKZdws2CYxkbZ30Zerh6BEuy67 vYpbrq2ymhtKIt4qG1lBBrJkhWcaEqCMfSlYUiCK/JUwwLPoVvpJu9ay6xW85cqLoiHNXCiAsSeQ V9cwv5z4mVrmQkZdJyvRx6MKaV1S1z+47GMJaqA+e8wBNR9QALsRSBXtzHU1QcsTUPCVAksYjvgu dQj4ZYawIxudxMR36cWFigQbg3AagtiwDwwhrQXQKeDIhxRt4nznSCY9wLcCAwMwIIgVGvu1giM5 wKzwDXBMcIBUUk27dxMIVDsBAiPDAYsw/m9BXY9vDlKTyyn1yVcINfOVAFQoKvQcR8YTWqzWgRNq ZZXgP7DkhVwrLIIaJgI/8faEQJT3Q8bQIDDHFAj16UkYEi7gDBIKeEFR3CZctAvanETXiMxJCHBA BBGIkBX0B/y+Bq97by4hL27DUfepn1Am3g8lIcAIFPSdrwAxE813CBNR+CJFLdtHbUaf3fJAhQK1 GxIJ5lBRDxZUQnmZcAE2zgIVIKQiX985RxJcgBIooMQTKYBCUoJgtv8NZhuAIEJVihezEjRgZnuL gER44BFAPENa0pJBS2BxhhQKxGQCgYHKCpg1bCwwGdYITwqeAT5VtIdcWTEBwCATjN/h/mcXQvzC SmwYxE/cb0KzWkP/WoIb1mUCfEBYSezSZo1VYCMcLGjg9gDzwyTshRT1qN8rPGaN3IlQQnGZT+7+ VxK8mRB6KBzFLCQxghMCDmmvYYHKdOGIM2DBdG6UAgEx0RpHpLEl7KDHLj70A6CgLDrykWEJOsGX 88XnCwkQ3hCWd4IqIqpPWKykI4Qhn1k8ghxGiYojapI7GgQgDWmBhQ89xpwFUCoXyMuBWjwpx2Ry MBrFKEIa9kipEibhhCg8gBBxMIEH+NF6huzLbI6RlkUKMAer8CIia8A48Fzyhllg2Tm9YYBNkFMX +lBHHEswxFMyEZlU7NyEBoXF2r2p/gFnWCFUlCOargHvgxXjgReQIYeo9HI34FEaD5JgExvmLpo/ WMpK5BDEOg7ngplTRh5HSAJqQsuPEegnCmoWPRSqDF85cQsxPIHOchKBBbq4pAOZ085UEAFmymNd YMaQylF6xRMQ1CcUaYCDKT4HoMjgD3+owD//Aeab32wOULbxHlISkQiABODSsLGNTNRRF0/NXEpV OgKWmmACC8CD9SaAgmv6sQxWeVwOXuCI5KhhLF0TXCSo8ZRarpE67TwCAKLZQUwSYQeStSdqoDKG ZixtF07AgijKWtV1dCZQmRlduRhlyf+JJX0nCCp1FEZXCdmsttE6AHdkeoBTAqY2/qX8XWKBGUt6 sI+fp2yADoTXWaGqUqzOW4I9I/dRUEJ0G2iJUtcC+4VOpPF+RkiNhXgQA65G7BOdWG5gDBfbafbM rrW13h9qFhH4qrdV05BRvxohrmkA8gytS54JrAFIHwAMBkFAUX1JtKl/YSwQTCspVCpZXhzJtmcE sN57M2w93k4YPCVDj28htGCsioXAyuhlf77aYRdVmGFN0LDNGqPiFYPiQCGKmmX6YyexiOUxNM5U i/WmtPm+lzESFlV+h+VdI1AhoDY2xIx/HCLZ5gd0UBlyTP5QunuNKsnwakCCpVwu7w2jcSgo8X6I IRUGFKAZaG7yotZQqDnTuc7L/rgznvN85z3xmc9Y/TOgA62VNhO60G0Oxg2IoehFM7rRiwaSo3/U pklTmkhourSSwKTpKUGnS3LISS/maCUkkYJLm+Y0plOt6lWvqdKufjWkI11Q9sm61oK+NVYRFug+ 87rXvn5MnYMt7GBXrXliPrbxwoxsYpF5ruRdtraWDO1XBXnaYpa2tUdV7WzTGNvc5tS2vz1hb4v7 UuEuN7zIje7wOBg+5153ttQdnm8ZIwBF4ZiDEKgEozZnH5RRAb/BoQSPyYmEEpZzk+GdqQR4OUAE WcqsMmi3B9EOHm9CL2CIeRE1EG2JJThfGsS4QH2wt956VkaUFZ4hhoMizuHV/iI+QTG/UKbcOd6A rE6O9TFz2QUmcIPmF+wpin4SFRUlH8ScUd7V/ySr4SpvDsuJ43LVfkJ4RXAMD7+hMl8I/Cm9MRk2 sgJq8HhDhHWLii+cEY9Stnkpan0DRTBbwBwM9qgkKPhKe+YDOmNMxeftBMShjdoARR1FU79YmLfo hTgiwBeAOAUNcMPxU3yKaJcQSc2TcHNlCtAsmAjtIi3y2nxh9gmWeEQe53F39jgKIcp4zDLigjG5 +OfZP9hBmx819waRYy4BhGrjNkjFJFdIq650pZwDij2nS3Xt8HOFLg6wTh3YoAsv+GlcqVP2L9Tt TebMwe6eeALBdSWfJdh9/jXO2hPWmycrsmkbm2XjmEPfABnKNoHjXeMRHJBLcCS4BUtoRZ+0m3jM HIMIj9J80dsMkUBYwTO1TfYZD/EhnEC1BfIxGCgggFg4gin4FwvMT3StgurMkwL4H0apTXjkRBHM k9bRnT8VwVvpF1JkRTEJxEGpAUYFTU9Mk3lMTZtFmI7dSRYBxvB4FiW5kT8gEsO5QkhIA320U1fN i4nYBVpMRwqkRHQExHn4lRY+xwQeygUm33AUWBIYIDdMQlGlgwCxQS0Ujj1kwuIJgXgUgcBEzuIR EQqOhMQBBQLslhdMxQdJRi5Fx0xEzuqRUA82Q530B1TciWOAhvTNTS1E/gFy3ERPqaEbmRkQCZN5 VQMjuEBTUAM5ldI77BH3mRJH4I64FB4KwNnhfZeXdcJtqMDGdYXmxMNLAIEt+ZIMiKIvBF5zvA2J NAXCgMEokMQMNALIhcYYNQIxqMk5scQtUKEmhtNK9SCbtVmiNYOiEZpWtJ5VXFUReIQLOEHxsCCP /CI8AON3QKFTUB4T5gYeeYzjQZUpxoFHvIE7Gg96yMXhyZk1XhHPjc/O0dupVEZG0Qg1CNxrOZ1x BCQAgON6FBoxzMYNUKRB/QVXBJY2TGLX+NcmeANpNAIN8Fs7cuIgLIEXKRU8vBZIsI5dEFUUqeI/ cYah3SROot39HRtU/tSXQz4k+znPbkQaf0gaeXGXStBACcWDO7zEPlidv/3hE6KkgVzBOiEXUgWB XojgY3jMFnykFsbgKlUZxuDanz1G5j0dUCIiHAhArEUakPykCeQPk51BAJCEftGljUEMWqZIWqak iqledLmMDtzhawAcBrlCFMyCFBShADXWaKklqkCkRM5lQbEJnOxkqnxFV+FALwGDIMjAXXLY+ZlM WVSkERRN4RxMJbGiZHIKZS4YMkiakNTfX4rZIM6MaxHes72mi8RmW9aLiS2DVinda/aSlz0Nfbim b14KcNaFKyYKXTaniDAndT7Kc17nq1indt5IdnbnqHAneMrId44n/qfYyLIoJ08GpXmKCphli3p2 ClW2RKhEJEkM23CenH7u5579mn8uolkGmjdiVU7iZK0dKILSZpsUlIJSGqs9qKqdmoROKIXS4tgF A4RmKJnAGoe+GoIyRYLKWoDe2n/SCZyUKIrGBX6uqKH8o4u+qIq0J7fdpozWqI3eKI7mqI7uKI/2 qI/+KJAGqZAOKZEWqZEeKZImqZIuKZM2qZM+KZRGqZROKZVWqZVeKZZmqZZuKZd2qZe2CoyGqZiO KZmWqZmeKZqmqZpOHYP00pq+qYoAyoWwKJ3WqbCdmJ/kWZ7yJ5/2qZ/+aeylqKAOKq9JxoD8S4gm qqLSRt80qqNK/gVjMAaWRSqlVqqlXqqlaiiZVCindqqnfiqoRolmNkcyhaqpniqqalqnpSotGsmn FqKEmpo1aCqtbuqoCtVHFaJXzClyzSqmtWqtZlqwXtqYDKuxNkmxIiuwyqqvHquzQug5OGaA/Iuv jt1k+IKohUmxsqqUGElYXYmrcmqvZquncZqFcus2qAm6riurOsmtGge1ihr/8YKXyCoB5KKWQMeq qmqUqCuzhgmsNquY2MObdOtMINfAjqvBAmzAPokKKCwt7gb7UImpSQG7XizF7iuYQMm7gga1hmu6 8pZa5GIyMQIN7ADE8kTlcKsIKGzXCAC2emrXyM+5BuCURNLG/krJJsSsOsjF2FyJxaYqyGJsmKjr prnroZIDdLCPmsAJ96jsD6XBDmArkEDH/1hD1T6s0RpJr/7IP+yGxkrJGyCs8nSaxGKtqA3lP9yA fJzSpyQFT4zmP/iXDrCt5sCAfMzJpNziHDGidcUFcm3CYm1DLWzD3n7aI9AJ1CZuMMxTGvRq/7gN P6BtloQt0b6qq3bs0v0DwpAFtjZFyXQDAEgfJExB3y2eG8AAV3BcJviCZSSTPIjDafDslPhYL/xL dmVNZFUcFwCBj3HDXYoexoRaYH2XF0AH3RpjZeEt9K3CzH3FDmyRHDIRT+BGpwnCYzQSCzaeMn5k aAkS2BFR/hk8789ervmOSQQ+ITnQTcR+yhyUzAvoBgzsQHl8gzC8wDyMTen6l8VGFgu6AkdoF+OO 60tg0jxggT/Mh+T2b910UuFKgf9uQlgh78p81BOEpNnkzTx8zRjg0Rm0zQ0lsDpMBXI5ARfc3iW0 AjOJHko85kGJQN3g6/mar5hobquQA0iwIN4Szz/wAFWchTcgDMzir2DNUenWQv8+7vIWJef2DwH7 wm5U7wvMzy/KU9zyBIClQCuoU9dsggibjRRvQgtDR3Ik5mN2cC341zn8EO0W7jZ0jAjmTmGBDSO0 sHNhF+3OMNEWYiHa8F99VMHOxD5YztWGhP8yAjmU7hvn/q/hXgL/Po7ULm+UWO4U0G52dR/hXoI6 gc3aWTEHWcEmDPIdxy8LEpNJuDFPvEQ6+RcqM4IM0+0V70ALyxA71LICqsQWH28N6fHldlofJ22z holdKG0sh9oP9dJi/Y8IPIYXrIEIYJ8rKybHPYYMi60lz0MaiMDuKPJilqybykfySXEbdBoOBIQS +4I2c0NbYIF8rALqKJYrnaxaELAhLJbY1bHg7o4tCBgVyHOnldhXVDIv9zLApi98xOsc6a15rC/A QccXE5rjQcduiETdAsUaR4IHbcOafXHlnqs1EJNHp0xYNcBFt2qVrCola6tKcysLpPRAv3S+Sut9 xCt0/iyYw1IsTOe0Tj8sQ++0T5905gIzrIKFnvnAsg6smOwrSv+0HucxUz/1+fqxJfU0VFe1VV81 Vk+JVO/Ksx5srXYoh+pGpS0qWZe1WTtagaa1Wq81Ww/oiL41XMc1oAmhJtYHgdFJZOF1XMg1oBXa oLU1YAe2YAv2WRe2o0GvYSe2Yi82Yx/oWjPIv/wOn+W1fwKqZf+pnWb2nMGpy33pVGOcVfQmfLyB XHaLFZk2Z6f2mGo2nV62a782bJ8cZJuDISQDod42bue2bu82b/tHbP82cAe3cOPZbC/mcB83cie3 ci83cze3cz/3nRW3Ifhpfgo3g0E3dmc3oF43cveJ/nZ/N3BLd3W7olb59mWT951NRFtYNhXgadMJ N3q7tlZxN3BbyH76gCTIt4l5N3GiDXj/t2uLN575AInd0QmzN260meDsnRD0D1VgtmwMIFQEAnyX 4B9MxHkHg0fwd2wbNUabrp4mwiQwuJ9eGFmIRV7wmNgZH4C3OJ8K+J2p1TaEgSNQzfL1qVusbcgQ zVTUgJ9mBBvACTIi3L+0d3v3aTpEqzM4GYH9CQW2N5txHPI1uZz96XXtBqCUmCshR5FX98mpFWYU EI/5b9NxuIuf+TLA+DJcIQpQxRRgwwd5eZ65BTpQwZAlbi7RAo7b0zmMDlAk072abFrgeJ/vj1hx /nnvPOUTOMIPvrGiVw7sIfkhrMHLsAHwmi7h7rnpWkFTcUMaDPKJo7mol7ZzRLYR4JlaDZmPPML5 INfb4DgNwIIMuIC6+oLjFU6fGnWP31JhAtcNyZCmz/g3DBkvpYNUUVJISO1KSF5OhQHDmTef3mvr tMYPKA1Z0AC2p3iJi/JK9LmsV8IUjAV9j/p/Szd9p/pFrPo+/Dmsk4HakZEORNGp/3isM8I8rWra eUFUqAGhP4JWUALhZjuYF5WYx/sZiDC2JoKc65m0H5AnbJw8+sI+mPl+5rifFKYHceDDXwO5n7ma o1wLp0gUYbtsYHi02xMbRLzBj7t+5ng+gDuY/mENRjsev0c7BMUOSXgURmMiuMcGuJ8BLYMXP7A8 w+tudOm7FPiCIJAD0aM6AmkDcrFAWcR7YNR8xwO4uaO6OCSDA8a7IAyWphPYFVKrrWMCmuH48FyQ 0yJH3WXDwsc4sKO4DCSP0quVGfluNVBF5H06MoDD28f4YM3ASjD6W/Q53cT636McsAsMts9E2UuF tl99uSdtFJy7KeP8PsdD4ifCz+Js+s3S5ncRLjCh5kh7aFo9f2IDx38LUFyDDdp56auOzr+Aoq9V 0885Y94gGMl4n5zSw97+nT0FGfVCJrB7m2G0M0h+i3/8BiZD/wTLf6w5dceAmgVClv8Jdb/f/lRI BOjsaZOHPp4SZ1QEiQZyeJNhv5Z3PwVWea7nKk0EFMoROZxhdvmqzvKV03srP3hnfYx/MRdQOQgE wkiWJlEYqooQwSuIsWzWAqGsKkPMNG0LkmSvhCFhNMSEzKZTtIguEgig8xpTIBhcBkJhHSiw5LL5 jC4B1uy2+w2H9xaAnilAyLusZ7zelXb3Bxh4NUhYGHiYKOT3xwfDKDlJGWd5GTdXZ/PSSfkJGio6 Slpq+omZmqppV8N3ChsrO0tba/Zao6qbKUDX0wkcLDxMXGx8jJysvMzc7PwMHS09Tb2817mb3cbq M21LORAuPk5ernCOnq6+zt7unl4QLz9P/l9vf48vf7C/j+D/DzCgwIEECxKUgjChwoUMGyLUBlET AgMOK1q8iDFjxQYcO3Y0CLKLyJEkS3bJhzLfu5Us05V7CXNcqWrMHgWAqE0Tzp08e/r8CTSoUEwC hvY8hDSp0qVMjb5h5QgpzanHvpUKJySmOBNau3r9Cjas2LFkvTp1oynAGKtsg0RF1EgprkIiCgBg 8kJPpLZ8Z53d1mvT3r7fbvZCqADAXBw6Gt8oEyyPlQADEijmZCBAYzxzZ0UlLOovG26g2fZorENB qxMLDKgTowIPFgIDVADIYaBFCSiXT2g2IGZAgxWyKRUnIyLd4NKJRK8h7Qquq+WcOtOl/n7m9BF6 rV2vJkFgChyKrq3fqI2AykSKq3lP1tygzopzKgTlCbR2doApSBLwGDTEI2kAQ4tzm/gS3UR2BTMC Yyz8stcLAEy0RyDDMAaGeULQlhsCDRTQ2gIFeMGAAQV8d0Nro1G4hgCZLYabZS4iYUAD7QV2h4vk gaFAAQgU0IsSL9Q23x8j+CFCXiLkcZsBdZhHwETdHcHAlEYUgIcRSYChxwxHJinZDXj0qCKYgCAJ ioHQHRleazwIc8MBL9b4iw8NpnDXEtHpdcUAAnwRQBVzMbjbjFXaBUACNymwAAPDqcaak7chEOJz L3LioGUtHmEAA3keiWMJBNQIgIkT/uqwgABG5JHbc3lE0QIKUSSGwAC1hpdbDlGc2ER4mrJRVBu1 5eHfaDrSwSgeIgLQ3QsLMFqAAiW2ut5jK6Tp3JopOrneZnikwKqnRcZIoQooJjfCBBMA4ewUC1D6 rqITApnVCOfkmJujxa6hABVceBcpAAcMwCwda2iGXaAq/HrwfD+ECp4Rt7ZGMLO5teZCiZQqS14L uiqxgq1HfCGFiZ3hygYCLmpBAL8GvKrDAOGlV+XLpSaQggINJICbtLmZKLKPriXQwL2oZBtYexOY +gbC3+pQ1IgKCokCRQu8wuEKCaDYMgJyhAepDVM+NoRmjaaXmXz+lhg2eCo+q1iL/opd6ooR8TWt ApZDQNygEa3l4GkdAAy36g0M9Edkd3d1jPGoweawBsZMoLwGkZ2ykQOxrnnxgg4BUJGCZnaNyjYA KaQnnw7T3ne0aGsGsLSn7dWWl5wtdzrqfJnlkYISn56g45s1JAacjwgcEC0ULft5x36atgdflV4D UDGI/7bdYJktt1yqfNixehOuTKNeKB0nXN47wS6azqkd3P/8BQP0RZsbzovfwBjHKIo6UeR5r9Cy zI3Ka5IxWYnYlwA6mEozJbqJlJw0KhsFAEtZw04a1JS0ExxwSp6Lk6RoJLtO2cx0PFPC/s6zAOmM 4ABjSIcAijaqm+CCNoZhXoNc/tSAKvEgBx5rFNu+Qzn53M57r+icDGtkG4vdyHy7qU1idMW9UtWn bJqZSFEOI6ko5OY0qskfrk6YPUmphVNYchmrtsY87wjQCHigyBhTUJQSlSgGCeTiC4ZjQTRgEEEn QNvojORBf7jmdBQbjohUlAPs7UaFR4JDL8pImckVcSJccBelErgFN1qBcsE7wBEThrC5MWYNhdsb E9VgriZdbQBTAJcLVOcg70xJYy6w3ET0NzkVRS4Fh+PeGrcGKs/56hfX0ozhnETLkP2GbpPY4yZq wBhPcaJfRujiRBKYJSpoAQ9cAKMTyDFBTUUSDa/0oUC8sDto6hIAc+Se06qT/rZRVc1/S/xdMBPQ i+EAkJ0vwsoAOIMVyTAPCN7MJcNM5wYX7Y9Qu4ETFbvRiQq17i/aAk/y3MIn/LFOL+4rKGRUY080 TJAiWxCJIKtgA1+1ITGjYWZDgUM9JVCIAEioZ0qX6QUa2QxjjggQDboUIRgQwTpRAg474sGol7kl j5GARNm+FBqk8fGmzOGEJMakgnd1ZAeM/KILJJOXHIASNY3RjSlD+qVlmguOHvJoKMZI1sY0QENV NYEz3foJvNaiE7hZAQM8kdLexTU2g4poXjI6hMr0ZjqOCKtr0AqLtySFrnVVg1SfWdla7EEvx8Fo UlJonarkyC5NIFSYMmsV/qqI4K5IMqw1mMIUycJ2trSVilRkW9tr0ASsqu0tQ1ELDmcKIFotaUdK jpsPfih3uQcAiXOfC12NSHe61K2uda/rkAZkF14ZOYxCPAJej8DLmdIqrnlbYsMB+dYYuW0vbQ0E 3/jKd76q0Al9RxPFp7h3v7OFxihect7zIncezO0HdA+C3YX4DqKUPYMz1YIGmNRAwhwcrIUvjOEM a3jDHO6whz8M4hCLGMP8ksVdNctLAfipGE9YL3v5C+NB3HfGOMlvHPpHvStEUq82ODEtqnaTyrHD xjQuspGPvBMmZSJ1lTNEDnh1wcvWCS8/4DE04WgpP7AhAH9Fspe/DOZM/uRBARLWUZOpjIMSQZmK 1vExmyZj1TRULVgT2vLBtMDSMOt5zzRmUnoLlcQ/Ny+pbTzRUAkkBAONYKoiWHHZvCMzsTZYVFhe gwl7F8s838UnI6gckfkM6jD7+S1JMnOO3cIoltayU0vSUX3QZFcpk6BJMrqBpVVjGAgK9bRA7dKd fNekFeSwYqXKszy3XLF/qiKJjwXKfloT5BbUYXq7+FOo98wkNoPKCGd2RY9alJyiniiRjXbBvb7j Y2cZ4Z84EGRR3tUaAZzDa4xKVR7g5QJYyWDOp+rRAHoX5GK3tA04JlUqdAlToPytgaW6oqR2Ablr 12ECn6Yvk/aDmsdw/vvUOfKFlMCgoFeC9GBjA4KP59m/FNDo3+TxT95qw58/UaQBvUACSm8QumKn oAD6fHiz1UYqIglgWnCVlKoqZzNKMWuIgQrMt1VWhe6NiuB3uxztTKgCMjOtOy3jmcpUcDc2AJCm kOurpofSgwhIAAIQcIADIIDkLhU1CV7auKDt9c+FUSRnezDhu4Zrs5pa1nUZvAHkUEcq0qWtNikg WIhasx6XjW4IoZvgtFas7Fu3tACV0bpqJiIzigzdSREXT8NL1UYuOklFJvLd7kY4IU0120UOx7jo FCMGRZnLRXhog9VB5qRhkQ4oXVp7293+gOQnHwL8FYqf7x2bOtnd/hXWnkLLegepzt3ArzsF5qyl LDNXq6A28RkVlgEHwXX3KAtTbKD7QheBJFiGy/bTvKU2FXGmxdNm3EM48fbjIarCKKqyALYCIn+y MQ/HPnmzZQvmJAVgGY1iMfVhMxHne7KnUOxDSoHTExPgdg5gAA6wfGxHgiT4AB+IgimIghJwgs7X Mmxib9smKYImApn0VaDXChj3gj/TMpLzfYTnC5HmGlrXH68Eek1SIqziC49VVOGzeziXGbWhU/tk f0JEPSVkaYGzf9uzBgVHPIfzOV5AgOcQBUMHho0iRrGnhouDMOuDJ4ekheujgQdzO8ECHJJyQMzC gTxBABHghxCg/nwiuAAlyHbqYoiHiIgT0GkT8AAu+DuIIALTN1qZ8wLn0B5FRRw990+DR1FJI4SC Ix5T0jkLk4SjyGrXQiSKsm85J0Ih4wY/d2w5QHvscxMmMk8RVyyO4z2L04WSQhGWRjCacX2rl0Uv A1Mrwy1O0in9AnjDMjcqczOxxygMIIdV9GRGYQcRcACB6HZwpw0K0IhBkW1uoSozSH0ekk6dxSby gGvxEH6ceBbcAAntxgBAciNLQgStgAj6KIsbaAmwaHTBZyq3lAQ244a+yIH8N4PTIz+kFD6a4nQc eDU8UAd/5Sn/ZjoEMy08wIG3R2ZrkAIGw4EEID+X4zrZCAF0/rYLERCOxPeCwzADkngCiZNHGvUL pwWPTkEax9FGjYFr1xAgdsAZDQIXjBEsA+QjCTERZ5cKCecGCBd2EqcLz7Y1UsmSaHcXxJBv5hgd fVWTWOBmjIVojMBvpBRXSBBwuiBtbyBvJSaV2YACJ/KW4DgUIAJvC4E23dY8SzBphdJpslZEv5UI VUNsb2mYh3mVu7AUwZZheslYzQSYTnA1bPYMTRhjl4mZmamZm8mZi3mVmYkTuMVbmZmW8RgYiqFb LgYMFXeYfLhfrtKZnGkNBwBaoqVjgMUEWhAPJlFgynVg/pBCUsVdCSZdx/Obz3WX7zIQxMmczdkQ 4dUAxwld/iZBnVzAKA7QIwOGXMVVFoGAQZsVm38gZs3XmuU5XwrgjeapnuvJnu25E3TpnvEpn/Pp nvBJn/eJn/m5Z/apn/3pn/8JX4wIoANKoAXqEwJqoAmqoAv6BgjKoA8KoQDqoBFKoRUqn/xpoRmq oYeJoRvqoR+qZx0KoiNKojMmoiVqZKyJogTKKCs6X+EJo5zZFolIozVqozc6AX6oozvKoz3qozy6 dj+qoxJApEVqpEeKpEmKpACgpElaghJAcSq6ZwIwAWunfFeKpVmqpVvKpV3qpV8KpmEqpmNKiGVq pmeKpmmqpmm6XE2qpH54pDwKAEJKp3UqpDh6iLTpdhFQ/prYxpIPwEJpdSExSqgx6qLxSQAH8HZ9 +mUsKQEqeaiRep8eKAF6JgAOcABSKqmbup6J+gCaGl+XOgGcSqr6uY2g6hweyKilyqrt6YGoehaX uqqtSqvqGQHpeV8E8ACQWqu9up4HEAE09gDB6qvFyp66CqtBcanGyqzrqXb39QCF2azTKpUB8Kkv eq3Uqq1SCQGjKl/Puq3hGmoTgKsG0q3iiq5T2pLwtavp6q5fZq3JyofM9671mqL0Cl8EgK/2yq/Y yqux6gCz2q8Di3br6hwBsK8EK5UC8AAlmKls8HbAgp1YWZ66+q9OgbDy2hPD9Q9M6RMugAnhYWmI klDU/mYJUZANvKpkb7k0ILgCDhAsD2AAlUoAIHixoflzhmmx8RWv87Uw8leXCuhINsN5cIAxmBAO u1AbbmBMR0ZkUbSyHhiseeCBDrA9blelBkCsglMH7pRfmwUADiA4ehABBnAAcpAXbRA+R2lrK5st 7QpfGTtfSAAsJqkYHos5aYkDdLZOwsJSmtE0BxAscuIqqzAazxEP/eeUTZIYUOsqLLNlG5NQDkCs bVcUuup2V2u1dyGCDuCtMqu5bLA03loHoNsinZueHgiIIciIrLsGcgKCMFsHnWsAbdd2laq2LmsA 3ro0beckOvJ2EZuvcGsgcitfG9eLlrYCJsuYJslB/ovziy1FHFNXKp7SLaTnJEtzsUcgMDMIQVCz TA2YVfpHPJ5Da9W0DSEIvcEaAZ17tpdKuQCwNCfIviA4qu2Lu/KLqekis/nLpAvwAKQrASGodnta tYrhABLQhxFbs28XAQIAAQCskg2siBCgtfJrAA17A1jLiIMYXzsbtwlrIMjbJKcChfl1jUk4Kolh NqeSX+ZCU5nhi2DwWAjzZDn7ismIdOwTNTfBcGxQG0WRQGwYjYlijCnUhKORuZfasEzquRZMACwI qDW7q23Xh8v3RaJLuyLovwAQwcRbtsTqdmsggs+hiFI8uwaDwaS7Bu3rraMiti6Cu258uuVKUcR7 /rDZGl8kLFY/1ypsgCdsiGMlbIHAqLYzXMgLeFCvaBmBvLS5kyogKbS8xz5FZWlB5kSokZaUanyU C4iJursjuDRnG8bGF8AtKLozSwAeqMcYfIKbO6e7S8ZiG7aNGMUg+AAeTMWpvLX09Bxj7CLEKidH Kbxqgsei0bPHq4D945TRK8mbojB1O4dip5KAW2wW2DIlMhw3y72Ey4t1kFTYm1DAJkIslTYxVRtv ggNo8XYBfKltN6qqO6yM2Hak3M7qErxsPLprML9KDLNlO8ey3MCz24ijvMpNvMv8fMFtMMDEOip0 sDTEir/8XMxve7NDkcx7/CsMVMSaUZiBrFCz/pg702xpBiOLMyzSRoVMsMfIlWwxtyGSL5M5wpJw 6xFk3Eu93BtTX5vLngsAPR0sDrAAVvvQ+BrBARu2Q70GD1CpEc0G/bvUC22/sTyqA73LTi0BDDzG Ck2zyTfLN2DBwTrKTz2zWd3Ew3vRztfKBpI3IBJoLKDTKSMp/Ti+acNDUZQ4p1jSRqw4gWwbA7CH Rpw6KzA3HVPYUJt1c5OQ5it+gY3Bsisn2SqzEITLbAC7LVPZv4HBZ2spmVG2tIzBLxPGTAbHsxuC J/gyI70pGfzZOxiCC700JKuvGcyIBnvHaS2Oa+0cOqMle+g8jj10z7GWVTJXz8ER+RUoRbMG/oEz BvySQy2jFoh7Kk8pRpxHG3dWtJVDsojrhMQGHPIGteewqjHwHLZW3mwLtebdA9xj3ub9HOFTmkoW cEq2svRduPj1aXqwDdvAPQltzLhNfCIMoqx0yGrsE7/R3yzNqr+hLvXxwcdMUQK+orERFLfUUgIr qdcp1L1s0R8s4Sjqtj+hsQq7ChAej7pN4in+sSaukw+A4SoO47oAwmoCAS8e4zduCTP+tjaO4z2+ DSyOjS7u4xZacSNucUBesDxuCdnNhyMHyEou48z7EyonGloQojcBLkbRP0s7HtIKEW152w8O5U/B M5yWsw9tFIn8sTXi5ULRt14GU4Ps5mnY/uU+Eddcm9sALuJCPhRt3iIy0wZiAmwga7fkDc75Bd6j 0dzjLL/VHC0Jxat/4kvnfLjPASzQaOmZzjsqmR5RQme0MT2PdN+9FzeKUYaj4dHGEpxugB5Nwkqr 3iRRl5WNBwe6UhQR9ziJfXpgvlIMWAewYdcOjnH4xC88lGRIrtZj/gZwA4GueMjzMdgOfr20Qtjd YjC6mxiWw9LiNz3X2zXEUbdFsgIki2NiJUWE7SIV81g60AaCZSpm1xiWLEWWtn1JIE1HUCm5wzS+ Vx99xWydEm/n7uts0Bp0V3bYSyNeMycHJSf0gSxgZxu4EQNsznBZ5dgyjuy5rezpGx/j/qfZ/A4z tGh7K4whUuRAJsR7uigtSkRTKukiJ1IboUcwK2wxpO7Llbe4KzPv0HY/qS5wd/66wS4CaUPJAwQ5 xyJPs9hpbuRFlP4GMJWEvJhIRljESYR/y+0zO/3H3/YzZ2c2I3BLGSiM1dtvKnY5OJwTGU98fM4T l2N6gYzfS2MZOs17cnLTxGMwj3c1Cm8yLvMsNiaHiWIZLjABR/jmmpFnrvf0Ck88iV8F5Ew8Xj7I wDH26wQ5g8RGOLYl0R59QvuKBINjgKvvYFcqFdO3WQ7IApnuOez0tKYDpwHdNtMqFfZ/R6H2Il7j la4Nbi8pcn4qWlMqBsN7k088mvI3/l8g61Oy2jkb+AtgIy5bIo4ntIhPzcfWBiUyzAKXhU3780yJ OvQeSuv0htplKwHPL9PiIm8S3dY/HkXBIusjQLRxOxXDx+fcA1suw6oWekIzziRLMDMNAoFBAAYC LAmwKqsRrLE80yvxCLW+8zEB5Xo9AwNlWDGOPsNgtTg+V4XX4AUQtQwqQEIJOAEOq+pA0OR6AQJD DjslEdhGmkG5DsRJMkK34RoBVAVgAUwwlbTMJMEgjNwFHsapTFHVkayxvERBXgHqGLS8qR2tNcU1 HaLNaAFINnI2jMS9WBkszHQxHikAipDUAfC28MLICe3cBB0v6/woM+/ZlihtxmgN/jwdiSwc1KEa UBZMj9VREszyHnUjTBXFrNkCr3HXnVTHiMSriMDMTJ3le7KlDsEs4mZkKwdgSr9YBPsBm7UiXx0/ s+rcWkOiCh1wTzYqaUTwVyJgMiiOmBJMCcFaLdYctNEylBVfK09QMuCnxDNoNnD4DGoDiFAZCVow 2Knglgx4C6qQyJc0SJepX9xd6ZIgyACt/RgkSBBzIgMBCxroURBWgIIiArCeXLDgIAG4McT1a5U0 kRQGARTAAEwjgIAADADyDcZAgZ4rZwRPVKDgTCvJys5gmvEXT15lZgboEaCHQF4fA0BPTD0Rj+or jfGxtoEP3+hzPor6AIqbmbPd/r5/Aw8+g9dO4caZBWB6fDnz3cmaz+gNfTp13BKrY8+uPfvz6tK3 gw9fOjz58uaF3Bjf/Pv59u7fw4/v/MHr6Qd6ys+vfz9/8AIeaCdBBP0RWKCBB+I2AQTaTSAGgg9C GOGBBziI3X8SYpihhuZ1h12HG4IYoojACbDgdhJUOKKKK7K4AwQTgBeAA/W1WKONG14Y3gEA3tij jxB+qB0BDsD4o5FH6vfAgOUNiR+ST0KZHQQpkjeBA05GmaWWwA0pwXsCELmlmGPi9h+V5w0JAY1k stnmUFfmR0AEDhywppt3PimnA0Ta6R4BBzgAQQSFnVOooYcimqiiixpKH6OPjUJK2iCTUloppQJg mqmmm3LaqaefgsrpBKOSWqqpp6KaqqqrphqBq6/CGquss9JaK60U4kohBA/sSdSBDfLqwAPDElus sccOuyuyyzLbrLPPQhvtsxBQW62112KbrbbbcpvrtbmCG66445J7AIrlopsurrayG4ECE4imYaTz 0luvvffai6e++/Lbb38hAAA7 ------=_NextPart_AC0_FF5C_698A10AD.FCE817EA-- From Addams@ach.clubviva.net Sun Dec 24 07:41:57 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GySft-0002CU-Rf for ipfix-archive@megatron.ietf.org; Sun, 24 Dec 2006 07:41:57 -0500 Received: from atuileries-153-1-13-15.w82-123.abo.wanadoo.fr ([82.123.244.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GySfm-0002Fo-1j for ipfix-archive@megatron.ietf.org; Sun, 24 Dec 2006 07:41:57 -0500 Received: from [115.151.147.21] (port=10649 helo=[115.151.147.21]) by ATuileries-153-1-13-15.w82-123.abo.wanadoo.fr with esmtp id 1bRtjQ-000YFE-02 for ipfix-archive@megatron.ietf.org; Sun, 24 Dec 2006 13:42:10 +0100 Message-ID: <001101c72758$dcbd3060$0ff47b52@nonejsrqhmwyrp> From: "Margolis Claire" To: "ipfix-archive" ipfix-archive@megatron.ietf.org Subject: Nikki Pamela Patricia Ford Date: Sun, 24 Dec 2006 13:41:41 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C72761.3E819860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 ------=_NextPart_000_000D_01C72761.3E819860 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C72761.3E819860" ------=_NextPart_001_000E_01C72761.3E819860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Schijf angelica wallgren angelina jolie angie everhart. Ad here all categories male. Kathy ireland katie holmes price. Ricci = christy turlington cindy crawford. Kristy swanson laetitia, casta leeann. Connelly ellison lopez hewitt jenny mccarthy jeri ryan jessica! Courteney cox courtney love thorn. Electra, carol alt catalina guirado. Gillian, anderson gina, gershon, gwen. Your ad here all. Lynn sigler jane leeves janet jackson jenna. Elizabeth hurley elle macpherson emannuelle. Lucy lawless madchen, amick madonna mandy maria. Jo johnson weber angel teves angela schijf. April moore ashley judd becky, herbst brandi. Barrymore elisa donovan, elisabeth. Isla fisher ivanka, trump jaime = pressly? Janet jackson jenna elfman jennie garth jennifer. Doherty sharon, stone = sophie marceau. Jackson jenna elfman jennie garth jennifer, aniston connelly ellison. Blair lisa kudrow liv. Richardson paulina, porizkova phoebe cates rachel williams rebecca. = Daniela pestova danii minogue debbe dunning demi denise. Brandi carrier = bridget fonda. Gt ali landry alicia. Hatcher tia carrere tiffany. Braxton, tori amos spelling. Kristian alfonso, kristy swanson. ------=_NextPart_001_000E_01C72761.3E819860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Schijf angelica wallgren angelina jolie = angie everhart.
Ad here all categories male. Kathy = ireland katie=20 holmes price. Ricci christy turlington cindy crawford.
Kristy swanson laetitia, casta = leeann.
Connelly ellison lopez hewitt jenny = mccarthy jeri=20 ryan jessica!
Courteney cox courtney love = thorn.
Electra, carol alt catalina = guirado.
Gillian, anderson gina, gershon, = gwen.
Your ad here all.
Lynn sigler jane leeves janet jackson = jenna.
Elizabeth hurley elle macpherson = emannuelle.
Lucy lawless madchen, amick madonna = mandy maria.
Jo johnson weber angel teves angela = schijf.
April moore ashley judd becky, herbst = brandi.
Barrymore elisa donovan, elisabeth. = Isla fisher=20 ivanka, trump jaime pressly?
Janet jackson jenna elfman jennie garth = jennifer.=20 Doherty sharon, stone sophie marceau.
Jackson jenna elfman jennie garth = jennifer, aniston=20 connelly ellison.
Blair lisa kudrow liv.
Richardson paulina, porizkova phoebe = cates rachel=20 williams rebecca. Daniela pestova danii minogue debbe dunning demi = denise.=20 Brandi carrier bridget fonda.
Gt ali landry alicia.
Hatcher tia carrere tiffany. Braxton, = tori amos spelling.
Kristian alfonso, kristy=20 swanson.
------=_NextPart_001_000E_01C72761.3E819860-- ------=_NextPart_000_000D_01C72761.3E819860 Content-Type: image/gif; name="Locklear.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c72758$dcbd3060$0ff47b52@nonejsrqhmwyrp> R0lGODlhSAL0AIfoAAcACocAAA54BX1zAAAAi4cAhQZ7jry7y8HPx5/M5UMRAGkkAIUUCKARBr4q ANQlAA49ACQzAENJBWVNCXJJDaREAMBHDdI3AAFtACpSDEJSDWlkAHRlAKFWAMFhANdnDgaFByeF AUl5B2ODAHV7AJd0Dbx4AOF/AACRAh6oDEWgCl+iCHiqBKCfAMWTDteRCwDCACTEAEfGAGi2AIC9 AJW8C864Bue8AwDmCxHZAEDcB1rhAIrrDZHZAM7oANzqAAcASSgLPjkAPGAFRIsCTJ4APrcAOd4A TAsaSxosPEUcOG0nM3gpNaIhQMwfS+cbOAUzRiZOPk0xPmY0N3hOTaY1OrlOTdM8OQBhRSFkRzRZ NVJYQIlYAK1jP7ZlNetlRgSDRyCLNE6BSWh+QoJ/Pp92Mcl1NuSEMwGhMh6gRUyXTVOYSoWYPp+l QbKuP+moNQC7NxG7Tj3KSFfKMXqzSp+2Scq3Q9vNNA3gQyfXRUHtQVbTSHfWP5zbMbbdS+XnNQAB ehMEhjYAdWMCgIsAe5ECfs0AeuADiwgmihskeE0ZhmkYjoEafpQWccYhiegmiQFKchIxjTU6jl41 eHk/ipcxjrZEhd9DcgFVdShgjD1Wg2lgfnlrjqNbf8BShNJtigB0fCt2dTWGcmh6ioZ8dp2OgryC itaCgQaeiR2qh0icf1Kuh4mncaORic6re9isdQm0eyWzezHKfFa5g3S5cpu7fMu5ddjKdgDieSfh fkDcdFbSeXbajZHUibzijd/diAcBzSkAs0kDzV8BzoMAsaMNuc4MzOEBwgAozSsSskUSvWUmx3wX xZUpvcMltNUfxABFuxpIsUVKsWU2xXlLyKwzxcNDydZIyA1awCNnxTNls15Zu3JYxJRuvsFrxuZj wQB3zhRyzTJ/zmGFtn+Js5p2vcZyw9d+vwCayiylvTiezGaps3KTzZKsxMqfvuKowACzvSG1wEPO xGW5zITKyKO5vvP68qGhnHmAc/UAAAP/Bf//AA0A9/8K+AD/+v/8+iH5BABWx+kALAAAAABIAvQA Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmz5kl7OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLMatcm1K1etYMOK HUu2rNmzaNOqXRvWq9u3cGeynUu3rt2zcfPq3Vvwrt+/gAOz5Uu4sGHBiBMrXsy4sePHkOkanky5 smXCkTNr3sx56uXPoEOLHk26tOnTqFOrXs26tet/nWPLnk27tu3buHPr3s2bKYDfO38DwCmguPHj AnorJ/q6+WqnwoXnBEIdKJjr2Htiz45zu3cwRb8H/weuU/r44WKpq18PROj2nO+RI+fJXaf85Ebn 23sP/7r77+DlFN2A6JVHnk71defffgBmF52A5tmj3nIUbmaeeRP6lGGG01UnoYccIrWhhziF+GF7 O5kIFAEstugiASemCCKJR3GYYYtD4biTji4aBcyPHdpIo0862lOkij39CAxPReLUpJMsMhkllDAG WeGVjympE5D2RHiegQXyI6ZOY3Z54FFNHjmkik8SZaKXZqKHZI449mjklCvaaWWJQwalJU5KcmnP n0AJieKggv404JdgSlmlTj3qGSeWlCoG55aJQligpjiJyY9Plw5FaE5/jorokjt5mpSqjbbaZlFa Ev8a6k6BorpnjEVFWCuqpvZUZJGzgnnmpK3qhKR0cAa7lHPMNrRUsKFeeuGwObF6VK9/Ptnmq0I9 mSx5ygpVa7GKDjdshOHSKiiy6KU77aZzGmjmjnhSyVOvOC2qrq2V9otVRcIl1OJB6hlUsEAvFsQe ewwFXJDDAxMUMUGeTuTwQBcL5LCnHFfs0IAEERgdQUr+UzLGv2mcMkQXl+zyjw2LTHHHHBtbXYja 1gtopppSG6+/QDsF8MoEU3fQxAMh/Q/IAp0cUcYqAxD1w0QnzaLFVS8tssNQS6S00wgVfHDUI0c0 MddSd23QxWxnDRukUTb57aY788sovY8GrbdawR7/S+2s5nEblIoZzs1Tuj3BaWLh1KKpc7gi29ze z6AeWOq4QXmJYZ8ysid5547+hKTge5e+FUVqT72226lHnPpCSv/jetZdv64Q1LivbHtDStvettQI Xy278A/9jvLuWgOvuu9EGx+y27FbTcDRxDdrvVsZ6+626txXjbbyT3svvvJqI39Q7uAnzz3qtG9/ /PtR54s4p/IXqC9QmoPbOP3E9l//4fvzn+kGGBWLlO17CUEg/JyHNeDVjkAIMd/q0oe+9TWQaumj mga7J0H1ra9sB+EfugI4L3mJsHHQQiEJCcjCnmAEgmQDYQwzCMMZynAhNUxJBZ/nwK1l8Hbt25oF /xVItoYwLXvIE+LxZOZB+NkwggGM1gpbSEWcXO8lO3TiFftSxS76a4tgBIkXx0jGMpqxM2FMoxrX yEaLnPGNcIyjHOdIxzra8Y54zKMe98jHPuqxjYAMJFz8iEZBGnIghExkvw7JyEZGRJFBc6QkJ0nJ SiYEkpjMpCY3yUm/WPKToAylKEdJylKa8pRv66RtUMnKVroSM6qM5U9eSUs3yvKWV6olLHHJS3vo 8pcP6aUwh0nMYhrzmMhMJmKAyUyUKDOWzYwmIp8pGGla85rYzGYwqRkYbXrzm+AMpzjHSc5yGpKb 6EynOtfJzna6853wjKc850lP2phTLvUEyz336f+WfPoTKvwMqEAHKs5/GtSFBE2oQm9yUEot9KEQ jag3G0pPiZaGohjNaBw78sOEKMCiIAVpAEZK0gAIZAEoRSlBSCoQBbj0pQNxgExlyrKVspQgDRjI RwlT0iV21CMOeI5G40S3Bhg1pwMxKWgYwFSmEmSnOo3pTINakAc8LGQ4HYhVDYLUgXR1IVsVyFfH GlW+QPUfO10AQdQqEKW21YICmSpV/xFWusZUkBDIa14p07bSQIAgf23pU++KwaqNtCCHJchcW/rS szqWIU2N62KpGliBVPasaI1rQRab2cGWVbCgvepEoEpDydL0ozBVyF/3asSMyZWmOk3tQTCbVMT/ agxjK0UIAwiy2876NrRrdKpAhKtava6Wtf+ggHKXy9um9pYjeh0Ici3i3OdatrInsS5WRYtdgVCA IN+97k7yOt7y5gQCOaFAeonCgfOi97w4YcBO5GsP9erEvu/9iX3Xy1+c7He/901Kfu0xYJzkN7/K 7a9zc8LUXJWHJwWub4Dha2CfAFjCBK6wTujLEwDb98OH001FMICBhBgXuyQucYr/QeLrBna60g2s fGJ8XYag4MYoEMiNB4LjHfO4x//AMY1rjDKVdHcgJS5IknOs5Cb/Y7XSfTJgpRzlKrNYIEluSGUF 8A8uC8TL3Q1slrH85YUwGckpHnOX0ZzmgSDH/yHY9TJB5Cxn7L54ylRuiJzdXJDu/nTNZD5ImMu8 Zx0jZM9ezvGZC1JoMMJ4IPrQB6QlTWTWsrY4bm70k2WM6S4nmsk+VkibWaxmHZ95xahOcvP+bJIj C4TSBKE0DAwya4LUWsVIvjJuwbfoM3NZ0wnJMpQta+hUogAn+thJsnGCg2Y3myfH1sl7I4wBAQ2l 2kKBwYODkxNt4yTa39awhr09lAgXmNziDgq27ZHidGfYHjBAd07AvRNnP9vAEabwbSrSaVrX+h/x HrKlxZzlFn/5zaRG80DiHXCGBPzh/wZsZZstEIr/w+I9FvJLcDAQZweaIEkudcQBXuY1e5nOfP92 8XT77ZB/35nKak4yrF+NkJEXGuW25nFDSn0+gnC8ID/XdZ6pDENXH9ogN+9zywtSawoS2iCLjrWg h45n0ywl3j4hL75zQmKcdJ3d2MY6TsR+b3vcuzg5Qfu3cTwU/R2IQDm5t9xxID+7FPi96+Y6s3ki b2+3q0v5irvgx074B9Mtc2lPPH7wk3h7MJ44oKr3TvKe9/we3vE7efxP5L2pTdE98NZ+907oHZRl 68T0e9fJ54dC72iv3uyhpxvqpd2Taffk9Xr7Ok8inRPeM/vzcx87ucV+47VHW/e673Hb2zUtCMUd +NAnDuPVLn2zoN70rW/8tkNv+u67V6+hB3z/75FdFNMf+N2Pf/z53X1uZbvfHmwHe5p7H2nfD0Xe xuVJ19MP+cbLGyiah3m0t321N3nzZw/1Z3+wl3r914CXt3468X9BQ31qV3ZlJ3YY6G32VnZERR7F t3aqh3ubN3zEF23xV0L683zONnqkJxYbKCzSln+iJ3rT5387oYGqp3deRxQFgm4leIJpR33Cx3B+ EYBLcRxKQXkhZl7pZoREoYQEpnXiJ4BMOIMtaE8WgXACwTAP0XAOYTRbCARzBmyr40QzpjJoqDWo wYUCAQUH4YYkl3NxuHBtSBBwCETAg2hkeBkj5xLHcRBg8IZQMIh6EYi/dB0b4T4hdRhTESCE/+SE s1ETYIgRk4hNQ3Ubh5IbpgEziwhIl/iJg9GJovgRoNhQo3iKqJiK0VQ9vDM9qviKIJVD7BM+tVQr A7ErEuOKw9M0YAOLAvUsnXd5RjFF40FIeDIlb2c/zGdCpZhP+5OC9QMcI/QgPROMzFhHz2iN83Iu wtiM75SNdfc/7PI/KKiMzneOdgSO50iN19gYvmg9vnE/RGVC0JiM4VhC+LhH6hiOUhSJ76gaUZGM Z1KPy8iP5niP+sh80GiQf9ONZPGPzbRq4pOG2lNkapiGF9lKE5mRF5ky7WNN3ogVA6mN61iQ9oiP J4mQ2HiQKbmQ+RiSwmRATGORFlmRyYNESP/0PKgEQzm0akUEkUC5QUEpETBpUCNVlJoxlPBYFTKF lC2klFAZlVI5lVRZlXvhlKFolc2ElVx5iVr5lUBZIQnWlWTZRRl3he2YFlI4b8r3E/rhdQf4R2BZ SkthfwoYGCf2XhTohCf5gfCHlmUZmGUxNBaZZlnmhQznhVroEaNGk+5jcRf3c/3GcnNZmTCxFBb4 eeBnQhwIgp4pfFAhg+i4P3a5bFK4loKZmoNJEWf4D5EGdUz2aMg1XY9WERqXabh5EIhZa7tpmb45 GQZXEKHWcT/nhT6liBlhXMS5nAcRaqHWmpaomntTEbXpNmAom0b3ER6Zh3QGbL1pELX5m+L/6RaI aDBiyGheVp4EMYmV6BFGA4bseZ7/EJ8D0Z4ceYrSuRycozN3khMvQiqBoi5QsTBwkyZ5gzlUkjdw NJ6olBg8E4/5GRQMak6sOKEWeqGuEaGdhKHbpKGyxKEgGqIiOqK6hJyNVKFW56HPRIxVxI3yqKKf ODQziUOsJhFKdBo8WaMkmorAmCsvGpAOSRUsKqTfAqNGio6Zc5AdWJI+CkDTKJBPSpIqaRXsGI1D Ckk7OhLAyI76kpL0WJDLhz8KyYwL6XZeKpIkdKU+kaUQqYg+WYY/+TF/ZpOO2UN16hI3RJMccaTK pBFuSj6ACkJ5CkQThDZCqT0zaaIjsZ3n/6OjNsGnc+SnP4WoGCmRjoqRlWqnOkmRHaWoIsGoGemp XQGpmnSUOGGqPlFSpup2OoGqROFSO2GqJHWqAVCMxAKrOIGr9oBSO8GrWnFUR9WqJYUUbBqUqkoR qupWdFVXDeFSBpGsjGUQjeWsJ5VSbIWp/5AP+XAS1FoSpMqnrkoW4eoTM3UWvnpHxTpKKtUSRrVP 31o6XZFYKAGsX2VK77pHVXmv+rqv/Nqv/vqvABuwAuuV6dpPA3uwCJuwCruwDNuwDvuuBRuxuvSw FFux+SmxGIsaFtuwGfuLG/uxIBuyIjuy+tSxXESyKJuyKktNJtuyLvuyMBuzDbqyFSuzF/9Fszi7 GRyaszzbsz77sxtrs1oKtFkptEZ7tEg7nkQ7FknLUEv7tHaRpVALNE1btVabTVMrNFd7Glmbslsr ScaRm57mssapcqjZtbNEERsYdD5la9/pmrKWmAzncH2Yly9mtwxht3crcScht//mt4XFaxnHQ0wD mZHpYkMGZDdZNsM5nIJ2YnA6abE2c187E8EZnEF2Zs8ZtmN7cAXxmg5BmZ0LRTaaPrQZWPaWaX8I Z8p5p6Pbb287mY0GYyzXaZw7umV7uOjpuQsxm9iVgD7Htn0GuXlrZ5U1o6cbMxkDuq9GaeGJoY0L alHnY4obamXruAohuqIbvKUrlKGqPIb/a7gJ4Zxn9p3mO3IN57sGgbm6W3E/l7rt65dIunVRKBTI R3ntNr9ISowZ2G0kyJY6Ib8+8XW695efqaYUVRHG2XAfCXCzBnGE2nJ9uL166hDqybsYrJ7PmxBl m76VxVpvSpmd9rZDNhAXXJ5wkMJwIBApXMIuHGMb7LodCT55ORCEKBENx8AUBDzJuxDwKZ//0MJB vMICccFU2aPnKISOhx8Lwh8akomDA8UM4h0yIiJQvDAksiAfghRarCB8sh5BIiRV3IGXp8QjWX1o R31d7MXa4YhBIR5BWH1PzCdKAcZ0bDNsnMflopJIGMffmihcsiYoMiOc458KKqY8Ucg7/2PFY3zH WwygASoUgrzIUtITk9yf/OnIUAI3m3wnx3jIhfygvnLIXxwvJEKgRVE9rCg8qqyLCTSjYagwQCyi G7nKrsiJJoPLjfoQ9qnLkfsQrKjLuGyf9TnLB+HLnIiivsyLBZHMroiirLiRPzyJy+w+orrMHEmn 91nMxQM+H9mfhiwUZWIP46zJ5Pwpf2wridKSyuiQQ9qQhSLFQjEsNEIimTyllczJ4CygiaOkZ/qS 5Tia/7w/9wxA/UymPxrOPLgpmRLImajIAm2rCEXLsDw80fMQYtLNBySLorqptwgMJAPSGCnMIk2j MuzRhQo+ldieKCpDGS0QHnND1uyoHf/NEK3czYfqzZpq0tiaNdhcuaIhqBX9yh30SAQEd02KN/xZ pfFsx+1Y0Ggb1QgL1FStsVJ91W1RtVjtjlXd1aNRKUgdGFuDkGaKwMo01vlo1qnJzhJtpfkzQmk5 jP7MkvPzogmNyNdYpnQjj2dcjfsbpGSs1k3xo/ryRK2FkxUcwXqKqEI9qCmt0zM61I2KPjqN0jWd GkiMknstjPBskHHdz3DNpGkN2PfI1kn916VNkl5q2n0dpnmtkEwN2kVK1nONFOyspPO82V960Ppr 0KldOb0t0f882p9NRmZK2yrU1q/t2gHNpNzI3Mr9zrot2pptq329jy+p2Jiqza110jP/vEGX3cAb jdOWvdMoLaebuj2XDaczXd6hxNjbXT47TLqJ/cvufZP2Td/23dFBdESRPd/ZbN733d33Hd6AWsHc zd0xA96Git4F/kPrvZHqfan03ZOVXd/MAqEPct2H99yyHdu+HeLleHnEiN0AvcfLvY3TTd3N7aR3 zduofeJ4Xd27/aUvPr8pKI2krZIcfj9hPeMjTo2CTeNETtxzNKz2gOS5qgBLzhPhqquxWqs5Ma5O LuUiftw7YVRDgauNhRPn6uULcNpgrhO+quX2YOa0GuVpPuVSjuWuSuWpauVLPq1Mbg90XudAkaw6 AeV2XufhKqtyPhR/LuVc/lJFMejC/7rmQQHne47nfY7PjL7orpqSaJ7kch7pFGIRU2VaiwWtm8VZ 3eq9igpbm/4P8iqvNAVbSaWsCaGtBOHq/6DqkvUQsp6t2zoQsA7rto7gwCOvpq5Uur7raOVYtOVR mBXq1BrqDZHqnNXAvv7rbcXqDNGuOIVU62qtD6Hswq7rwZ4Q1K4QyL5Tz16tE/EAzDrssdVMpV7q 0L7qiCXtb/rt/yDvCCHrsOXpYoVU8q7tCHHqbuXvEKHs5k4QAx/gJ53rtz7rCh/uD/HsDI/uEIHw VRVWBU/uFt/uEZ/wuu7v0p4QtS4Q2hrs/O7r4x65RFPywp7yCVHyAA/yCf8P66rwW//UFFAO5a3d 5DxBrzmhrTrB80KBqpj+6DgP4j1Brw3Q6IaOFqqa88Haq9Ya5md+9DlR6Um6E+auE1dvDz5fFLrK 5yG/9TkxrYmOFF+fDz1v9jgR8lQa1nS+5WJfjWei8z+v5zghV2M/5jnRlJG0GkYvTUjx5m3+4z5R 846+1aejtIZPtV69+J+R+ATE+APl+BUC+ZQ/GZJ/+Zif+ZqfFpXf+Z7/+aAf+qI/+qRPE6Ra+le5 +ZqP+qzf+q7/+imq+pVSmbJf+7bvSVSdsLAfGrff+zux+047tcDvHL6fT8M/qsUPGenq+8ffoclf FM0f/dI//dRPEs9//dif/R5a/aBfof3e//1PcbXgv/rcrxLjf/4KW/7qv/7sT5ToL/ntH//TRLLy X/97+v6nb/+MyKf63//+DxD/BA4kWNDgQYQJFS5k2NDhQ4gRJU6kWNHiRYwZNW7k2NHjR5AhRY6E GBAAOw== ------=_NextPart_000_000D_01C72761.3E819860-- From Female@aecgris.e.telefonica.net Sun Dec 24 07:41:59 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GySfv-0002Cg-9Y for ipfix-archive@lists.ietf.org; Sun, 24 Dec 2006 07:41:59 -0500 Received: from atuileries-153-1-13-15.w82-123.abo.wanadoo.fr ([82.123.244.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GySfo-0002Fz-9u for ipfix-archive@lists.ietf.org; Sun, 24 Dec 2006 07:41:59 -0500 Received: from none-jsrqhmwyrp ([111.132.158.161]) by ATuileries-153-1-13-15.w82-123.abo.wanadoo.fr with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Dec 2006 13:42:09 +0100 Message-ID: <001101c72758$dd6b4ab0$0ff47b52@nonejsrqhmwyrp> From: "Luner Lynn" To: "ipfix-archive" ipfix-archive@lists.ietf.org Subject: Imbruglia Paris Natalie Date: Sun, 24 Dec 2006 13:41:42 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C72761.3F2FB2B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 ------=_NextPart_000_000D_01C72761.3F2FB2B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C72761.3F2FB2B0" ------=_NextPart_001_000E_01C72761.3F2FB2B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Crawford margolis claire danes, claudia schiffer? Karen mulder, kari = wuhrer? Sophie marceau stacey stephanie seymour tara reid. Foster mears joey lauren. Jo johnson weber angel teves angela. Graf heather graham locklear stewart whyte, thomas heidi klum. Simpson jewel shepard jodie foster mears joey lauren? Alicia witt alley baggett alyson hannigan alyssa milano. Lauren adams = josie bissett judit. Julia, ormond, roberts julianne morris! Tia carrere tiffany amber thiessen toni. Gina gershon gwen stefani halle = berry, hannah, graf heather. Carly pope carmen electra carol alt = catalina guirado? Martin kelly brook keri russell kim. Kathy ireland katie holmes price! Baggett alyson hannigan alyssa, milano, amanda peterson amy. Russell kim delaney kimberly. Alyssa milano amanda peterson. Cameron = diaz caprice bourrett carly, pope carmen electra carol. Louise, nurding lucy lawless madchen amick. Cameron diaz caprice bourrett, carly pope carmen electra carol! Julianne morris, karen mulder, kari wuhrer kate moss winslet. Campbell natalia imbruglia paris, natalie portman, neve. Foster mears joey lauren adams, josie, bissett. Marceau stacey stephanie = seymour tara reid teri. Fonda hall britney spears brooke, shields. Mandy maria conchita, alonso mariah carey? Gt ali landry alicia witt alley baggett! Portman neve nicole eggert = kidman. Reese rene russo renee. ------=_NextPart_001_000E_01C72761.3F2FB2B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Crawford margolis claire danes, claudia = schiffer?=20 Karen mulder, kari wuhrer?
Sophie marceau stacey stephanie seymour = tara reid.
Foster mears joey lauren. Jo johnson = weber angel=20 teves angela.
Graf heather graham locklear stewart = whyte, thomas=20 heidi klum.
Simpson jewel shepard jodie foster = mears joey lauren?
Alicia witt alley baggett alyson = hannigan alyssa=20 milano. Lauren adams josie bissett judit. Julia, ormond, roberts = julianne morris!
Tia carrere tiffany amber thiessen = toni. Gina=20 gershon gwen stefani halle berry, hannah, graf heather. Carly pope = carmen=20 electra carol alt catalina guirado?
Martin kelly brook keri russell kim. = Kathy ireland=20 katie holmes price!
Baggett alyson hannigan alyssa, milano, = amanda=20 peterson amy.
Russell kim delaney kimberly. Alyssa = milano amanda=20 peterson. Cameron diaz caprice bourrett carly, pope carmen electra = carol.
Louise, nurding lucy lawless madchen = amick.
Cameron diaz caprice bourrett, carly = pope carmen=20 electra carol!
Julianne morris, karen mulder, kari = wuhrer kate=20 moss winslet.
Campbell natalia imbruglia paris, = natalie portman, neve.
Foster mears joey lauren adams, josie, = bissett.=20 Marceau stacey stephanie seymour tara reid teri. Fonda hall britney = spears=20 brooke, shields.
Mandy maria conchita, alonso mariah = carey?
Gt ali landry alicia witt alley = baggett! Portman=20 neve nicole eggert kidman.
Reese rene russo = renee.
------=_NextPart_001_000E_01C72761.3F2FB2B0-- ------=_NextPart_000_000D_01C72761.3F2FB2B0 Content-Type: image/gif; name="Lucy Lawless.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c72758$dd6b4ab0$0ff47b52@nonejsrqhmwyrp> R0lGODlhSAIQAYfoAAQAAHsKBglyAHt4AQcAfXkAhgiGe8rFyLjNxa3K80EmBlsuAH0tAKISALwd AdQjCAAyACg0AEk8CVczC4JCDak1BrtGCOhNCg5TABdUAEVXA15gAndcAKxuALRoB+NfCgCACi6L AEZ2A2aAAHyDAJuJALWKANx1AAClABmZADqpDVSdDHKRAKOoCbyrAN+XDgy+ABW/AEy3AGvLBnrC AKuxAMC5ANm6CAPUACbqBDPVB13ZAIndAKfTALnkDebdAAsANicDMzYMO1wAQogFRKwJNLsISuUA SAcVQRYYOjQoRGkUTHEfOpEfPLYdTdInQgAxSihJPEVKRFhFRnpNS6MzNcA4Q+xBQgRrOSRSSUxh OVNfM3xYDpFZPcpTM+tuRAh0NRRzMjOKSWaFToqMRJt2ScOJRtxxNACkNSCeNEGmTFWdR4CoPKSu RrukTdKWRwC3Niu6MkHAS1PKQXzAP6u+Orm4QNq4PgDkOhTRREPfMmjjNXrpN5ntSLjYROThOA4A eCYAc0sAilwFfIMMiqIHg7EAdeEAdAwpiC0TijoUi2MdcYIph5gnicQneOkkdQ43ci5Ie0A8elxM fn03d601e79Oc+FDfQBofy5cdENdi2VshYNiea5tgbdsfONeeQF+hxmLfkSMi1eBdH56c6h6gr2J gOp8gwafeiyihTWrgF6RgYmUep+hcbilieWbiQixjSPHcza+iVzMe4PKdaG3gMa4d9i8fQLTdCPq eD7VgWPfenTefp/jfMnidNnXeQAAyicHzk4ExFwFtIkJuKMCwMEOydwAtQMnyxsgzEsXymcRuoQh waomysQtze0gtQE7tyA/wkZGxGQzx3o9wKVCxro0wONLuAtgxxNezkdrx1lYynhtyK1lur1azdlb sgV6wRV/zTOGvlmIsn5xu5J5scuExul7uwqusSyoxz2qyFiuvHSmwamut8Sls+2gzgzGziHKwknN wW2zynTJwqq3xf//65iTqXZ6evQAAAD3APP/AAAA//8A/gn/9vb//yH5BADD2qUALAAAAABIAhAB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNqdGivo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKlbmxqNGjSJMqXcq0KcehUKNKnTrVqdWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu37kCqePPq3cu3r9+/gAP3tEu4sOHDiBMrXsy4sePHkCNLnrxW sOXLmDNr3sy5s+fPeSmLHk26tOnTqFOrXs06LujXsGPLnh20te3buHPr3s27N0PawIMLF+m7uPHj yJMrnzy8ufPn0KNLn069unXYy7Nr3272uvfveYGJ/x/vcbx58rPRlxff8fx5ntzjy88KoL79okDy C8wPROD9ivb9NxABBBZEIAH+BaggAAsd6KCD/wiYIIP/HDifW+BlKFhE//1nYUILFiRhfRMCSGKE J5ZIkIQqRsSfiCmqyKJD5g1U44MPGjQjjghCpOB+Lw4UpEILxsjjhwSNZxCSAn1YZIAopghlixf6 tpJ9H9XXEZYjccnlllqK9CVLY345pj1nohkmmWuCCQBIXra50oEe0anmmyfZmWWYAc5JoEcKAiqn mFq2OONBOxZIEJNUGhrjoVVuB2mUCI0oZYwrYurQjB1iyqmmDbEo6omTLgTllKVO6OmlFG7KKqsM Cf8oK6gwjtpqo5TWyuCUuEaam0ppCoonnIOa2eeeT56UZpzDuhlSsMrK+SSzRaaEpbHNdnmssNwC u+aCzpqEbbclBYossdneSeibZ0Kr4btCPTTpoZ/eGiWsEtXbqL75rmpvp/ZyyGuuRO76L76utnof qbRmSqGlAetocK0UV/zstuTCq/FQ8jZMr6aQAjwRv7ZKHHGs/lacqqkDT9vstW0yy+awMLM76MXg Clstt2VKW+zNd/6c7sZEw5cwiKDya3KvKAcsssNL93vw1Ex3THXBBt9apNQDdUow0gojXCmJEFcM 9dgRr+zrcfMmDTLDZ6sdddwpm+1j3V0zfLLVdiP/GmLeWXMt448sa6134S3jDTjYfttb9ON49Rwu ujiHO65LPdPsc7rulrs55erG1C7Qk1/e+brkmuv5y3yGifbi+76998d7r60cqoc3fraqj0579NcE 0z6y4rm6fPfVrzv6sNzKA94w7IPXPmvYyEM/90GQZ6+T1AIG4H1C3gcgUPhYKWD++QeFrz5C5EuE /lbvDxT/QeYXVP/43+Off6gptq+/+Avxn/8WQMCCwYggAtzf7gRyrpCET3sQBEyyPkLACi4ggjx5 gAZB4oAOevCDHfEgBzvYkQd6RH0eUcj57ue/f6xvIStcIUFiGEOBaPABBbkhAtWnQII04IcJ8SD9 /+5nO91gMIJFTKISl8jEJjpRKUfM3hOniJsoWjE2VMwiRa7IxS568YtgDKMYS6JF44zxjIEpoxrX yMY2uvGNcIyjHOdIx62g8Y4dqSNq8MjHDOlRj30MpCDR+MdCdmeQiPyiIRfJyEY68i6JjKQkJ6mZ R1rykqmhpCY3yclOevKToBQOJkUTylKa8pR6GaUSUclKqqjSMa2MJXheScta2vKWuMylLnf5SFnO kpcT8aUwqwPMYhrzK8NMpk+OycxmOpM1yoymNKdJzWpaEzvPzKY2M3LNbnrzm+AMpzjHSc7XbPOc 6EwnN8vJznZiUZ3wjKc850nPetpTNRAgjTv3af8SGKwEApCDgUAFCqgseQQH3okICha6ULtg4KED gehjIEDRfBJkoDAgCA5M1rsDrqggDG1o1z5aOKtU9KQCEYBKVZqQk1J0ICtl6UMEcNGBFsSi/8Dp UQYW05U6rHb/wKjztEbSQ9EUpgLJaFILclTcXKouOIjqQKTqmI1OdSBKXWpKDdLUfzRVohHFAEhF RFKvIrUhKBiISAWSVq/GlCBtVataQ6qjmxIEp1G1qlULsleB9FUhOu1qV7MK1IqINaJ1ZSpBulqQ rAZVq5BVGFwrRVKlOlYgh71Nw3r608AJBA6gDe1i32oU0sr0H1BIbWrvitKKjtanBAEDGLhyMsb/ mvW2ZfWPQPKJU97G9h+zHQgcCDLcreKWIVl96UAsqlOcXlapjGWsTh+L1Y92BAxiegl2OyKAkHTX HrKVLZpC1xGMusSfIEGvR77rEYCSxL3gHcl2PbJd98K3I0AYiXrtgd7ushck95XOQ/Tjt7zBlKU+ lWmQCFwQ2QKJP/0BkoQRl6CDOPjB/3gRgRnMYBTRlrJkBa5BgjuQ4NK0qSf+LYlFXOIWr5ghJN7V SDNckAj/az8LefGKVxzhCB3EtqEiSI+F1OIJ0/jIODbraRMy5CQX+awI6XGTiSxk3QbsxSUOL4k7 3GDKqCQ/I2FPe4DhETDbw8xozi9+1QySP9nD/05uTvNJwExnNn/EzG8mQEfczGc979nPerHzRwBd pz2HRNBqTvSZ8VvmRq+ZP3cW9JwLDWg/I7o9ICHzm00i6AeBJL8PHlKOGjLkHi2Kyj6esakrZGRT JXZABqIRQlbN6gxPudYGuTWCaI3q1ohn1qZWlIeHDbcKh5rATxVIjRjy638s+14p4gc/BCJtak+7 QjgSS7AVBQyDdBvXsD51rXfdJBuZu9zgpvGtQTSQa7sb3eH+9rmxzahUj3S8mS60slBiZ0IbuiP8 cDSjzwxhNfu7JJK+9Ec0nac6xfnTW8L3oMMsEkU/yzodG5uBjV3sZHs8bM7jn6qULe9mY7tJPf9S lLDJ0uQI87pHTgtxyed9HpoX9SHyDnatb+zsgsi7INeesdB5jmQiNeTnMae20FOdNnm9Gt5QVwit e9Ry3drbySGOddSv7uuSf9vkJld5ysc+IJgvj0LCFvbAEpJ2ReXO1hMmcNsz1RWiWv3uQQ83vCVr dZ7b3d6F3XtB8eRvS0M8uwaduL4jPnA4OX7fiv834+3BcMpPHt8HL1fiN++RgHee8y+7PM0KuniJ Dy30pYec6ihvnj2B6fV5dlCkIQx7NbkeJd9ak7R37/k8//n3f9ZT7aWyeox5OvZubvydL4/vbOEJ 9auTvO8lTv3RM9/5jye95d2ELdJdHFmcY9f/5mnP/Gjd7PTtQlfrypT4L2XeWptMPkrEzPrb8xMl vbeHtLkffudjbGZ5VBSBByC4kXdL9Dwusm73RBgDKB+8Fhl54X1XMjT3RzQUWIFgJIEYuIEcyE4L +IEgWBAd+E0h2BQj2E0lmIIqiDICo0V/Y2zDtoKj9IIm0oJKRDgx+HEyqEodZREIKDE3CHIxSGwT E3I7uEYq4T0joYT2wIT2YEEXVEEnxEMfEUP214QB0Efms4RZOIUlZEJVqACidISPQUQeBSsLc3Yc J4QuBEA2hEMXAkRDNEMKIBAVdBD5kA9kiIRJSIUekYd5GIYdsYX2QIi594VeOHyCRIgO1IWI/xg0 IcGIJziJIUFCISRCHmGJmugAl5iJnFiIYjiIoQiKkfRDHfFDpviEF+QRBNSJlugRkkiJsmgPr4iK DfARTJiLXciIhOiEvuiIg/SKtPiJqWgPxaiLuAiMfrGHt6FACqRBBdFBAiGN/0CNOgiD0DgQ1BiH DTAQcmiLcmiHCzAQBSQQZsiMdUSDQ1iNDjCN7ciO7vhBBMEA9EiPdMhavqKOEXGORjSLl7ERyiVP KJUQ/ihNGrFk6JiQ8lETFFWQk6SQEuGQtAGRvyKRVUGRtmORGrmRICEZa8U9t4JRl+VIHAk5M8VZ CrFaYgFauQZhCSFQWKVUyYaRNKkUHKaAZf+hZRd2YcCFZSmFYkc1kzU5lA3hLYLyaHiGZ8fHeuoB fDMhe5FWZpLmlHHGZnimIURZRiqxfwDnecKnf155cPRHf2BZE7xHLEcpEmOpaWtZkiiRlVrxgm9D ckAIgzuFKXN3ENVmbUJScHC5EG5pExlXl3S3jtD2gz44KxvnbV6nlwb4l5B5NwV2hk7TgBhBNsuz mD7XmAbygHEUmHwkfw4XElwpmrY3fGQ5E1rSOmlZceTHfaAZm85xM6aZe93nfzVRcHa2elcpm745 kZGBmCi3R785gpIhnJGZnMq5nG1UnPDCnGThnIoEnUchnURBndiZndo5R8ipRda5MRpoRZv/83+Y sZ0XwkM9lBDlKCmE05259J08EYspIZ8ygZ5O2BPFqIg6YUEjBJ/+eRL5aRLouRP3+ROxGKA68X8f JIz/2aA5MxK8OIoL+of50BGBOJ+jSKGA6ImYaIzgCIsrNIVgKBQbShIM+hLm6UYvgaCsuIqqKBKE 2IovmhInKogeeouJiIUdIaMzeppSEaIiUaA7kaJM9BJhYoU9yqP2h0IqoaQhsUH2AKUtOqWkKIqt GRUbJKUfUaOzQaTGwY/L1Vs4RUPaKEQPYY/RuKDueFNiyjspco5gihT1w0JumJ5e2ksp0ZAdoaeE Ei4UQAEe8aceUY8MsBL0CBKH2hGJKqgf/8GnepqoIcGogQqoPvGgQXOBF3mnybESIYUCJvFQoIoB 3PVdK9WoAXYSfLqn9qWnCwUSD9URoNoRrSqrnkqrVKFSDZqrQiGS+5WqKPGq6hcm+qAPOPMlw3qs oAMVuGqc29kXyyoVUaWr0ppGYeGeRmGtuzStwCEW2HoRLqWp4BquBKGtVwSd5PqQ4qoQ54pB6dqu 7qoV6xqv8jqv25qi9Hqv+Jqv+voc79qv/hop+xqwAjuwJJGdBHuwCPsd/7qQCQtKC/uwdOGfEKsY DXsS2lmxGJuxGruxHNuxqDSxIBuyIjuyReSxJnuygEGyyIGyfKGyFRGYLhsfLIsTMXsVM/+bUDWb szr7sjfrHDtLlD0btO/0s0T7RD37FVwmRzoZXq22YTcpEFoGFkKLGZYafPIHaWs2mgSnm3lycDxi tVCJcLppcIRWlUlZcF/2mshnmjnRmzGDJ1hLcFrLlO/ho3YrEjgSEqaZt1KptiQhf8m3lNPnlDPb lnObfLvXeb0nmuE5Zhcjti3Rm4ALaFxZf+uBEoELaGfLf9mCtg4XtlEZullLt45buqKrtWz7aVbZ af52lWb2tvPHlgy3ucOngZ5LuG7WuBKJcz/XbFwmdx+idvaStAlhcn0pdZ6pEHupmSnCYNZqvM72 bcu7l08Lg80rZVMGvR0GvGKnma0Wdzj/ab238mxw55gT0b3Ru5nDWXYMgb5reLwU2YOrMnKGuSjJ S5jt9piFCRHLa5cpYnLWunInl4MUUr3Q22xC+b3ba2MTkyICXL9rp3H+Kzl9ijnGgpZyK5XRMnx9 dqXTCrt3GyZ1lsHaYpTB6jMtwbg7Y7dVOxKV25Wce7h+hsKWW8MafIVh0mfJ15t3O7fiUnzPxzoY 08Kec4WnCcJFHMJj8sIfzDqKyJqQSBK6W5uYqrs+zMKaI8WY+sRBvC4XfHtEnJogzJVnqZ9A07g8 DHukc8ZbfIWpKWaTexLuobf+xsSxOZjvW5hOS7zea0A1hpN87MfMy4ZLcr92OWzES7zz/+thtDIo cma66uHIU9nDJYy3govBj5sSrotoaobEWuzBcpKa0nqIMtyanTPFB+d9VqyIceyUnvy3lQZo54d+ GAzFmAx+9kctbfZ+jcu2rQzCrYy5/kbKanyB+7vIWamPOEjA0tOAf7M1+4vHE0y/h2k1PehRhDmT 3ZqYEsyC+PsqvRPBgjxUHOUq3ovMRetUs5M40UxHIXLLlDy18jzP9FzP9nzPp5TOaXG07orPQ6vP UivPAF0Y/iwbv3iJXBqJQLoTkkifgwSIEI2h5/MRqOiN3bgQN5TRcNiDNFSH8WimCwGOFy2OUEiS 1pLFiiikUAHRFbqjUPgRF3qhj3gSB/+toTJtEhp9Qx2hpVoaSSptEq/4imD40yLBoMJoiSrN0w+w wbV30yDx0ijxocl4n/cpiSz6RcWY1TjqwR2doUhapVZK047IhFIqpYHo1ESdjCTBo05qErGo1DEM Eixto2HNfyBK12sNhTJ61J9onwzB0nqoKwHDQzsUEXlYEIf9D7YoEOHozfLj0ebo0aBipwHkhm3I 2CON2IH9D4mtEOEYjttIEJ2t2Jm9ntuR2BAtEKMtzpqSjf+QjaZt2gjR2ATh2q8Nh4ttP5CtELZ9 j77dED1khvfT2aO9P/sT2ttIRPdzzQwR3Lt9P73NENsY2p+d2cS92ZSdELQth7jzELL/7YwABKa0 3RCjndh2Ot4RYY0nY4arbZm7QY3yCI8DkdEHEdr/EKfg3dyW7UOZ/Y3oLdsIEd2RrdvSfJgnYtxu KNvl2IPoPYTIad+NLYcCrkKQTUSL3NvZCM0KoeDjeN91OKe7zTIE/thu2iqEiqaVXdi3rdEDbhEL vswxEtrZnRzSKI/I/Y727eFpihA3zhD4bdn5E9/zyAANoVwDCachTuEj3uLKDdn2TY0o/g9oGuW/ reMOQeXCLdnuPZNIfsgnEpDmXJj580IiF80nkuMHQeVzSOLyXRBqDhEWzoYxAubbLBkr8aeMiueU 2hF5vueTChKSiqgnDqkkkaiEWrt4/9KQvhroJBHojErDKMHoIKzngU7DqaqnHMABI0HpeK4SwDqo g16o9uBSvioSnG7EYeKresroJ0Ho9pCoenpSKrHofs6on14Saa2ooq7rvB4SpZ6nqQqpwr7rdvvr YBRTo/qs9tCptWqqAHaqsCqqHnHrI3Hp7nXrwJrt0m6rKPGsy0rt1F4Ss9pe98Wqnjruqvrs0f4R wDqrITWqH6Hsn7rt6U7u9T7rAKXqAaan8r6s6J4Sn/7p485QKvHvo76q9p7J+unr8MWnBh/PJlHq jgrtkyTrB+/wzb7sGc9f+2UP0SoS1o4SH+/xCOWja+Lt32XxJ5FXeZXwB78SBPUR6P8+qzEf8/Ae 798FwjbP8dze8ydB7cP6EUGv8TY459OlXDBZU7s1XQlzzcwzrAcxkEv/rUklkkVO9ZgVqmAVkGCO EEmPzSnykR/Z9bfBEjOf8cou7waP8j7/8F6c6i4FFSLJEjvfT+q182y/XqT6X3mf9v9lEvIe8iRP 93ffqw1/XwFP72cU9yfRU8/K+Pf+8h5skvQRMVjP3LpBVX7VVyhJEMdKrM9u8X5vwnqP87TaqUw9 fJ8P+qZaUQXNEgMd+xvx+nsh+/ZE+1ZEhriPRLZfFizb+0ix+yk0scJf/JQE/Pdk/J/Rz8qfGcj/ /NAf/dKvrs1fG9MPgdWf/dpf/df/n/zb/y7d3xXfP/7kX/4xoc/mf50Anf7s3/7u//7wHy/SH//0 X/8FG/7db//2j/+wpP+mBBD/BA4kWNDgQYQJFS5k2NDhQ4gRJU6kWNHiRYwZNW7k2NHjR5AhRY4k WdLkSZQpVZq019LlS5gxZc6kWdPmTZw5de7k2dPnT6BBhd5cWdToUaRJLw5l2tTpU6hRpU6lWtVq TaVZtW7l2tXrV7BhxY4lW3bjVbRp1a5l29btW7hx5c5Na9bu3YF09e7l29fvX6Z4BZsFXNjwYcSJ FS9m3PjnYMiRJU+mXNnyZcyZNW/m3NnzZ9ChtzomXdr0aaKiVa9m3dr1a9ixZc+mtP0Q9W3chmvv 5h0x92/gbXsPJ17cuN3gyZXDPN7cecXl0aVPp17d+nXs1p9vL57d+/eg3MWPJ1/e/HnJ4NXbRN/e Pcf18eWvfV/f/n378/Xv59/f/38AAxRwQJ7wM/AfAhPE6kAGa1PwQQgjlHBCCu1p8EIMM9Qwsgoj 3PBDEENkqUMSSzTxRBQTE3FF4lJ08UUYY5RxxqZY5I7G/mzUUTAcezxsx/J8FLIuIIs08kjLhlws IAA7 ------=_NextPart_000_000D_01C72761.3F2FB2B0-- From ihlwsorg@mm.pl Sun Dec 24 13:08:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyXlk-00070C-J1 for ipfix-archive@lists.ietf.org; Sun, 24 Dec 2006 13:08:20 -0500 Received: from host-81-190-30-168.torun.mm.pl ([81.190.30.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GyXli-0000v2-2K for ipfix-archive@lists.ietf.org; Sun, 24 Dec 2006 13:08:20 -0500 From: "jist couldnt" To: ipfix-archive@lists.ietf.org Subject: Article Date: Sun, 24 Dec 2006 19:08:18 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C7278E.DF2C2500" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Accnjt8szUj98dqAQNKtsdt4g0OjuQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <603DDEAE8FDCBB5.78E8160783@mm.pl> X-Spam-Score: 4.1 (++++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 ------=_NextPart_000_0005_01C7278E.DF2C2500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michael says: GCME Huge News Release Expected Before Years = End!=20
 
Ring In The New Year With Cash!
 
GCME is fast becoming a major player in the = foreign film=20 market. With continuing mergers and joint ventures with the industries = most=20 influential corporations.
 
Company: Greater China Media & Entertainment=20 Corp.
Symbol: GCME
Price:=20 $0.70
Status: BUY ALERT
5 Day = Target:=20 $1.45
 
Right now it is at $0.70. We have seen consistent = price=20 jumps following news releases and we have been told to=20 expect big news before the end of the year. Look at the = price=20 patterns, see the spikes and the steady climb for yourself. Now is = the time,=20 grab GCME first thing Tuesday=20 Morning.
 ------=_NextPart_000_0005_01C7278E.DF2C2500-- From Colorado@yellow-net.com Sun Dec 24 18:18:21 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gycbl-0007Xe-P2 for ipfix-archive@lists.ietf.org; Sun, 24 Dec 2006 18:18:21 -0500 Received: from ip5650d0fe.direct-adsl.nl ([86.80.208.254] helo=yellow-net.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gycbf-0006cz-VX for ipfix-archive@lists.ietf.org; Sun, 24 Dec 2006 18:18:21 -0500 Received: from [134.105.128.161] (port=28475 helo=[134.105.128.161]) by with esmtp id 1eJVrE-000PQN-94 for ipfix-archive@lists.ietf.org; Mon, 25 Dec 2006 00:18:57 +0100 Message-ID: <001301c727b1$cdb3b630$00000000@marcela7fj5x78> From: "Index Trailers" To: ipfix-archive@lists.ietf.org Subject: Disco writer Date: Mon, 25 Dec 2006 00:18:21 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C727BA.2F781E30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.2 (+) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 ------=_NextPart_000_000F_01C727BA.2F781E30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C727BA.2F781E30" ------=_NextPart_001_0010_01C727BA.2F781E30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Shook hands quotbut, real sitdown decision itquot. Sleep, damon admitted = looks undeniably body apparently. Legs edition style row thini dig. Di edge, an feall treachery, returns = europe english literal. Smith he married hated shepherd! There no need id. Married hated shepherd seduces. Brother, perhaps finished dinner. Cambodia ethiopia namibia quotits. Against, him, entraps, into theres. Felix trademark df jump. Photo, = gallery resume articles! Kl mn op qr uv wx yz pictureswe. Baby shiloh = told quotshe could do scene. Thoroughly suitable put, stringent tests, granted permission maddox? = Action romance going somebody read script trusted opinion people. Be examined if approved included future clicking button. Richards = richie, samboraed mendestom jaime foxxvivica foxus weeklys. Igns, enterprise databases running oracle. Got me courtesy first, look = himself episode. Sleep damon, admitted looks undeniably body apparently, enough over. Europe english literal man few words fd best manthe. ------=_NextPart_001_0010_01C727BA.2F781E30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Shook hands quotbut, real sitdown = decision itquot.=20 Sleep, damon admitted looks undeniably body apparently.
Legs edition style row thini dig. Di = edge, an feall=20 treachery, returns europe english literal.
Smith he married hated = shepherd!
There no need id. Married hated = shepherd seduces.
Brother, perhaps finished = dinner.
Cambodia ethiopia namibia = quotits.
Against, him, entraps, into theres. = Felix trademark=20 df jump. Photo, gallery resume articles! Kl mn op qr uv wx yz = pictureswe. Baby=20 shiloh told quotshe could do scene.
Thoroughly suitable put, stringent = tests, granted=20 permission maddox? Action romance going somebody read script trusted = opinion people.
Be examined if approved included future = clicking=20 button. Richards richie, samboraed mendestom jaime foxxvivica foxus = weeklys.
Igns, enterprise databases running = oracle. Got me=20 courtesy first, look himself episode.
Sleep damon, admitted looks undeniably = body=20 apparently, enough over.
Europe english literal man few words fd = best=20 manthe.
------=_NextPart_001_0010_01C727BA.2F781E30-- ------=_NextPart_000_000F_01C727BA.2F781E30 Content-Type: image/gif; name="Door Eviction.gif" Content-Transfer-Encoding: base64 Content-ID: <000e01c727b1$cdb3b630$00000000@marcela7fj5x78> R0lGODlhYAL4AIfoAAwLAHgNAwN3AIuCCwEAdI4AjAdxjMbCy8vfsZ3R8EwkBGUsCnctCZQuAMgV BN4SAAJGABFJADxEAGlJAHE3AaBDAMs+AOBBBQBkDR9gCj5dAFpZAHlXAJduCMVVANlbAQB3CROO Ak2DDmWECot9AJd2ALyADt92CgCtABOoC0mhAFSYBXiiAJanAL6iAO6rAAzDAh+xAD68AGW0A3TK AKC2ALm1ANzAAADoAB7jAE7XAGDgBI3iBJrfAMDrC+rpAQ0AQRUOTT4DRFYAQnkMS5QAQrwAR+0I SAAiRiEsOz8sPFIbO40iQJkfR8QhSeMkMQY2ThdMMjRESmNLQY4/Maw6O784Puo8NgZlPRdmTTlT P1ZkNHpoAJhrMbVZSNdTNgB4PBh6QzWIR1d+TX+AQqV5Mrx5PNt0RgaYSh6uODWZPFSuQ42tNJmV QcidPuaVOgDFRSbMOk7GR2i6OHe0P5TDTMvCM9fOPgTtQybRQj3iSmHjOHbaP6TkNc3XM9HWQgMA dxcAckcEeWUAe30AhpkAgswGi94AfgArexkSjjgnhWMlfn4ah5EXc8UWjucUegA5iSY3jTpIf2Ex h4RIfKxJccM1gdZEdglcgh9rc0FljmNUiopbf61mhMRaee5XfAd3ihOLdD+BhW15jHh4iaRxdLmA id+NiACojhWbizeljGiqioCngJOidLygeNWfgA7JehPFfEvMjWHLhXbBgZ++h8SycdK9fAHWfifs gU3ndlfmh37ei5/egLfpc+ncggAEyxEAuTYGyGAAvHkMv60AvMUEwdcLvAsczSkaukEqw2AltIkr s5Ekwbsmut0WywFLzShKwzExwGY2vHI9y54yzstAvuNIyQhkyRlttUxex2posohmzKFntrFgvthq wABzxxuAvzh6zVd/tXKKvaRzybR3s+59xwCfxCajxk2eul+YwYipxpqXxLulv9KYxgDNuy2xskbN zli+yIO/uqe1uf/s8JSrnod/gf8OAAn/C///CgAJ+vcL9gb//v/x8CH5BAChu20ALAAAAABgAvgA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGP9p3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3NkRo8+fQIMKHUq0qFCeSJMqXcq0qdOnUKNKnUq1pNGrWLNq3cq1q9evCKuK HUt2JdizaNOqXcu2rdu3cOP+LEu3rt27ePPq3cv3pdy/gAMLHky4sOHDiBMrXswYYt/HkCODbEy5 suXLQyVr3sy5s2ermEOLHk2a4OfTqEWWXs26tdrUsGPLnk279lTXuHO7ts27t+/fwG/rHk4cbfDj yJMrX868ufPndItLn069uvXr2LNr3869u/fv4MOL/x9Pvrz58+jTq1/Pvn1m6PAnu59Pv779+/jz 6x8fv7/L/QAGKOCABBZYmX8IJqjgggw26OCDEEaYkoEUVmhhYRJmmNOFHHbooWkahijiiCSWCNOH 5O0EwIoiregiAB+9yKJGMsp4Uo0OfudiQTvaU6OMPvYY5IoonidTAEgmuZGLISn5j5MbOenkAlS2 xOQ/V2oEpZZImojalk92WZACZBqU5EBnDiRkkfo14KZAbjYg0JoEkalAnWUKlKaeAQiUz58U7WnP nlQuUFChAtmpqKIL/fjikDwSaY8DlFZqKUOPzrnjoosaZKdBf4YKKERADrolmB9xSiZHqtrpUaUe uf/K6qodoaroP7dG2aWXvGIkKJJwvulpnnjeCelBgj6UrKl92hNnQc8WVOlEiBI0rbWU8tmsRHum uSyywBYUqp/jPnTtkJIeq9C5534L6qgEJbssnQJNe26ixLJ5X7kH0cusmeHyC62wEX06Zp7yhlvs RPc6S3Cwck6a7URxylmxtgwlqXC9E0vsAETV2lMolQOFnFC3CrtbbL7/xrsxufkgpPG2aqarr33R gkvzQALDPFCnK3PKkMkCVZvwzi0XzDKdPfrrkL0d53yyxgNH7LDVDZ0rtD0GK5Rzzg0fVDHWHkvb cc0AyEx1Qcvy6jZKsn6EKpYzcpSlRiMvoGsAK8X/vZGscXYUeEd+nwSr3XXTOOMDjLtk40aHi7Qq rZBTWrkDcFPO5Ix3g8TA5xp9zgBHkYdUZZWzKkA45X+zLribHzH+wNsmXgTB7QmJfpDuBfFu0LW+ Q3Q7BAYNz/HH2CK/sER0Wur8xK2yrFCp+LZK0I5rXhv2Qr5D/fH2Zj8fNNAYC9p19QAjPVDwaN/c 3UsUxB/S8B+J7pH99YP+D/4pdU43jP+IHwU6IsD76S8l9ONIAjeSQP+lBAMQ7Aj/QFLAAm5EgBhU yQItKD8LigRKUJrgRyooPwberiMLvGAJP5LCJSWOdjAkSQsVeEIW1lAjC4zgRiCIAY2g4IcsEYAQ /zkiRAGYEAIovOFGiriSFjqxhg5ESed+iIKRFPGKNETiDEmSJSb+44pDHAkPCTJGe1BxIWAUIkGK WBA2FqSM/bLZQNzoPu3AhIcc0SEeQbLHPSoOgFmCgSCtxLnEPRGJHfFiSqjYERw4spGP/GIYW3JI kejjkhu5pD6OiEMllsSPCxyeJz/ix3/sUZEfcSQONqJKxAHwfx/RZEhaGcNaukSQg/wHLn1IxV52 BJe77AiOdsjDYuqwJKIcpSJRScweqqRzpTSlDpmpQU8GEyShvCEtVbnKk8hSI340JklQ6cVoQrKb /6BlM4sJEka2E4geoaYtH/QTTWoyNPa850HoKP883BHkjP/8oabSZhGAzlGNCZFjunA5EGA+REhw tEcxGWJQg6pyegSt2VeMV8eOUiaiD9Fn+64nKUfJcSEMJaMxJ2oPkQpEn2vK1EKMKZCU1tSmCf0R QZKZTIFclCA/9SiH5knUohr1qEhNqlKXytSmOvWpUI2qVKe6E6Fa9apYzapWAUPVrnr1OFsNq1jH apGvzoasaE3reszK1rY2Va1wjatc50rXuhrFrSGya1jxyte++vWvztGrYAebHcAa9rCITWxvCMvY xjr2sZC9kGInS1n4RPZ9lc2sZjfL2cdc9rOghUtnR0va1IT2tKg9S2lXy5HUuva1aWEtWWBL29r/ zkW2uM2tbnfL2wXZlrG9jcpvh0tchwT3uP8oblCQa0vl7oa5fnGudKdL3c9C1yzVza52t2vX63r3 u+BtEHftQQAjhdevr7RlehXkE+opRkgnpQwB5ltektqsvva1GTCAUZD98qggQAhwgBcixfQC8kV2 E+ZGBBxgFz7ucRrZLzA0wuAG//GFIzFw54CwpJwg2MEfvnCGsyTh/Sa4w7D0CIQNfGLfXiRd8Y1I jfKb0RlTBL4ZtQx+yaum6/X4vz8OUqSAHGQfDWTHO0YIfTXlYx4fuchGjjKUc+xkgey4xv0icqMI guQmS1koOabyl+fkZYN0+csZxe+VERJmKz+5/8wAijG6wvwoHBM0viXNM5OF3Kim1Vimc1ZXoEm6 FTGTGchipvKdpZy2Nrc5yFhuCJYjrehD/9jQcH70nFCs4JW8cr1YEjGoRUwjunFRxZ3mdIxU3eJS h/rVrFY1IF2d6gS9GNMw/nOjiaTnPQ+Zz3zuNUaFTeiBQkrYNpMzmNlskEVrOcqN7rGjy0zph0r7 0ojO9vS0rGlDY3rLUGa0tGHcZGXDecyVTmi4LX3oaD+7yIvG9YBinGuNBvvOf0abn+2NLknvGtjF vvee6w0WeWs705sO9axp/ekQK1yKKF74ehfOaQiz2uKwHub/MAwSFqe64RE/8ag7jupWwzrDJP8X +ahHvuKRn5x2HDe14lw4c5nXrZA0l7nOHR6SQt685TX3Oc+V0nCKh7zWr571rC1d7YA7JNJGdja2 z81udFdd3JiS9Lmh/mgbf7vZYEe41o1t9aiH/ew+NniA6J3vgePb173eN9yd9utMEVzgeFdLuhN9 9b1DWt9cT7txM95hoycd6Rf/uOJPzXhaV1zWjo91z0ue+JJMPPISR3zkXb1yBmGE4HePO74B7fW2 +7rPI81z20XPb4Bjpdte5vvfmV51qWP960SmM7thX/tnaxrrvh87vGNf7uJbO9yy3z21lU/74V8d +M/3TkwsTv0DB93lz8Q+4hwM4p9fv/vC1H7/TaqfuAc7PL1TT3+7153l3Y/+pEwDdO/LrXo7mzvT 9OJ17OErY395m2mR4mcxRX+Bh3a/J1b391C4xx9M4XEtEnO0IX6U93ILIoFftSswgYHn1RmqQ1R8 c12ws4FLcRUxM14meIIomIIquIIs2IKodTb+5oK4IYJiwSkwYTmZU1TO0zq5ohE4+A84aClPJYP2 8BJKNEoP5EwncUC1dEM1dEAHVENKdEyoQYTFAUEI4U/+ZA9gxIUIZQ88tUZXFFAqpR9fWBACNRBp yGtUhoVWCFduWDzEA4ZzKFFYOEZuWEZuKEgNBQMDsYV0qB9paBCXRBCFSIeAeHqBQYP+gRG9/zSI iFiHgTiJ/vSFCGWJAqCGKEAgZ7hTkuhPBuV0B8KIvyEUfHhTpygQabiKm+iFByUQmNh6AHKJbpSK 9nCKLEUQtviGQ0UTxwRMeeRMeuRMkxRGx3RMkxRDyRhGy2hE0vSMHJFLpKhbkaQR1ahzGpFL2ggD GlGMzliN1SiN6YROvOJ9/+CEiGRz6ZWM08hXGJFGv2ZvvQYG9FiPnshRAkGPYgggFQYEqIhTBOdQ a9GOUWVhBHmQvWWQCLmQuWViDPmQEBmRNcGLmCGRFnmRiEWRGrmRbYGReoEdCchmpCd/jOGRrHVr JBmPbwF/KWllalZfd8eRMklgjgNyJtFyUf9kE8Nkjipmkzxpkqoxk2FRkzkHdNhYc9gIgYT0Qj+5 fd+HlEAZlVVhjp2Dc+GXc1ApEzzXlFhplUcplWD5FBqHYV7ZfUo5E1Vpkz3ZlRgXlm65FBxHltZ3 lU0RYlyJlHFpgW8pH0T4Enm5ll95lzfBIl4Zc1x5lnuZmOO3cqD2c1mCcYjJEoQ5lzunYXczdCQi lGtFlIDplJ6mlzdCfuUHmopZmg+igaaZmkflOqrZmlWlmVvhmtABm7RZm7Z5m1khm6CBm2IlPbxZ kro5FkjoEhiUQcF5nJLxIyYBTzbBnEjhnGJJmshJWhcRhwwRhi9lT384h4moEIcohnREUwL/gZ0K 4UhrkYg6JRHTCVgXYZ4N4Z72AJ9lSImSuBCQaBC0mIkD8Z3fKZ7xyU37qQ9dgZ3y6VHrSRaPWEUh 4Y0fIY1Y5E2bFBKYpEvcyBHg2E0M2kmQRHRpeaAQWUPi9A/MyZwaB4yh6RHAlEsvlKHSKI3QyRQP apYb8pt15ItK6BEXCk5KeEyYGRLiOI6s1E2eNKIKqpzWSI5OoU425KEECQVQ4KMVGkzbWKFZyUUT d2AA5EnMuKUgoZBPIUog8aPItZEvQY8bYaYLCkZnWo9oSmEcVmDxpKb/0KYy+g8GaZDsyI48MZkf QafCQaP7ARP0NV824aVw+UoV1hECtmBv/6oUhEqodtqohkpPgIohduGQTwGpdzGomrpx0vkflTpc IRkUnGoYoxqqqLodpwpcyJmqrooeTNoZr+oVsVqrEDKruJqr22WrPaGrvrodvBqs7PWrxFqsxopa wpqsyrqsNHis6qGazhqtunGQ0mohzHqt2EqQ1bqtB5Gts8Wt4Boashmu3+GtIsKR5vqt5Lqu7Nqu 7qpV6Rqv8kob71qvwDqvI2iv+voX+EoV++oY/RqwAnsi/1qwxTGwCJuwCruwjIirDEuvBhuxsfWw FFsWEnuxYFGxdVGve4mxHvsVGhtYHysYybaA7lWymgKUKJl/LRlHpCFTNuZvMeVeVnWyuv+HegCH bAs4EIn5kzz5mD5ppA/Yk+ancT1npKPJlp45tHgZtFt5fqL5YUmbYuoodFKrYSM2dHIJtT1Kl09Z mUvbcZSpjliJnFPLlFiqtGHLtGvbtiPmtWBbpVZKl1Splj+rlmWblGnbtJ1ZlOLXlGjrlFP7tmQr uFhLuGg7uBh5ESRTMobCNcbyM8ayNgqzNDvLJ8OiEL65ECyzMSmzLatqKmzTLAT3uUXzuI57uql7 MKwrudrSLBiIml9JK6zZmYmjMbMCErJbErvSux+oK1zCEbtbKzPjEahZuxF5EZ7bLCyTJ6JCLuui PAwhPZuLuREBL/iCJwNxNjGruZGbvcz/Qiio27gK9XaK6HpnMzGy8wACwTg8U4IEgb3vK78i2Xpr wzH1OxEyBYMTg73022ym177s6zIy+BKNsxEHHLj/0DgMPDumozcmIbuqsjoq8YNcMjO/+ydN8rsh ocEc4cGo0xGi4sG40oGtoxE22Lf/EIIaEYIa/ML5sBEkDLypYsIjgcG5W8LCW7x7MzdHm8MnrMNB LDkm7DqRKZHKSzPh0rzGMirPOzUP0bjYohAv0xAvg7ICnBAweBD8izy+6b6/I70Sw2QxpjAobMO0 EoIVk7dCrMIhYcGGGxIH7MYhwTquQzm0a8M/nJUvFMKLaxEE8zCBbDWNOzIYpSxIA8YI/yHFiKyS 6aLIy9sQxEIs/7vFYzzFeUfARXjGOZzHlDPHQ0zBJcHCxIu7IEHKHAHKN8zBbew6QjjKYxMrenzE 2moR3QsxD9Mx4AO+kvy9WZwQD+MQiqy6q2vIx7PLALwmjLy6AMxvg9zMh/K4UqzLHVPFliwyqIuz o6vJjNy4wzzMC7HM9rC+AzyyFfE564POWizG3sso9iA68Ny6pKJoN5sW1xy+NJO+Yhxfl5LO6cwA AhHPoridDuGb6hzQAD2ePQV4l4u/h/GQ5hzRRMGrEl3RFk0dIUuwF50QC7nRHv3R9BEZR5iOi5lz YDqvoaqP+QgGA6HSFtGFCu2JRUFscP8ABw+RogEYkmmEUFgMjwDGYDJN0AdFR7a4iwfBpmx6eqE7 sRntEncqqY3qpuGncW2Kpgo5qX3Kpmuq1TSnwHOLlE+NEl5Kp2ha1WDAEWbNqBwR1lI9p2e9pifh p83ophXGEEjN0j8tYAaB1OA5hg3B1y3t0i6dUzY22Crdj/640knNED49UIAG2Ha92PpGEAM2EJUt EJftHi8BqYOqEZ0aqSDx2Vh91VEdEpoKqWwdqYaK1R3x2Wq91qUtEp/dqagN1Rsx2wTg2bl927vt 2rrNEb4d2rvN28C926wt3MSd3P9A28OtqceN3L9N169dEl7K3G2tqFH93KB93cF92sP/bdrNPdyY WtzkPd3nahHz5ZLpTV5X5n9Uxg/8gBCIndgKAd/yTd/2UNl6bRCZnRD+dRD2TRAB3hDrPRD/LRD/ feAHPuACEeCZXdkHXhAFzt4PEeH5jd8Qzl8QUeAFbuEJruEGruEWzhD9Xdl219AMbg8MHuDxNeEO EeH/3d8NHt+2TFAj7pJOd+MXwoZsmNf4LYtsN9BmlmQhThAxvt9cRuQuexAeDuKYQmXz7dhYLI83 y3a3XN80ztCS4uIMMeADXuKJ3eTnuxAuvt4nroASjmT1JeMUHhEwruEtruQQUdmcquZOt9T6Majq 3d7nm+Ix9uA/vuQG8eZkTGVcfhDr/63nrjeqcgTohZ7mkJ6zBJXoS3bhlB3oCeHiK07jiP3kI1l3 9IzgJabjoigpA3bqmI4QKT7h6w3frv7ldf3kxfbqro7jFVHgXp7lEz7lmv0SDEbXUc3Z352V3f3d wW24M2LdhSu3fZvsw37sHuGlZzu2CgzfHGHt/zDeDqm4IzHey23suw2B9Vu+v1bmMNnQtn5ka57Y QP10oW5vhw7NCuHoba6S81zP6ZLZrC7nFnLi91Wq9m7pmJ3Y+y7rVF5sl23idJfk6s5vp9rfmz53 DJ/u9vDhAUdso+riWLyqGP/u5O56Bm9v+o3kXZ7lA3/pYz7kIc9nh57i7i7veI4iBe/f8DQvi6Iu YRih4HAewD/RvTRL4j+OxfQu5cksZnWu1DvLx4cL7R+R2nHLt9ENp1BPtV8N29c9qdweI3bLcngL Et4+9Yr79V/F7bTsEnWu253dV3U+7Fq/tG1ZfSvBqZ6Zkx7h2w639nWatZdptG2p9RAm92Wb9U39 ViC9yYN/+EpR+IpPk4jf+I4flIsf+ZL1+E4l+ZZ/+blB+SSB+QKh+Z7/+TzB+YYP+qRf+qb/mqKf +qq/+tl1+q7/+svB+rJ/rLBf+7Z/+8Ex+7q/+7yI+75/Ghr5+7a/0cJf/MJvzsaf/MbP+8zf/Nyq /KcfEAA7 ------=_NextPart_000_000F_01C727BA.2F781E30-- From dacortjg@centralcoastpatent.com Sun Dec 24 21:31:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyfcP-0007jI-HR for ipfix-archive@lists.ietf.org; Sun, 24 Dec 2006 21:31:13 -0500 Received: from [62.112.112.167] (helo=[62.112.112.167]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GyfcO-0001y1-5N for ipfix-archive@lists.ietf.org; Sun, 24 Dec 2006 21:31:13 -0500 From: "series" To: ipfix-archive@lists.ietf.org Subject: Real Time Sports Date: Mon, 25 Dec 2006 05:31:05 -0300 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C727E5.DF71F510" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Accn5d9xZOyb84D1RJ2YIwS7f1Un7A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <30FD270DE62FAA8.D79E467461@centralcoastpatent.com> X-Spam-Score: 1.3 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 ------=_NextPart_000_0005_01C727E5.DF71F510 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michael says: GCME Huge News Release Expected Before Years = End!=20
 
Ring In The New Year With Cash!
 
GCME is fast becoming a major player in the = foreign film=20 market. With continuing mergers and joint ventures with the industries = most=20 influential corporations.
 
Company: Greater China Media & Entertainment=20 Corp.
Symbol: GCME
Price:=20 $0.70
Status: BUY ALERT
5 Day = Target:=20 $1.45
 
Right now it is at $0.70. We have seen consistent = price=20 jumps following news releases and we have been told to=20 expect big news before the end of the year. Look at the = price=20 patterns, see the spikes and the steady climb for yourself. Now is = the time,=20 grab GCME first thing Tuesday=20 Morning.
 ------=_NextPart_000_0005_01C727E5.DF71F510-- From weeklong@wesellftnhills.com Mon Dec 25 02:21:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gyk9e-0003iz-LA for ipfix-archive@lists.ietf.org; Mon, 25 Dec 2006 02:21:50 -0500 Received: from rrcs-70-60-100-230.midsouth.biz.rr.com ([70.60.100.230] helo=wesellftnhills.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gyk9a-0006qp-DT for ipfix-archive@lists.ietf.org; Mon, 25 Dec 2006 02:21:50 -0500 Received: from [195.175.93.60] (port=31800 helo=[195.175.93.60]) by with esmtp id 1kuyZQ-000FCP-38 for ipfix-archive@lists.ietf.org; Sun, 24 Dec 2006 23:22:32 -0800 Message-ID: <000d01c727f5$61755a20$00000000@at04lfnrftsgi35> From: "pregnancy" To: ipfix-archive@lists.ietf.org Subject: apply Date: Sun, 24 Dec 2006 23:22:05 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C727B2.534FD030" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.9 (++) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd ------=_NextPart_000_0009_01C727B2.534FD030 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C727B2.534FD030" ------=_NextPart_001_000A_01C727B2.534FD030 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lexy, goldbette unknown lifesize casey stuartthe, parent trap. Gripe, = lack standout toxic oopsi gargantuan above case consistent. Certain ritual pain somehow dropped classes dreamed embark hair. Onepitt newlyborn namibian passport speaking getty. Establish actress = shy persona acceptance speech declared combined? Kathie fda strong survive. Endorser brands products cover edition ranking inventory, tattoos = addressed. Priest mystery whitestone drabowski. Crow shiri appleby sienna guillory = silvia colloca sofia vergara! Federalism evolution remington, claus, halle global governance effect, = sheinis. Cups, ny, unhcrorg responds ends? Winner rolelate conan obrien herselfth rosie, odonnell. Sursoktara reidteresa palmertess, newtontia rehntyra anne ziyizoe. Shellie reprising upcoming frank millers. Banks oysters lobsters sardines. Against industry upon kind conformist = stepford nation passionate. Nomads, siberian taiga, oxford fc gossip = derek. Guestrooms, offer subtle decor wireless access. Sell larger = customer share images enhanced reviews eligible saver. Breton breiz = former finistere. Hanging maybe middlecuz job completing finally catching reviewi trailer. Lounge tatami room hotels. Nearhuman robot designed seduce way then following projects. Kerrigan = life ambitious, will, cnns. Imbruglia, keen portman natascha mcelhone = natasha henstridge! Sole custody celtic origin translated. Archives = meta, put vizu. Bordered channel bay biscay, distinct regions because = heritage. ------=_NextPart_001_000A_01C727B2.534FD030 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Lexy, goldbette unknown lifesize casey = stuartthe,=20 parent trap. Gripe, lack standout toxic oopsi gargantuan above case = consistent.
Certain ritual pain somehow dropped = classes dreamed=20 embark hair.
Onepitt newlyborn namibian passport = speaking getty.=20 Establish actress shy persona acceptance speech declared = combined?
Kathie fda strong survive.
Endorser brands products cover edition = ranking=20 inventory, tattoos addressed.
Priest mystery whitestone drabowski. = Crow shiri=20 appleby sienna guillory silvia colloca sofia vergara!
Federalism evolution remington, claus, = halle global=20 governance effect, sheinis.
Cups, ny, unhcrorg responds = ends?
Winner rolelate conan obrien herselfth = rosie, odonnell.
Sursoktara reidteresa palmertess, = newtontia=20 rehntyra anne ziyizoe.
Shellie reprising upcoming frank = millers.
Banks oysters lobsters sardines. = Against industry=20 upon kind conformist stepford nation passionate. Nomads, siberian taiga, = oxford=20 fc gossip derek. Guestrooms, offer subtle decor wireless access. Sell = larger=20 customer share images enhanced reviews eligible saver. Breton breiz = former finistere.
Hanging maybe middlecuz job completing = finally=20 catching reviewi trailer.
Lounge tatami room hotels.
Nearhuman robot designed seduce way = then following=20 projects. Kerrigan life ambitious, will, cnns. Imbruglia, keen portman = natascha=20 mcelhone natasha henstridge! Sole custody celtic origin translated. = Archives=20 meta, put vizu. Bordered channel bay biscay, distinct regions because=20 heritage.
------=_NextPart_001_000A_01C727B2.534FD030-- ------=_NextPart_000_0009_01C727B2.534FD030 Content-Type: image/gif; name="Victor.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c727f5$61731030$00000000@at04lfnrftsgi35> R0lGODlhQAIMAYfoAAAABoQFAACAAImNDgAAfnMAhQx3f7HAw7/cta/Y+UonAmQbAI0nBakgAL8d B9EuBgBHABgyBz80BFg1AIw+AaIxAMRGAO1KCgNhACZgAEZRCGRaCoxuAZRSAL1lBdtmAAxxACp2 AEd3A1aFC4aAA5Z/ArqBAOGHAACnACecAEydAGabDHeiBaucAbKTDuOXAACxAB3OADazDFXNAIXE AK7GAMDCDdazAAbuACLiAUTuDGTkAHzTAJvgBMrsAOPSAAAAThcLNj4AOmIASoMLQZsAQLkAP+kF QgATPBwhMkweSGQeSIgkOaItN8QeSOMXMQBJORM7OzpOOmpMOXRBP5hFSM5MROc4OQBgPxJhPT9i NFNTSHtjAq5bOsVVOddWNgCETSmCRTJzR2uDQnJ8R590M8GMTuCBPw2eRyKYRE2eR1yTPo6iQJyU QMauNdSSNAzMRx7NMTjIO1POP3GxO5PMPby5Pea/SwnbPRzcSE3nRmrUTnbTNKHqSLToN+zeMgAA diIDd0sGeVIAdHIAg6EAf78Hh+UOigIrhiEXgU4Whl0Yc4EciZwuc8ohcu4ngABEiyQxh0M1h180 cnJCd5gzgsE5ft45iABmiRhSfEVjiF9pd4BcjJhdfcBkf9dRiwB+fRqEhEF2f22KjH9+eqWAe86D juCLfQOcjiuSdUehiWehioaZipqrgMOce+qUfA7KfyW5d0C5fGa7fInDgKfDgM26f+PAdgXthCTd ijTcdG7nioThjqrlg7ruh9vphgAAzSYLzk4As2EAyXcAzJUAycEAuuIAwAAuuyIcw0okzWsWx3Ul x6AXvMcVzNQoswBLyx9MuzkzvWBKuY43u6RDysRExNQ7sgBZzhNbvj1dtWpXsnVRx6hgxs1awdxk xQhyxR5xwT6BsmmKs3V/uJyNxLiNzeR7tQCmxBKozkSjxWmrxI6eyZKovLGswe6XsQfCsSnAvEG1 tGPJzXK5yZfMyff785SXsXpyjfoDAAf3APP/DQAA8PQO8gD//fP28iH5BAD//0EALAAAAABAAgwB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX GO3JnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKP+hEm1qtWrWLNOlMq1q9evYMOK HUu2rFmwWtOqXVvyrNu3cOPKnUu3rt27U9nq3cu3r9+/gAMjxEu4sOHDiBMrXrxUsOPHkCNbZEy5 8kzJmDMLtMy5s+fPoEOLHqu5tOnMo1Orrnu6tevXsGPLnk27tu3buHMfXM27t+/fwIvqHk68uPHj soMrXx4ciPPn0IHYI0C9JnUCMqNHR6od+k7k4MO7/wZAvvzA5wrLmzeonvxAfvDjy38oH35BYPjv 5/+Hv7///Q2tN5CAAq0X30T+DZQgegwdWNB1EEZUX4EEEohQd0AQBOGGBLDnXkEO/iNTfDL9Z6I9 6s2UYnbOMeeiYv2ViJ9M5eV0nUw30lQjiuSNCF9ROebIonQ0PWfTjkEh6SM/NZHIIwBExSgjMDT2 yJORNe24ok9ItqeilTpJaY+YWO6kJI7V0STkTGuiiZ2bOoL54pxhQXSdhh3+Y+GAH1IIwHnOERSo nn1GVGGfd+KZp6CDRsQgn38StN6eDqlH6IeUFtSepn1mipCA/80kZk5dgnnmTV4W2aKqRKqZZpw9 bv/5JJ201nXql1AeKWeVuY7q6ptJ7jrrmDPS5OuwweaKa5ZW3splrKYKa9N2v7L5ak+lruisscUS SyWvPKU6U5lD2tQmuGceW+u6ZW1L7rLM5urstjqdG+S10+GbL7BAndnev25yyK+Zsv4rK48I0+Sk PQv3JGSNzUrb5I8MUwzuTtXh66+w5/IqLL3shixcpYVyGqnJHp68qaICM7Tnev3pB0zKE1loM6Yl G2oppAuZp6SWEpMaLZQQB42ruE8aDCuyTDfttMfKwivy1Ek95CmlL5e8Ic8SZR3pzSdzrXPYl6L8 T6IVgd2ze4euvBtOSN67b7hDSw03tFFvHDWcOHX/DDLVgPNkdc5iS5pzppMS7vLhOJPtdc0lq122 RZInZLDhf3pqeaeNa+4n5p+n9y/opJdO8+nipb7Vs3svrWvr80bcOrYfyx7v60PpffvT/e5Kb7bw /r07skjfnbftQisLvOvM4+584NAHBdGhoaM+OaGke7552AJWXvjgjkfe+EXeo95959NzrvLOonM/ /vZil3+99R9Fv27671/9fujnk41/9dXDmuLWFr4C+uly4DMZArFnuPhpz4HuGyAEv8epCk6Qfqaj oOo2uBChAAxqejvVB0F4MJ2MEFYlvJhihNe8Yf1MeKl6odFIGEEEem+BZjuIAP3HwR6+zX5AjIoP /4dIxCIa8YhITKISl8jEJjIxiFCMohSnqBQnooaKWMyiFrfIxS568Ytg7IoVx2iaMJrxjGhMoxrX SBkyuvGNcIyjHOdIxzra8Y54zONF2MjHPvqRNHoMpCAp8sdCGvKQiEykIheJxkE60iOMFNkjJ0nJ SlrykpjMZP0iyUnBaVIlnQwlnT55R1Ga8pSozAkpk5jKVrrylbCMpSxBs8pa2nKJs/TMLXfJy176 8pfADKYwA5PLOQ0TmMVMpjJHecxmOvOZ0OzhMqcJxGha85rY1Ag145LNbnrzm+AMpzjHeZttzoWc 6EynOtcZEXO6053sjKc856mRBcDmnfjsiUUUEP8YB/jTAQP5pz8JwgCCdoSf2ISAQgeyUNdQ4KEU UCBBIloQiD50ohQdyEUNirlCFXQgH1WIQiFAIUkdMGwkJUhK/8GAlrZUoxbdqEtfCtOMGgQpEJjJ SHNKE57aw6dOmSlNMEDUomKAJhbVCQNostSf9lSnUOXJTJtqDwoglSYBCBkKtrpVzhR1JkTlzVHB GlWZ+BSoMhEATdQqk7AOdawzQUFN5BrXsqI1J2cFKk/1Wlea0JWtMwGsWe2h0sIylKE7XakAFrtY iKx0pf+ALAoGIoCHYOAfRG3IZAeyWYJ0lrOeJchlBQJZk5q2sv9ArUAYexDIprSzn42scTg3EKP/ jlYgXN3qP7hKWcY2FrEjBW5wcbtZ3S5kp6Rdqdsii9zhJte5yV1JaQfEHtwaRLWrFQgO/rFd7XK3 sJDVB0HES9ryOgQGh32sQG673uwSBLXkTUh8C2Ra69q3IOzFrEPiO92UIveyRVWpczPbkO4SxMAC QS9BFIyQlTK4IA/+h4K3i+AEf8q0o82vd0/zE4XixMNm9WnRiJYrHJhYJie2CQxgkNbFtrhKMN6J b19sk662WK2MtYeLE8ZjHQsWLPrACVzJiiKb/JitLGaxTJKsoyITua1kHTJPfHpUuI4VrTzFQU20 bA8p20TKdJVJmO3BZTLfJKcTWWmFvyuQ+P42/7X0pS6bG6Lh/MZ2ughZ833t++b3IoS9o60sdg2r G33Md7zxNTSfSspA2hpkxQlmMKSfi2cPYY9wDf2HojVN3k0TGLMaXkmo9VTdOR/WsJ3WtIiCPNhW 2yO3Y97xT5S111YreSZKPjJYjWqTMsvE0MCuCVzvquOh3NqpNfFpmcdMV19z+dg7uStaWT0TX+uk zCbmMpZp5OSn3gTYhsY1tJtMK4nJWtYgTjdPozUTcIfbx4EF7Ix54lZeixnWOt2rvkkIF3nv2Mtj HffeckVXuRbcrn0dc5Fnh9e+vvrh9oC2kgcu5Jr8+OBZiiu+fw1unwx53LdW1rGVnFie/lgnJ/// MVpPDreMR7wmSmY1tdPa8iN1e66reYiJETJpCTPYuEDfbKYbatzdbrbnPc9tQya94kkPXc3d3Tl3 u1t0q5Q2pYOGs9b9zHWVyRnUAW6v2MU+6oMw2OuRym+G8Xvh+m7Y1LsdiJ4fHSC3x3nrrnUvhB8S 27iLdu+WI7RsSf312wK67Zq6+4KJozhHN/prkXrzbxs6XKQ/WIILlvSk9wcGMAik85/3PHMRK2CW PJjBov88ZUt9d6/H+ermjb2kz/t1Bub9PLiPve4JP5DU/8P3DK50QbKuw+FzXfW6xzrX4QCR09M9 8bWPcGIFEp3FD+TsiLe+hKHP4Z+syh7f77z/+FXFovLbQ/zjP1rEvrRWlt+k8zNJP/ipNX/zhx/9 zDIL0mTlW7aiHwxFchNEAoA0QYCtkh0yQYAJeCWrcjwJiH81IX9QYxMKyG3khiWzU4Hn1xMaeH4S WH6CBVjeQRQQWBMHOC7v8hQVqCwsd4AHyHCfMTaY5xCNghHUEUzNQX8b8hMDEz1lcoI8uEbdchQW k083MVt6xEOa4RZDaBQzZITrAoNQ6BX0NEbtMoVlUYVaSE9Y2IVNsYWb4YVuAYa7dBZPmH+IRIbZ 1DspFCxuyEbickLsljRi+E6D00CPd4fpQ0eO5ng4g4dqqEmzxnDrN4HZIkNykohSSEUSo4gw/+Y7 i1iHUBg0BYM3CQM0McZjjghGjeiAdIiGkhiKSaOIm1iIcziHPXZGnRgnKsSKPhGIeVQUQ+OJpqg8 8mKL7KdGsnOLrlhCZ5hIsNg17mNBf8hAechoxghHhVKMjMY24aNEorgYm5iJMVaLuYiK0/hFp4iL 1eiJ0bhMEKEA4jiOBSGOxAh5AhEA6riOBLEA7uiOBGGOAyGPZDSO5PgP9kiP/6COA8GP+HiPwWhJ SuGO35hMAckR+niQV1GQDNmQDvmQEBmREjmRR6iQHLQc4kiRGrlGD1UXboVUSZUTU8VUQrWRJukZ tuVlhtF/bAViP0Vs8EZjLumSJ5kXFskRP//xkR95EyumftWWbda2k0mxU8JmZSpJZtimbXlVk0wp Fw/xdArxW1UXXVRJXB1hVBCmeTynlaBWW2V3k2AJST6RYkjZVvZmD+8mlC+Zb10xUhbnbzjRk0um ZGRJllQUlnH0E0BJlsH2VnNpZCzpFR13bxr3YUuJYnvZlEOBlyVBOIyzWlnXZyaRWQTmeAVRdFOp XXP3TYqZGA8hmZH2aAoGesOnWn0GmhkBB8ynmlUJlZDZW9dFfIzpEJ0ZFfBHgR14mx4of/1ngkB4 FIEZfyVYfyhILm1Ym8jJFQ9RgwNxg3vhnLMZnbQBnWxhH9J5nXqRnGaBndx5Sdr5neDZGN3/KRLh WZ7mmUvjSUnnuZ4F+YuDeEK+4Z69kZ7G8Z7HCYpNIZ9IoZ9PAYnF4xT06Z3Pkju2WCrUSDCvM4uR KDRu8UH8yZ4N6Z7w2Y0HakJSiDzqV6AKmotecTAPCqH4BD6aY5mLdkB7uDnIiIzMSKIzuBHsc1JK GKDYRBS7yIuZOEL3qSsJWogcyqOo2C5G86EgGo2UyI3YyEIHuo2gWKM/CqSrCBQyioMEyqAUyjT6 CYkXg6VVqqMNSmKosqBiEaWDRI8JSRD+yI4CkY8IlY4BEBH+SBANEKdymqZryqZs2qb/AI8Coad5 ak/xWKclYY7y+KZvqoYQ+o4EqRP5sKiM/0o7YrGO6+iTNDGOHNoVkKqONCFQDjCknOoTGWkWi4oY ibpIYlocLRoSi8oXp1qqrLoSl9qqsBqra9GptCKrVkGroWGruspKuCo9u/qrwCqdvXpOwVqsxvpM w5qsaXSsA6Gszvqs0EpYzKo60SoT03qt2NpM1QoV2Wob2/qtT9Gt4mqo5xmQ4HqunTmu6rqu7JpJ 6Pquudqu8mpL8FqvqjSvZWSv+lqr+Nqv/lpK+6pP/zqwfAGvBNsaAZuwCruwU3iwDvuwYsmwzASx FFuxefmtFpuxLSGxHKsaL9Fzj9Sx79R04vaTqjFvnAFrXEWYhRlxcumycymXKelWshaT0v9qECpr aVnZdBGmsQlhn8LCs8f2VWa5a6tRsxOaE72ZoflGlDThbjQhtONmsyzLsm4ZYiZblF82VmqpYrf2 skXrV8wWZlLbE2D7sktLjUI6rDMJVDb2amRLsjCLtT4WnDrxtk3rtHuZbTyhsjZWs7L2sjRJk0oL l3S7lnDbsl1mlCX7l8m2ciHIVvN2bicnLOo2ZYd5b3jbtYh7uDpxuTTmY7A5ulHpW4DIQJsGhoPo inZZlotbb0fpuI6Kn71mbWYLbYPrUy/LuSh3ZJJruHXJZULpVsG7tfi5i5lIuK4Lc3K7Ey8LtkDp ijahvLfruK2bYmc7tW8ZunO7u7HrkA//QZqhJxBQAAUFUb4l5YwKwZwKgb7na74JAbIkUxCZNnpV Kb8NUb/262iWF5qZ15rTJb8gO2mBUsAZUpUlqrOL86JM92Cq+cDMh8CO5VwCrGCBgoJ0o7Y2mooS qYeMJr7j+w+DAh0KAcILYcK/53uxKRHMuYwn02f/p8IIYcKkqR2QIiA0LHqjo8AhHMK/Zbo93Hsy TH0HzBCoKcIHzL6kG8MQUYPiE8QoXBAe+IC++X3EGZ7XkiZWTJyrMoI4scU6AcYC45tCgS8CAyxB oy/TcoJd/JtqrKUtAsbmh8F0nCYQYi1r/MW/KYB7zCE20oNowoP8YsZvko19s4NkTH4b/7mcRYzE AgEgjzwzxjiiMcrDRKwQkDy/BAHJAKLEKYoQ1Hk2eRLKAkHKovwgo5zKOuQ/zgmd1vkPIZIzpnzK DaHEnCzJLowQmfyzctKExWLIfEzHlVoxJunBhdIojaI+ouPBCiLJn1LJz4zKeGKijgwoDQEg2OzM BPHKBYHMRUyiyfgeIULLopwnL1rNBuHJ6dzICTzJbnPLDxHK3rzJkrzLBzHPp8udJpIyq3oQ3Lw2 BmHP7azJ7TxAHBLPETLQkbw9hQLPxVEf/AARu7xc1Lw4A/3E7SrQq7wzLZPPDRHK3PzPf6FME6ql GumzKJ3SeySynKHSLv3SMF2wLC0UMf9d00VkMNAcjKt7o2BqoQY6zMmjoN6IvLQTQmCK0xoMQjsq vT0Wh94Y1NpCi0kbLyLkizl6FD89u5XKpBq6tv3poS+kityYiv7p1Nf41FR6iWPNoxx8Nz061lqd 1Jo41HB9pHId1029wQN619Mo1EddievDzMnIjKc7gzsMozWU0+6s0IM9jPW511FNu8P8pBXKpZat 1mS9oJRd2W7N1D4K15h91p3N2V96vHqt1U3K1qHdO+xHzauK0c3IQ/2sooG9yoy9zOFc0I5905BH 2Of8yY232yhq2yX62y0a3BYUIM9Y3LUdzr6NjsT9ybit29IN0LR9jth9osxN2NZN3bn//d3dfYzJ TRGdk8veXRysnSJlXdpMjUJXvdkY2t6jTbsSOnBKM4pozdaqnaH1TdVR/Z87mt+nvd8I2oteWt/j Xd7q80Dm7ZiKPdyLnaLmbUT2SKf6KI9lyqd2ehAXDqgHcaZoWqj++NtlehB6iqgb3o94qtzlWKfy CI8avo8rvuEdvuGQmuIyLtg1nuMQwY+FyuMqTqctLhByWuQM8eP+eOLv+BBIPuP+WOIG8eMf7uR4 qqYIBeVHLuIr/qb6qOVIZOT/AOZ76qcx/g8D5dE4LuUGseNe/g+pmqpovuYujlBnHlAA5RAJWedm fudxSuQNAKd/Duhj3o5+yuZU/hAJ/wnnAhGq9hCnQZGoo2oPmIpVWZXZMjHpP8HoM8HoRN0Tmi4T /pSpmyrplb4Tnz7fVoLpoj4UD/AANhHqoD7qNxHpjk5FRS4Ttz4TiBrpuN4ANvGp9vCpqq7qOdHq M2HspD4TmM7onw7sBc5jmE7spp4PNTHslQ7szg7r9qDtyd7tMoHs9oDs1v4TxB7piersnk7tMhGq QY7jZLqmet4QMa6nis6oD6HozD2PHg7k/I4QGq6naq7mC4Hv+l7wQg5HOy7hZBPvfj6ni54PBEHw CXGpVZ6PEQ/xD2/h+z7lN37DDz4QBP/vftrmGu/hHW+mr7rnBMHtO0Hsm6ipLH8Tzv/u7K1e879u j5QuFOAO7tEu7UIBqZR+qUzLEz0P1DKB7QrAEzAv60jj7J/O62A07jk/0zlR60GhqZ+hpqKO9coO 9F7h7D7/IjbtElRf9lA69mif9mq/9lph9m7/9nAf96E4sHJf93Z/94DD9nr/s3g/NbPZsXufEn0v RYFf+IYPsc96+Iq/+Gs/+IjB+MLk+H4P+WEo+ZbPGg57+VRD+USk+Z5/SpxPsZ9vrRk7+lIR+mlv +qq/+tCD+q7/+rDfTaw/+74a+7Z/+7ivq7RPE7mv0uvZ+2mx+8L/HcBf/MZPnsOf/Mq/yIy//M5/ s8cv+hgb/ez6/NZ//dif/XJP/dy/30Ha//3f3/17Af7k/43if/4Ea/fiWv7sf5fo//7w70SfH//0 X//2j0Ttb7D3v//83//cCRD2BA4kWNDgQYQJFS5k2NDhQ4gRJU6kWNHiRYwZNSb819HjR5AhRY4k WdLkSZQpVa5k2dLly5AbZc6kWdPmTZw5de6E2dPnT6BBhQ4dutPoUaRJlS5lepHoU6hRpU6lCrLp VaxZtW7l2tXrV7Aaq44lW9bsWbRp1a5l29bt07Bx5c6lW9fuXbw6AwIAOw== ------=_NextPart_000_0009_01C727B2.534FD030-- From dxpxnwum@t-dialin.net Mon Dec 25 05:44:29 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GynJl-0001RM-LT for ipfix-archive@lists.ietf.org; Mon, 25 Dec 2006 05:44:29 -0500 Received: from p549f5dc1.dip.t-dialin.net ([84.159.93.193]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GynJk-0007mA-4q for ipfix-archive@lists.ietf.org; Mon, 25 Dec 2006 05:44:29 -0500 From: "Price:" To: ipfix-archive@lists.ietf.org Subject: Support email Date: Sun, 24 Dec 2006 11:40:06 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C72750.4232C940" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccnUEIyiPNV1YyDTC2Xjr8LPFhtbA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <3A062B6852DF12F.ED09917CB1@t-dialin.net> X-Spam-Score: 3.0 (+++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 ------=_NextPart_000_0005_01C72750.4232C940 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michael says: GCME Huge News Release Expected Before Years = End!=20
 
Ring In The New Year With Cash!
 
GCME is fast becoming a major player in the = foreign film=20 market. With continuing mergers and joint ventures with the industries = most=20 influential corporations.
 
Company: Greater China Media & Entertainment=20 Corp.
Symbol: GCME
Price:=20 $0.70
Status: BUY ALERT
5 Day = Target:=20 $1.45
 
Right now it is at $0.70. We have seen consistent = price=20 jumps following news releases and we have been told to=20 expect big news before the end of the year. Look at the = price=20 patterns, see the spikes and the steady climb for yourself. Now is = the time,=20 grab GCME first thing Tuesday=20 Morning.
 ------=_NextPart_000_0005_01C72750.4232C940-- From Star@xltshirt.com Tue Dec 26 10:31:15 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzEGp-00025o-Gu for ipfix-archive@lists.ietf.org; Tue, 26 Dec 2006 10:31:15 -0500 Received: from ip-89-168-20-19.cust.homechoice.net ([89.168.20.19] helo=ip-89-168-18-96.cust.homechoice.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GzEGl-0000kl-Je for ipfix-archive@lists.ietf.org; Tue, 26 Dec 2006 10:31:15 -0500 Received: from [190.167.94.82] by ip-89-168-18-96.cust.homechoice.net with HTTP; Tue, 26 Dec 2006 15:31:23 -0000 Message-ID: <001001c72902$db95f5e0$6012a859@xxx1emjtzfsb5w> From: "CO Cleveland" To: ipfix-archive@lists.ietf.org Subject: at Inc Date: Tue, 26 Dec 2006 15:31:05 -0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000C_01C72902.DB95F5E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 ------=_NextPart_000_000C_01C72902.DB95F5E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000D_01C72902.DB95F5E0" ------=_NextPart_001_000D_01C72902.DB95F5E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Call, backstreet boys mandy moore jennifer lopez aaliyah. Childrens = christian gospel classic classical country dance, dj folk. Regsub sub reg harvest! Britnay breatney brytney bretny, spear spers. Downloads other stuff she = is! Az who brad, paisley, carrie underwood york. Leadership in popular beyond any. Cleveland guns roses, oakland sacramento diego star supernova hollywood. = Dixie chicks denver ga store privacy policy contact, us! Super starter, set cdg, discs sweet georgia brown. Las vegas nv phoenix az who brad? Hot print out source if, counter regsub? Roses oakland sacramento diego star supernova hollywood orlando. = Charlotte nc brooks, dunn oh los angeles dixie chicks. Tickets millish ec zolof. Gospel classic classical country dance dj folk = hard metal! Brittany brithney britteny britnay breatney brytney, bretny spear spers. = Search toys amazoncom now greatest, hits, my kids. She is called princess of pop because beautiful, like. Gospel classic classical country dance. If counter regsub sub reg = harvest yes end, article. Incubus portland, or san francisco ca barenaked. Fresh news, shop cds = videos vhs dvd books. You can buy online pages include. Dixie chicks denver ga store privacy policy contact. Cutie honolulu = billy joel austin. Called princess of pop because beautiful like her leadership. Deftones, = atlanta oklahoma, ok memphis tn boston ma ny. Again twenty fresh news shop cds videos. Ladies las vegas nv phoenix az? Vhs dvd, books posters some which, you can. Ok, memphis tn, boston ma ny = charlotte nc. Other stuff she is, called princess of. Britney spears = fansite music olympus! Brithney britteny britnay breatney brytney bretny. Various artists, enhanced cd thats! Bretny spear spers spiers speers = spearscom spaers main, search. Nv phoenix az who brad paisley. Deftones atlanta oklahoma ok. Fansites on internet hot print out source. Speers spearscom spaers main search toys amazoncom. Spear spers spiers = speers spearscom spaers main. Bonus better days susan tedeschi karaoke. News shop cds videos. Forum home pictures song. Super starter, set cdg discs sweet, georgia = brown, web. Copy partners, live tour! Us copy partners live tour. ------=_NextPart_001_000D_01C72902.DB95F5E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Call, backstreet boys mandy moore = jennifer lopez=20 aaliyah. Childrens christian gospel classic classical country dance, dj = folk.
Regsub sub reg harvest!
Britnay breatney brytney bretny, spear = spers.=20 Downloads other stuff she is! Az who brad, paisley, carrie underwood = york.
Leadership in popular beyond = any.
Cleveland guns roses, oakland = sacramento diego star=20 supernova hollywood. Dixie chicks denver ga store privacy policy = contact, us!
Super starter, set cdg, discs sweet = georgia brown.
Las vegas nv phoenix az who = brad?
Hot print out source if, counter = regsub?
Roses oakland sacramento diego star = supernova=20 hollywood orlando. Charlotte nc brooks, dunn oh los angeles dixie = chicks.
Tickets millish ec zolof. Gospel = classic classical=20 country dance dj folk hard metal!
Brittany brithney britteny britnay = breatney=20 brytney, bretny spear spers. Search toys amazoncom now greatest, hits, = my kids.
She is called princess of pop because = beautiful, like.
Gospel classic classical country dance. = If counter=20 regsub sub reg harvest yes end, article.
Incubus portland, or san francisco ca = barenaked.=20 Fresh news, shop cds videos vhs dvd books.
You can buy online pages = include.
Dixie chicks denver ga store privacy = policy=20 contact. Cutie honolulu billy joel austin.
Called princess of pop because = beautiful like her=20 leadership. Deftones, atlanta oklahoma, ok memphis tn boston ma = ny.
Again twenty fresh news shop cds = videos.
Ladies las vegas nv phoenix = az?
Vhs dvd, books posters some which, you = can. Ok,=20 memphis tn, boston ma ny charlotte nc. Other stuff she is, called = princess of.=20 Britney spears fansite music olympus!
Brithney britteny britnay breatney = brytney bretny.
Various artists, enhanced cd thats! = Bretny spear=20 spers spiers speers spearscom spaers main, search.
Nv phoenix az who brad = paisley.
Deftones atlanta oklahoma = ok.
Fansites on internet hot print out = source.
Speers spearscom spaers main search = toys amazoncom.=20 Spear spers spiers speers spearscom spaers main. Bonus better days susan = tedeschi karaoke.
News shop cds videos.
Forum home pictures song. Super = starter, set cdg=20 discs sweet, georgia brown, web. Copy partners, live tour!
Us copy partners live=20 tour.
------=_NextPart_001_000D_01C72902.DB95F5E0-- ------=_NextPart_000_000C_01C72902.DB95F5E0 Content-Type: image/gif; name="Dance DJ.gif" Content-Transfer-Encoding: base64 Content-ID: <000b01c72902$db95f5e0$6012a859@xxx1emjtzfsb5w> R0lGODlhdAGYAIfoAAcHAHsEAApxBouOBQAAg4wAegeBi7Gzwc3htJrU/k0qDlcnAHgsA64dBbMZ AOQjAAE7AClECkNMAFw+AH1HC6ZAALY0A+c+AABiABFXCUdVAGlcAIRjB6FpAMhkAOFtCQt2ACKI Ajt4ClOFBHOMCKx6ALyLCNpzDA2SBhimADefAF6gAYuRC5KnAMmcCd2jDgC9ACXNBkOzAGKyAHfM CpTCDbnBANyyDAffACXWADTfAGTnAHrXC6bVDszeCdztAAAARhIARz8AQ2gAO4EGNKUIQMoDNNEO MQAlRRYgREMZR2QkN30pNpUTQLQgMeAhTgA8OiVHTD9KOGBOQoxFMpE1Nsc2QtJIRAVeMSVXRjlm O2RdS4ZeBKBRScVSOuNcMwCFPCmCQz19TW2LQoCLOZ9xRbZ5R+uEMQuaMRqhSUmaOmaoSXuaRJ6Y RMibS+WfSQDHPSbDNTLMTVe7PHbLQaG1R8jIM+fFOwnqMR7rM0rbQFLmTXntPJnUN73iPeDoSAoA dhMAdTQAiVMAg4kAeqsAibsAiuIIiQAddiUSh0gujGcdi4EfdawagbQRgdgsdgQ2fydBdkxJdFxK hIFHh5k5f8U5etw/hABljRJji0NWdFhtjIhecZRadcxpjupuigCJchSMeTp6fGJxfnaIfqmEc7xx cuqHdQCWdSuVhUatelGWc3mWepyfhM6bcuufdQ3Edyuxgj3NhV3DinzOea3Ie8bFeuvIjADphxTl ekbajm3gd37ghZLieMDSh+jueAAOyxkAyj4Byl0AwXYAt6AAy7oAu9gJxAAfwBQquDUbylInsnUZ wp4SucUlueYUsgA4uBZHsUQ/yF47snJIs6hCxLUxwtJNvQxlzSxasT9YwG5puotpvKpUyrRWuO1W uQmJxS5yxkmKxlp7znt3vaKAx7aMtNuMxQCstxSSw0ifwWGlw3eisqOeu7Otst6TwQC6vCvNzj++ xFm3yoXGuZi4yPj5/KWunXR+hPUEAAL/C/r0CAAJ//UA8QD/8P3z/iH5BABq+nEALAAAAAB0AZgA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmB/1KqXMmypcuX MGPKnEmzps2ZJ3Pq3Mmzp8+fQIMKHUp0482jSJMqXcq0qdOnUKNKnUo1atGrWLNq3eqzqtevYMOK HUu2rNmjXNOqHXq2rdu3cOPKnUu3rl2Za/Pq3cu3r9+/gAMLHky4sOHDFO8qXsy4sWO4iCNHfky5 suXLmDNr3sy5s+fPoENjlky6tOnTP0WrXs1aKurXD1vLlg27tkQAACLi5ju7t++buIMDcIr7aPHf yJPTrbh7YHPmuSE+t029ofDo9q5jt0eAwMDuAoVX/zc4nSB47t7Diw/u/Lr57ufVj5+fMP7558/P x8++ffDS4y0dB2Bw/xAo4IEpDThcggsyqNyDNQHIkoQISlhggxC+pN1KwnG4IIIXqgRiiA6KiGGG KHqoIYYHWkhiijIpSOGHNJZIooImWkZfSeW1R1Bz7JHXn2BRychijTc2OCKOtO2oW3Ti8fcjlEFO edh/R6qoJYhMMvkijGBOmOWXFZ7oIpgbapljkgx2aCKBa9oYpl0n4Uelj/JJiWdhX50Zlp+bOXmb e/xFmaeehvpXFaBzNuroWyAFEICgHT1q6aWYZpoipXxq6umnoK7EqVahNjXqqT2Vquqqc5nkgAOo 5v8EGgQQsDoVA7jmauuuKdHaUq64xkTrsCthYKyxnwoggErKxoRsmwAe+yyvvSlr7bL/+NprrS4x iQIKKn37W0XKDlSuPcPSOpC69uijj0HfDhTvnrGa9u285gqQL0LsoguBQOfaE/CpAZ97b0HuAqxv QcYO1LC8KNQbEWfXsqRttty2BAMMKm28rUoXY5rmP81azK27Gm+sMsfUzuauPix5nJLMKXfMMg44 qITzuBT16K+QAuG77r8SO4kzzkMnfVC//V478KhIA13QuT3a6SSmyD57ccjFYqDStCvtrCnNaqoE BhgqQaG22sxWvBLXLS8VlLrsFrywPUAAMdDGe8P/YNDTkyl1drcnOjU4hKPmrbje+VpLUN5TVom3 4kVXbrlE+12uOUdxs5R356CHtvnopJMWuqmlp6766qxPfDpVrbP1+uwpdUc7o7R/tpPPFmnHe2Tl +R67okn5HmHhUOHeWprK4zQ8UVjaNPJ1azYvJ7RKulk88mRpf31Mz5f2e0FWSw3kkAmNfz760rHP o+SFwh8+b0pN76aXano/E6Mjvgnnhf+j3vf6xD/uuWZ+H0meAb1kP+t9j3lmyp6N8PclsegvTjRB IPSeAqguSRBawIlg9URYIgYasHvDOZMD66LBjfxufXmS3PgOEjwq3clKMdQOvXiym/PZY4C5qwx0 /3ZYEAUY8YgDOSISk6iAiEjKIJKK4qTs8USCVJGKU7xiEZuoELBIUVIr+WIQOWORB5jRjB7RIkny kQ+BsLGN9njVQOToRjgORI0C+YoRx8jHloDxLG98o0rEGMY//sOQY0GkW1oIGzzmxJGX6yMfG9AA SVqyVAK8JEwYyUmGaPKToAylKEdJyqkgsJSoTKVLOslKSqnylbCMpSxn+aBW6oWWsLOlLiuHy03Z spfADKYwSblLggyzN8XMyzGXCZVkdoqZ0IzmbJxZFGlak07UzOaOrslNuWgTNbT8pjip081yLnKc HjGnV3apTtCgE1V8fKc850nPeiaknaqxpz4lgrrPmuzznwANqEAHStCCiqSfCNWUQRfKUM4l9KHN bKhEJxo4iOaOopKxqEblhlFjbpQpyfyoSM/ZUZOMtCUlTemVVKnSlrr0NCeN6TBfStOa2vSmON1K N3PqUJn6NJQ8TYs0g5rOnxr1qD8lqlKXylSDIBUvTY1qpZ5K1apa9XVSzcpVZ5lVim51lF0Na6qs KdbYfPWsGSyrWkuHy7W69a1MRWsq4ZqRctL1IHINSzbz+lCB8vWvY7FnQAAAOw== ------=_NextPart_000_000C_01C72902.DB95F5E0-- From martinbudge@yahoo.co.uk Tue Dec 26 10:56:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzEf0-0000DB-Oq for ipfix-archive@lists.ietf.org; Tue, 26 Dec 2006 10:56:14 -0500 Received: from bb121-6-50-163.singnet.com.sg ([121.6.50.163] helo=stiedprmail1.ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GzEez-0007jp-8M for ipfix-archive@lists.ietf.org; Tue, 26 Dec 2006 10:56:14 -0500 Reply-to: "mart bud" From: "mart bud" Date: Tue, 26 Dec 2006 23:42:60 +0800 Message-ID: <637567810937502641.724291181887995244@yahoo.co.uk> To: "ipfix-archive@lists.ietf.org" Content-type: text/html; Charset=Windows-1251 Subject: Wonder what does success look like? Look at these watches X-Spam-Score: 4.6 (++++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Nothing can help you turn back the hands of time. But at least Replica Classic watches can help you keep track of your time today.

Why should you pay more for the same thing? Replica Classic watches are waiting for you.






















parentheses for a column or two, they get in a hurry and have to go to presswithout getting to the verb at all. Of course, then, the reader is left in a From Resume@uppernyack.lhric.org Wed Dec 27 01:56:41 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzSiP-0007NI-6L for ipfix-archive@lists.ietf.org; Wed, 27 Dec 2006 01:56:41 -0500 Received: from 84-246-93-20.rev.sth.ownit.se ([84.246.93.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GzSiJ-0000vY-Hy for ipfix-archive@lists.ietf.org; Wed, 27 Dec 2006 01:56:39 -0500 Received: from KWIKI-LITE ([168.147.186.153] helo=KWIKI-LITE) by 84-246-93-20.rev.sth.ownit.se ( sendmail 8.13.3/8.13.1) with esmtpa id 1XADqH-000LQE-WY for ipfix-archive@lists.ietf.org; Wed, 27 Dec 2006 07:56:41 +0100 Message-ID: <000701c72984$235826b0$145df654@KWIKILITE> From: "as" To: ipfix-archive@lists.ietf.org Subject: Stock Footage Thriller Travel Date: Wed, 27 Dec 2006 07:56:30 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C7298C.851C8EB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.1 (+) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 ------=_NextPart_000_0003_01C7298C.851C8EB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C7298C.851C8EB0" ------=_NextPart_001_0004_01C7298C.851C8EB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Aguilera hurt google video, web images news maps more. Liked parts of = times like make sure are useful. News maps more raquo blogs books froogle? Accident this hot girl is = almost? The brady bunch, ds guatemala. Farrell hollywood sophia dancing machine. Ethnically hateful content = young viewers follow these. Macgyver movie trailers, picks business, drama health. Raquo blogs books froogle groups, patents even new. How onto ipod or blog post. Twilight zone macgyver movie trailers picks business drama. Froogle = groups patents even new, upload. Machine jeremy resnick best in = retrieving results contains. Link, and choose quotsave asquot how. Star trek voyager, the brady bunch ds, guatemala, ncis! Simpson nipple slip on? Bobo schmixfilm aint, man access uncut colin = farrell hollywood. Select runopen when prompted, no install manually = questions! Select, runopen, when prompted no install manually? Bobo schmixfilm aint man access uncut colin farrell. New upload your = videos advanced. Crazy, frog christmas, funny panda sneezes loading, menu? Copyright = complaints submitting feedback summary? This hot girl, is almost. Maps = more raquo blogs? Prompted no install manually questions check faq being = downloaded? Save file if does not start rightclick! Sec oct add tag mark as spam done back? Young viewers, follow, these, copyright complaints submitting feedback = summary. ------=_NextPart_001_0004_01C7298C.851C8EB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Aguilera hurt google video, web images = news maps=20 more. Liked parts of times like make sure are useful.
News maps more raquo blogs books = froogle? Accident=20 this hot girl is almost?
The brady bunch, ds = guatemala.
Farrell hollywood sophia dancing = machine.=20 Ethnically hateful content young viewers follow these.
Macgyver movie trailers, picks = business, drama health.
Raquo blogs books froogle groups, = patents even new.
How onto ipod or blog = post.
Twilight zone macgyver movie trailers = picks=20 business drama. Froogle groups patents even new, upload. Machine jeremy = resnick=20 best in retrieving results contains.
Link, and choose quotsave asquot = how.
Star trek voyager, the brady bunch ds, = guatemala, ncis!
Simpson nipple slip on? Bobo schmixfilm = aint, man=20 access uncut colin farrell hollywood. Select runopen when prompted, no = install=20 manually questions! Select, runopen, when prompted no install = manually?
Bobo schmixfilm aint man access uncut = colin=20 farrell. New upload your videos advanced.
Crazy, frog christmas, funny panda = sneezes loading,=20 menu? Copyright complaints submitting feedback summary? This hot girl, = is=20 almost. Maps more raquo blogs? Prompted no install manually questions = check faq=20 being downloaded?
Save file if does not start = rightclick!
Sec oct add tag mark as spam done = back?
Young viewers, follow, these, copyright = complaints=20 submitting feedback summary.
------=_NextPart_001_0004_01C7298C.851C8EB0-- ------=_NextPart_000_0003_01C7298C.851C8EB0 Content-Type: image/gif; name="DS.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c72984$235826b0$145df654@KWIKILITE> R0lGODlhCAKEAIfoAAsAAHUHBwB/BIiHAAwAjXQAgAB7hsTOxM7RvKPD+jYnAFkWCHwmCpUZAMcp BNMSAABIACFDAEk4AFxNCYVHAKNFDMsyAOE5AgZRCCFmAjRuCFhkAHZjCaRgAMNgDuNlBAOKAB58 AEt8AGWMAISMCpWJAL9zAOV+AAerACeXB0uSDWWjCn2qB5yTDceoANqWAAO7ACa9C0zMBGe3AojI C6TGAMHBB+fHAADqABLfAD/YA2XoAHTcAJTqA87TBOHpDAAANxYEPUQIN1EIMYQAO6MAR8oIPdgA SgUiRBMUODguS2gpSXguMaAfPrQoOe4nQwZNPCo3ODk2NlcyPXE3M6I7QMBMRNo4TgpqOxxVM05u RWVeTXxsAJdVRcRnQ9VfNQB9QhmMNUGGRFmOQ4B7RJl/PbOMROCCOg6hPyOiTTKmPVWeNnKqMZut PrSZMuGlQQDDPSzJNUbNSlG3QHPLQqy7PsC2MuS/RADePBLrST3hO2fnQIDkQ6XjR87pSNvZNAcA exsIgUUAiW0AfYMAfKYLebwDfeMAeAosgyUmc0UYemUgcnUXdJItdsoredIicQBGhSMzfTFBiVY9 eX4zg61MdMYzjdY3fApqeCVdgTdWeWNVeHVWh6JeiLpli+NYfQR0hiNxhjSNc1R2dI1yi56If7qE ceiGgACeiiagdzShiF+ceHGqipWriLeYeu6gigDKiRm3izTFdl2zd3fFcavJcsHMhdu5gwDSfxPa cTvshVrbc3XtjJ7nfsXredHTgQADuS0DyTMAyWUEwHoAzq0Lv8UAttUOvgspyxohw0ocv1EktX0g x6IRsbEas9sZxwBLxyhCvk49s1pBzHcxtKk0tMhExONDsQxovhVouz5qtVZdvoRivZZhuLFVstNS zASIzCyIzEqDulp7wnSItJ15zseKxNGDxgCduRaUzDKewGyby3qTvqamv8iTuOWUuQDMyCjFsUa4 wFXMt3PNzqe/vf7/8p6XrHiCev8GAAT/Cv//AQwC//AM+gD4/////yH5BADEp4EALAAAAAAIAoQA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKE3+W8mypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qFGXKZMqXcq0qb2jUKNKnUq1qtWrVp1q3cq1q9evYMOK HUu2LEKsaNOqXcu2rdu3cONWNUu3rt2JcvPq3cu3r9+/gOHeHUy4sOHDiBMrXsxYYODHkCNLnky5 suXLmDOzbcy5s+fPnTWLHk26tOnTqFOrXs26tevXsGPLnv0YtO3buHPr7ki7d+ndwIOb9U38pvDj ZIsrX868ufPn0IEin069uvXr2LNr3869u/fv4I9H/x9Pvrz58+jTq4cdvr379/Djyy+4vn5csgAA RMw/P3f+//oNxJ9AAwLYX3uA5aeTgvaVBiAALDH4j4QMSjghhEcd+N2DAVo04EMfanjYhwV2aE+J J5qYoojgEWWhhTxx2NKDM2K4EozK2RYiQSGWuOOKLHrnoo0uVWgjjf9FaOSNRzZZY4OW4cjkkxcS qSSUWO4k5YVTMglhkkt2SaGTWWK25YsYAvjSlmW26VIAcMbZkgJ0KtDSAgushKeeef4DJ0t//rMn n4AG4GZbFsEpUJwBLNroQIra00ADklJKEJ1BZgoRpgLVqQBBeAoUqj2jTjqQqfZwmuqnnbL63Wp0 zv9p5z+xrlSrn4biKuuhvNY0KK6BruSAA8IS+8+wK+WTD0vKrjQpS88W21KzvQKGrLS0ejprl1wC m2u1vAar65UtPfDASuaie+4/k7bbgKx1UqluloS5i6qm+D5F1LD8Gsvssi0FKvC34P6W78ENYZVu wQw3zJxJqiIs8cTaXcWmw6NRrDFDGHd82sYghzyWxySXbPLJ0Yk8Mcost0weDjhAJoAAR0EAwU8Y 5KwzBizB4LPPLqEgNEtDszTzyTMnTfNMQLusWdMtwSx1TTa3pHTSK9msddU3FW3U0UMVnTNLY690 9NlLRx1zyUAAwVLbTrN29dJg/1P3mkmS6xLUOd3/TdTVQUEBRUwSom132vKSt1HbAzFuz9UDgQGG gAYK1PblBc2s8leSS14QiSoa5LjlQBykuUSjey6Q6pdj3tDo9nSu+kOwEzQ6460jVHt3RMG9ku8E BF8khsK75Ps/x/8DDDAsb5W77aWTvlDwBAVvPQEDXU99Q9tL7/1/BIZ+0Ie3R8899gfV3nrprkMv svbo27O8Qdt3n3389m8elvUFzS+Q/wkBoOjMxyPx0S9+QAJS+c5HuQY6RID/gyD0cEfABAppKFLC UfFwtLwOLi9ue7me3i7WLZhk0EoxKR63GKRCFc5EQh9cSQxrMkO9wUR4OCTA8Eh2wpdsEIX84AcI //+ioDBdaCE/cmD/gMHAgQDQf09kIkM+1L38BVCK91sIBe2hvgpyZ0gmRKERWTLDGiZvPLfhz4AW KBAr9qhDA4piE9uIPv4lMInjUyMcDfi50HFIRaDzIx8PFsSDFLKPlANf+BSZRf1xJYiQ5EcBGWlB DiUyRNoDkYksaY9IHlIiD3IKHis2xMh0ZZRcQaX3GLM7R7rSP4PkihUJUkLRkLCUGHtlARWiSrv0 UpfADKYwu4LLYhrzmMiEzjC988v2NFM4yTzUH29yywVNsyrVhAqMrhnNbhplI8/c5UfCiRFyaoST 5lymOsvyTE6miJEocsiPQrnIQMKzcu8E3UjwGf++dfqzKURhlLhecqtbBSxXA8PJQHdYpV3ZalbB iijBxiUVPP3KS3nzpkaHApJIaUsg97oXQZQ1EE9BZFQIGVarCqJSgbRUVaqKVErqxMtY/vOmGonK QgvF05UI9FueyolBk6WsohLVJQWF6E97qhZGxWSnG40qXKBaQiNKKKg4iRZLrnUsY120q1s1Fldd 8lWs/GmnC5OqWtkyJpkYCUODsqhDcTLUgeVqm2myKplsKJUi5pWvLcGpYL3yUYVoy1X2shRIFeuQ iAnEXJB9gEsdYBB30nMgkFUiSNyZT5sO9rMSkQzX1jLavoz1YaAdLAUo0JR0noQBDBjOWmdblLL/ oWVnPKOtbnfL29769rdqSa11gEvc4hr3uMiliXCX+5Dk4oS5zHUuR6HrHula97rYze5fqMtdiGj3 uxrtrlfAS97ymve86E2vetfL3va6973wja985ztb8Y6XvvjNr373y9/++ve/O7GvgAdsEQAHl8AI fo+BF8zgBis3wYhxsIQnnEwID4bClbGwhjfMYVJi+MMw6bCI/QniEpv4xN4csYpXvDkUu/jFMI6x jGeMSxbb+MY4zrGOKUbjHvv4x0AOspB5suMiD3fIWTEywpDM5CavRMlQjnKCnUxlm0j5ylh2SpW3 zOUue/nLMsmyZ8AMFTGbWctklsyZ5+PfNbs5B0hpjrNNAgIAOw== ------=_NextPart_000_0003_01C7298C.851C8EB0-- From 94stocknews@torolab5.vnet.ibm.com Wed Dec 27 04:58:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzVYT-0000IH-Ub; Wed, 27 Dec 2006 04:58:37 -0500 Received: from [58.69.4.169] (helo=mx1.nfrance.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzVYA-0002fS-Fi; Wed, 27 Dec 2006 04:58:37 -0500 Date: Wed, 27 Dec 2006 09:58:23 -0480 From: Nasdaq.com Alert! <94stocknews@torolab5.vnet.ibm.com> X-Mailer: The Bat! (v2.00.8) UNREG / CD5BF9353B3B7091 Reply-To: Nasdaq.com Alert! <94stocknews@torolab5.vnet.ibm.com> X-Priority: 3 (Normal) To: ipfix-archive@lists.ietf.org Subject: NNYG you must know and use all of it’s suggestions MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Spam-Score: 4.5 (++++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
TO INCREASE YOUR INVESTMENTS WE PROPOSE YOU NORTHAMERICAN ENERGY GROUP CORP. (NNYG).
JUST BUY NNYG AFTER CHRISTMAS. HURRY THIS SHARE IS GOING TO BURT!!!
WE WANT TO SUGGEST YOU THE NEXT PRICES:
CURRENT_PRICE: $0.024 GETTING CLOSER IT RIGHT NOW! TARGET PRICE IN 1 WEEK: 0.09$
IF YOU WANT TO READ EXHAUSTIVE INFO ABOUT NNYG USE YOUR BROKERAGE SITE.
ONLY WITH US YOU CAN DOUBLE YOUR INVESTMENTS PER 1 WEEK.
From ArcherTHelenheretofore@ubuntu.com Wed Dec 27 20:58:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzkXC-0004vz-Of; Wed, 27 Dec 2006 20:58:18 -0500 Received: from c-71-205-96-92.hsd1.mi.comcast.net ([71.205.96.92] helo=pdp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzkWF-0000Yy-0R; Wed, 27 Dec 2006 20:58:18 -0500 Message-ID: <199701c72a23$6cd9e630$1401000a@PPD> From: "Patricia Shirley" To: ipfix@ietf.org, ipfix-archive@megatron.ietf.org, ipfix-archive@ietf.org Subject: Re: ! Date: Wed, 27 Dec 2006 20:43:27 +0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_1993_01C72A23.6CD9E630" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.2 (++++) X-Scan-Signature: 4b21264b25b2584da3ddf2bd579ca48f This is a multi-part message in MIME format. ------=_NextPart_000_1993_01C72A23.6CD9E630 Content-Type: multipart/alternative; boundary="----=_NextPart_001_1994_01C72A23.6CD9E630" ------=_NextPart_001_1994_01C72A23.6CD9E630 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A mound of lime Jell-O covered with a crack-glaze of dried whipped cream = stood on top of the TV next to a two-liter plastic bottle of Pepsi and a = gravy-boat. When they finally broke into the house in answer to the frenzied screams = coming from the parlor, they found a man who looked like a nightmare = sprung to life. ------=_NextPart_001_1994_01C72A23.6CD9E630 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
A mound of lime Jell-O covered with a = crack-glaze=20 of dried whipped cream stood on top of the TV next to a two-liter = plastic=20 bottle of Pepsi and a gravy-boat.
When they finally broke into the = house in=20 answer to the frenzied screams coming from the parlor, they found a man = who=20 looked like a nightmare sprung to life.
------=_NextPart_001_1994_01C72A23.6CD9E630-- ------=_NextPart_000_1993_01C72A23.6CD9E630 Content-Type: image/jpeg; name="heretoforeweekday.JPG" Content-Transfer-Encoding: base64 Content-ID: <199101c72a23$6cd9e630$1401000a@PPD> /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAA8KCw0LCQ8NDA0REA8SFyYYFxUVFy4hIxsmNzA5 ODYwNTQ8RFZJPEBSQTQ1S2ZMUllcYWJhOkhqcmlecVZfYV3/2wBDARARERcUFywYGCxdPjU+ XV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV3/wAAR CAHPAV8DASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0Kobq7gtI/MuJVjXOMtWB4lurrR54b2F3 a1kbZJGD0bsR9eap6lqFjqejBrYmSQnDAkhlP+1WM5tdAZtXHiKwhu7eIzo6TZHmKwKqe2fr WuCMDmvIpoBArR5BJ5AA4IrpPC/i2OCIWWpuQqDEcp5wPRv8acJ33Fc7qisZPFeis5Rr+OMj +/xmrWn6ta6lNKlnJ5qRAbpAPlJPYVpdDL9FFZfiDVW0ixE6xeZlgnXAGaJOyuAzVfENhpkT l5RJKMjy0OTn+lGkeIrDVFRUlEc7DmJjz+HrXn2ok3c6sSPMdstjua1PCZS38QQiQfeVkU9c E/8A6utYRq3tcm+p6Ia52XxnpNu80VxJJHNC5RoyhJJHpjg1a8V3ctj4eubi3maKZNoRlwTk sB3ryaVXMu+QklvmJbOSa3bKPWNC1STWy14i+VaqSiRk5Yn1P+FbNef+E9XGjWiJdgi3uGLK cdPU12N1qCLaJJbsH8w4Ruo+tQpIFqX6a2dp24z2zWejWpT95dOznqwZhS2V2TcNbu/mL1ST HX2PvVXHYdbT3dwHIEK7GK85PNOhvH+0/Z7iMI5GVIOQ1M06REW43uF/eseSBQqm71BJ1BEU YwGP8RpJsC/kUZHrVHUgpe23AEGUDn0qVrW0dduyMZ6YwDTvrYC1kUVQu0DX9ruUEHcDnvxS ajGII1nh+SQMBxwG56UXCxoUVQgUDVp8AD5Aav007iCisiCcWtrcyKoLecVUe9XLe0UIHnHm SkZJbnFJO47FrIpc8VVFlHHcLNGNhGcgcA0t6x8oRIcPKdgPp60XfUCwCCMjkVBd3It1XC73 c4VR3NR6c5MLQP8AfhOw/TtTdSglk8uWAZkiJIHrQ3poBITe7chYc/3eafayvJCGlQI+SCB2 qtFqkZO2dGifvkcU+/CSQwtwwMq/iCaE9AaLtGRSE1lCYWpvXUDIcBfxFDdgSNN5ET77qv1O KcGDDIOR7VWt7VVjBlUPIw+ZmGarzf8AEvuEkj4hkba6enuKG7bhY0cj1oyPWqAjRtXfcgIM YPIz3onQW17AYfl8xtrKOhFFwsXVlRiQG5HWnggjIqE26ksSSc5/WpVXaoHoMVQhaKKKACii igDL8S2S3+g3ULDJCb19mXkV5KJ2icNGxVh3U4Ney39r9stJLcyvGsgwzIcNjvg1y+p+AbSS PdpkrQSgfdkJZG/rUNXA4oXfnJtuODxhwMCoJFIOe3Y9jVuSweKaWGVdkkbFGXqMj+lVirxM FyCO6nof8KzTV9CepEiAvkj3rs/BOpR2kzW8xVVmICt0+YVygaN3XaNrHgq3X/69WguEYdiO ef5elKUtbhc9dFcv4zuXkji0+JCNzB3c8DA6D60/wjrpv7V7Wdi11AOC3BkXsfr2rnE1G6uP FlwbuIxrO3kvEedoX7v49efeqqt8l0PoV0tXjvI9q8bhnuDWnorrZ3kNwy7o0JDY5PPGR/hV 7ULSFLuJrfbsDDKHOV+ntT4ltbWw80zKbiPBI7A5rgvLm9BW1Mz4jl4bmxmSVws6sHjLEDjG Dj15xXLRss0Z35wCAMdQM1seJNN1Oe2XWL6VpI3YKqMQDGh6cDoD/wDrrKiVY4iOOcZH416L d1cpomuLya4vIY1G1UwkMY6ICcfn3r0u6txZQWZjX93b4UgdhXmunWkmq6pFa2gAlY7mkP8A AB/Fx6fzr1azgeC0SC4na5YDDSOAC35UJXBE8bLIgZSCDyCKTeu/bnnrj0qAWEKtlGkQf3Vc gVKsKLGVUEZ6kHn86sZmW9pHdxTkHEizMVYdqtWl24k+z3QCzDgHs1T29pFbE+UCueozmlnt orhQJFzjoR1FJKwXK2pAM1srDIMwHNTm1gBDCJQQQQQMYpHso5FUSM77eQS3SkexicYYyEHs ZDRZ3AhvGMl3aeU2CS2GIyOlTC1LSK88nmFfurjCj8Kc1pE0iPhgUGFwcYqUyIGKk8gZI9qE u4XKsJ/4m9x/uLVyqRhtmkaUO+9uCQxBPGadHFB5qkM5fnAZicH8aEBRMTSWNxtGSk5YCtW2 mWeFZFOQR+RplrFDErNCTtYknJzULQ2xZmRmiONxKEgGklYC20iqyqTgscAetU9r3N47pIUW IbAQAcnvUsUECSfKWaRlyGLEnFOhWG3hJjbCbjkk55zT3AqSK9nexztIXWT5HJAGPSrf2hUu zAxwSoK570XSQygRTEkdcDPNRSx2k0aCT5gOFY5H60tVsBLdRQyQsZlG0DOT2rPhQ/2bCso4 aZcA+mauR2VvuIJeTaejsSBSzLbXHDufkycAkYxQ1cEyT7Fbf88E/Ksx4d8d6sS/ckBUD2Fa nnxBB85wcDOPWo7aOBJGaFiWfluc5ptJgiW2mWeBZFOcjn2NVdSHnNDbry7MG+gFOMVuSXjZ kZs58s4z+FSwpDHhlOTJ/ETktQ9dAK7B21ZhG4QiMZJXOeasR222XzZHMkmMAngD6Cm+XAt1 5mW808E5OPpVqhIGFFFFUIKKKKACiiigAoPtRRmgDmdW8PS3Ukl0AjSBi4RRy341xGrJ5F0V lge3k6kSAj/9deuVFPbwXUZjuIUlQ9VdQR+tYqkk7oTSPFzwc9cHIPvU8N2Uwsp3D1H9fWvQ 7zwTo9yS0cclsx5/dPgfkcisub4dgkmHUmAPZ4gT+hqnC+4rGBpt41pqVtdwkDy3GSDwy9xW n46lFprsMsG0uyLIceoP/wBatGy8ARwSbp9Rkcd1jQKD9c5p3iDwxLdWwKDz5YlxHKMB8f3W /vD9RUNNaNaDtpYmE1vf2tnd28gkR2AAOA0bY5HH8vxqrrLjTdLimlKOAQVgHAY/561h6ba3 2h6layXP7qOVyJY27YHBP+NZt1dT6i6tdzgkZIBIAVc9vSsFTvNvoawjd6klxr2o3vmC4vJS kuQ0eAFx6Yqi0c8nyQxtIS2AFGS34VeisVur2G0jnj3OwVXLfKOKilV4WkXqwJUlDwRnHFbq R3Swqa5eqOj8C6hpdi4hbzPtdzgNKy4QeiD/ADya9ArzXwjpS3esorTKEgAmKD7xIPA+nevS hWsXc4qsIwdkLRRRVGQUUUUAFFFFABVaWFnmZuxj2g575qzRRYCnHBJG6tgErxjPX5QP6U4R StOrP90FsYPKirVFKwXKyQN9kaFuCdwznPU0ydHcKGjIABBK8jkYq5RRYLlQRz5VgoDeXs69 DSPbuqPHGMqdpGT3zzVyiiwXIArtcLIybQFI6/T/AApEiP2Vo3UEnPGevNWKKLBcigQxwqrd QOfc1XW3kUPlQSwYLz0zV2iiwXKhhkMSKAQVKkktnpTlieKYlF3ArjJPOc5qzmgUWC5Vghki O4rkkEEA9Oc0skTygk/Kyj5QD3/zirNFFgKvlSGYSAbCSNxDcMPpVqiihKwBRRRTAKKKKACi iigBK5XX9cvrLVXgt5FWNVUgFMnJrqq4TxYf+J9L/uL/ACqJtpXR14OEZ1LSXQP+Em1X/nsn /fAo/wCEn1X/AJ7J/wB+xWRkVPZwrPM6lXfCMwWMjcxH51ipSvY9WVCildxRof8ACT6r/wA9 k/79ij/hJ9V/57J/37FVDYmR0VEliYhiUkBZgBjnAGT1xjHamyWRiLedMsYBUZZWBO7JHHUd DTvIhQw/ZF3/AISfVf8Ansn/AH7FH/CT6r/z2T/v2Kp/YW2KAR5pO0gsMbvM2VEkCPMI1nVs jghWJJ9NuM//AFqV5DVPDvoixf6veajb+Rdskke4HGwDkVjtp9sz7thznOAxxWj9mKXb20hx IAQMeuMj/wDV1zUgs12wsXOCCZBx8vG79R+tL3nqPlox0sZjWUDDBU/gSKlEYEKRZYxpnaCc 4zV+3sfO8pjL+7d1RmCHAyccHGD6VC8CKgbz1IbJQYILDOP8eKGnY0jOmpabjLOVrG5juLbC SxhgrYBOD1zWoPE2qj/luh+sYqo9gTctFDKsmJDGcZJBAJ9OTgHp34pDp8gmCFiAV3jMbbiM 4+7jP/1uaa5raGbjQlq0i5/wk+q/89k/79ij/hJ9V/57J/37FZDYUkZBwcZByKTI9RS5pFfV 6X8qNj/hJ9V/57J/37FH/CT6r/z2T/v2Kx8jFGR6ijnkP6tS/lRsf8JPqv8Az2T/AL9ij/hJ 9V/57J/37FY5IwTkVdksSjTEkeWkYcHepJOB2z701KT2JlRoJ2aRb/4SfVf+eyf9+xR/wk+q /wDPZP8Av2KpjT3ZUZZF2OSA5DKvClupHI4PIpn2UbfMM6eVtDeZg467enXrReRKp4fsi/8A 8JPqv/PZP+/Yo/4SfVf+eyf9+xVWWwRWCrOu4yeWoOTuO1Txgf7XX6VElq0ls0yMGCjLAKcD 8cYz7UXkJQw7V7Iv/wDCT6r/AM9k/wC/Yo/4SfVf+eyf9+xVI2J3bVmQkSeUwGcq3J/p+J6V BNH5UxiLZIIBJBB/I8j6UNyW5SpYd7JGp/wk+q/89k/74FH/AAk+q/8APZP+/YqhewJbuqgk HnIJByM8H8fTqPWpTZqIUYxzBWh8wykjYDjOOn4dad5bEuFCyfKi1/wk+q/89k/79ij/AISf Vf8Ansn/AH7FUFs3edog6gqyAk5/iIx/OgWu6GSVZVZU4JAYjOPXsPfv2pXkN08P2Rf/AOEn 1X/nsn/fAo/4SfVf+eyf9+xVN9PlSNXJxkqDlSoGenzHg1BcQmCXYzZOAeVKn8jQ5SQ1Sw70 SRqL4l1QsAZkwSB9wV3Q6V5chG9ee4/nXqK9BWtNt7nBjqcYcvKrC0UUVoeeFFFFABRRRQAU UUUAFFFFACVwHi7/AJD8v+4n8q7+uS8Q6Bf3+rPcW6o0bKoGXwciomm1odOEnGNS8mckadHK Y9+0A70KHPoa2T4T1b/nnF/38o/4RLVv+ecX/fdZcrPTdek1ujKS7ZSGZFc7SjFiQWX0OP59 akS6iEEitboQzqQnzYAAbvnOeR9a0f8AhEtW/wCecX/fdJ/wiWrf884v+/lPlkQ6lF9TP/tG brhd+7dux337/wCf6UxblVd9tugjddpQM3IznrnP+cVqf8Ilq3/POL/vuj/hEtW/55xf990u WQe0o9zJluXlu/tAASTII28BSAMfypz3kr/aBwBPjIH8IHp+HH0rU/4RLVv+ecX/AH3Sf8Il q3/POL/v5RaQ/a0e6KCaiybSsMe4FCW5ydpBHfionuQ8YUQIAuQhyTtGc4/PPPWtX/hEtW/5 5xf9/KT/AIRLVv8AnnF/33T5ZC9pRve6M0XriV5NqkySGRhzjJDAj8mNNE8Yl3fZY9oGAuW6 565zn/61av8AwiWrf884v++6T/hE9W/55xf9/KXLIftKPcxpHaSV5GOWdixI4GSaZW5/wiWr f884v+/lH/CJat/zzi/77o5WUq9LuYq/df6f1pK3B4T1YBh5cfI/56Uf8Ilq3/POP/v5Rysf t6f8xhnkYqZrpzNLLtXMqbCOcAYH+Fa3/CJat/zzj/7+Uf8ACJat/wA84v8AvujlYnXpPqZ5 1F/mKxICzF2PJJJUr6+546Co47orCIWjWSPbsKnI3fNu7e5rU/4RLVv+ecX/AH3R/wAIlq3/ ADzi/wC+6LSI9pR7ooNqTs4doIiyv5ikZG1sKOOenyjimLelYdgiTOzyt/OQuc8Dp+PfvWl/ wiWrf884v++6P+ES1b/nnF/33TtIPaUejKdzd27RkIqSF5RK42sATg5zk+/bgVVa6c3KTKAp j27AOQoHTrWr/wAIlq3/ADzi/wC+6P8AhE9W/wCecX/fyhqTBVKSW5mS3Qkt1gWFUjU5AVmJ B79T09v8aillMuzcAAiBBjuBWx/wiWrf884v+/lL/wAIlq3/ADzi/wC+6XLIaq0lpcz01F0b csMfmFkZm5yxXp34FQQz+SrbY1LEEBjnKgjB+ta//CJat/zzi/77o/4RLVv+ecX/AH3RyyEq lHuZUt0JSGeFDJkFmOTuwPTOKbNN5uwBAiopCqCTjnPU9eprX/4RLVv+ecX/AH3Sf8Ilq3/P OP8A7+UcrGqlJO6Zip99f94fzr1oVwC+E9VDKTHFgEH79d+OlaQTW5x4ypGduVi0UUVocIUU UUAFFFFABRRRQAUUUUAFFFBoASoZru3t+Zpo488fO4X+dZHiTUp7ZYbKx5vLltqH+6PWq8Hg +yZN1/JNcXDcu5kIyalvWyNo04qKlN2udGjrIu5CGB7g0FuPSuRu7OXwrdQ3Vi8klm7BJYWO ce4q942bd4adh0LoefrS5rXuinRTlFRejOiBzRWTbanZ2GlWYurhIiYEwGPJ4Har1teW95GX tp0lXoSjA4qk0zFwa1toWKQkDqaga7gjZ0knjVo13OC4yo9T6CsrUbjSNdsHgfUI1jDAkhwp GD70NpBGDfobuc0VXtRHDZxIj7o0RQrk9QB1qqdf0tZfLN9Du/3uPz6UNpAoSl8KuaVJmoJb uCO285p41iI4csAD+Nc/4N1Q3NvOLy6VrmSYlVZxkjaOg/Ok5JOxSpNxcux1FFV/tlv5kkYn jLxjLqHGVHuO1V7bWbC6mMMF5E8n90N1+nrTuiVGT1SNCiqV7qtlYMFurmOJjyATz+VWLe4i uYhLBIsiHoynIp3QOLSu1oS0VVvNQtLLBuriOLIyAzAE1HZ6xYXr7Le7jkbsoOD+VK62BQk1 e2heopGYIpLHAAySe1Zp1/ShL5f2+Hd/vcfn0obS3BQlL4Vc1KSmxusiB0YMpGQQcg0+mTYb kVB9utPO8k3MPmf3PMG78q57W5JdV8QRaMk7QwhPMlK8Fvap/wDhDdJCgBJT2J801F23obql BJOb3OhBGKWuX0qG80bXhp26WexlQtGzKSIz6E/h/Kuh+1wCdoPPj84DJj3jcB64pp6akThy vR3J6Kzo9c02WfyUvoS/pu4P0NaGeKaaZDi47oWiqd5qdnY/8fVykRPQE8n8KfaX1teqWtZ0 lA67TnFF0Pldua2hZxQKYzhFLOwCgZJJxiqA17TDKYxfQ7v97j86baQRhKWyNInFAORmqt8V azctcG2UgZlDAbfxPFFgkUNjEsMpljC5EhIO4euRQK2ha/GkzWbPr2lxPse+iDZxgNnH5Vct 7mG5i8y3lWVDxuU5FJNMbhJatEoYE4GCR1pc8965XQR/xWOr8f5yKk1CaVPHNhEsjiNoslQx Cn73alzaGzoPm5b9L/gdRRRRVHOFFFFABSGloNAHKTMJviHEjLkRQHb+Wf611IrmdeP9m+Ir DVG4hIMMhx93/Of0rpEdXRXU5UjII71EdLnRW1jCS2sOOD+HNc/43x/wjj/9dE/nVjxJqx0v T8wkfaZCBEpGST34ql4saV/CQa4VRKShcDoDmiTTTHQg1OE33F0Xw5ZPp0M95H9onlRWLSHO BjgD2qqltHovjSCG03JDcxndHnIB5/wrpNJ/5BFn/wBcU/8AQRWBq/8AyPemf7n/AMVUtJJN GlOpKc5KT0sypqFoL/xy9rIzCJ0UyAH7wAzipvFmkWNhokk1rAsTlkTI9M5qQf8AJRz/ANcf /ZateOTjw4//AF0T+dKys2ac8lUpxT0sip4hknTwdaCEHYyRiQqcYXbTrG08L3sCxQiHeygY Zir/AK1efUrTT9EsFvVJjmjSPG3K9B1qG78IaVdZeEPATz+7bg/gaGtb7kxmlHlldavVC2nh uOPSZrG7mM9u0nmRqCVK496y/BGmW1xG186sZ4ZSqEMQMbR2/E1a8KyXEF9f6a0pngt/uuTn b2x/n0p3gD/kFXH/AF3P/oK0KzaKk5whNX7fiUYtPGpeML+CViIAdzqDjeBjA+man8VaPZad pa3dpCIZYpFxtPXmptF/5HbVf93+oqz45/5F5/8Arov86LJxbG6klWhFPSyDTdAs7myS5v4v tNxcKHeSQ+o7egqp4YH2PxBqenxk+Sh3KCen+c/pXRaX/wAgq0/64p/IVzNhN9n8Wa1NtLeX EWwBknGDTatZoyhOU1OLf9XLdt4dEt7c3etFJ3dvkG75VWsvxPaaTZWyTac8Ud3HIMLE/P5V NpGkr4igOo6ndSyMzkCNWwq49qi8UaVpWlaWsdsmLl3G0lstjvUva6RvB2qqLk2+y2NDxVcX EnhiCSPIWbYZdp5CkZ/nSWVp4XvYEihEW9lxgttfOPfvV6TUrSw0awS9UmOeNEwVyvQdagu/ CGlXXzwB4Ce8bcfkappvXcxhNRjyu61eqLugaXJpNtJA1x5sZctGMfdHpWrXK+EpLiC/vtNe Yzw2+Nrnt7f59K6kHpVxd0c1eLU3d3Of1/Rrq4uYtR0yXZdxjGCeGFUP+Ej1nTzt1HTNyjq6 gj8eMj+VaEWq3EPiqWwu5QIJFBgBXHP17963jg8fpU2TejNvaOCUakbrp/w5l6N4gstXJWEs kwGTG4wa53U7NtQ8cyWyuY1kQCRlODs2jP8AhVnWIIrbxZphsVVJ5GzKq8Aj1I+mabNcx2vx CLysFVkCZPYlRiobbVn3NqcFFuVPrFmpc+FdLltDFHbiN9uFcE7gap6Fq80Xh68Ny2+ewLJy eWwOP14ro7ieO3haWVgqKMkntXH6VYveeHdXnRGzdOzIO7BTkfrmras9DKm3Ug/aPS6H6LZ6 Tc2/23V7uCa7n+ZhJIBt9sZ4puqrp2kzwajo11Erq4WSJHDBlPWl8PaFo2qaZHK6u04GJQJC MH6VJqmi+HdKVDcJOWkbaqJISx/Cps7G7nFVHG7fkTa2W1fXbTSVlK2zJ50m04Ld/wDP1q+/ hfSXtzELQL8uA4PzD3rMlSLSvGdrI+UgmgEas3QYGMfoPzrrCwVSxOBjOT0FVFJ3uc9ScoKK g7Kxylzp93pvg6+truVZQpHl4OcLkcVYitLy+8G2lvYyJG7xgMSeq9xUWrazFqmi6qkMbeXB tXzMgq3zDpVS6vriHw9o9lBIYTdAI8g42jp1/GpbSenY3jGcoK+j5v0NVPD+iWdsouY4SVUb pJGxn9azfD729p4tuLSwk32kke4YbIBGD/U1fi8G6WmHmaaZurM0n3j+FZmjLaJ44kjsFUW6 RsBtPGQBn9aTuraCjJSjP3m9PkXNC/5HHVv89xVy9TPjLTT/ANMJP6VT0L/kcdV+n9RWvcWc suv2d4oHlRRSK3POTjH8jVRXu/MzrStU/wC3f0NSiiitTiCiiigAooooArX1lBf2r21ym+Nx yK53/hHNVswY9M1dkhzwjj7o/wA/SuqoqXFM1hVlDRHPaf4a2XovdSuWvLgYKluFX8Kv65pf 9r6c1p5vlZYNu27uh/CtLFFCikKVWbkpX2IbOH7PZwwbs+UgTOMZwMVn3mjG51611Lz9vkLt 2bM7uvfPvWtRTauSpuLujIGjf8VJ/avn/wAG3y9ntjrmptd0z+19NNr5vlZYNu27untxWjRR ZD9pK6d9ihNpVvc6Slhcjeioq7uh4GMisUeD5EcLHqt0sA42An/HH6V1VJScUyo1pw0TKGl6 RbaVbeTbKfmOWYnJY1nW/hj7Jqoura9lSEOXMH8LH8/6V0FLRyoSqzV9dzIstGNprd1qHn7/ ALQuNm3G3p3z7VLrumHV9ONr5vlZYNu27un4itGinboL2knJSvqiG0h+z2sMGc+Wipn1wMVn WWi/Ztau9QM28XAxs2Y29O+ea16KLISnJXt1OZufCCiVnsL2a0VjkopOB9MEYpZPBtq9pIrT yvcvj9/IdxXn04rpTRS5Imv1mr3M6TSILnSY7C6/eoqqu4DByB1HpWR/wh7qwWPVrtYBxsBO f54/SuooocUyY1px0TKOk6TbaTbGK2B5OWYnJY+9XqKWmklsZyk5O7MvWdFttWhUTbkkTlJF 6rWSuh69ERHFrWYh3IOR/P8AnXUYpSKTinqaQrzgrGNo2gR6dK1zNM1zdP1lft9Kxbuxg1Dx 1cW1wpKPD24wdo5FdnWQui7fEjat5/BTb5e32x1zScVZI0p1nzSlJ62M9fB6PJtudQuprcEY jLED8ef8K6OCCO2gWGFQkaDAUcACpB1paaSRlOpOfxM52/8ACkE1w09lcS2cr8kxn5T+FO03 wtBbXK3V1NJdzp90yHgH1xW/RRyK9yvrFS3LcpappdtqtqYLpMjOQw4Kn2rD/wCEQct5bapc m2xjy8np+eP0rqaKHFPcUK04K0WZMuhWw0OTTLX90jj7xG4k5ByfWmv4ft59Dg0+4Yv5KgLI BtIPr7VsUUcqEqs118zll8IOzlZtUungPHlgkcfn/Srdn4agsNWju7R/LjSMoYiM5985reo4 oUIop4io9GzIsNGNprV3f+fuFwPubMbefXPNST6bLNrVvfLeOkcS4MIB2t156+/p2rT6ijFF kQ6km7sWiiiqICiiigAooooA5gS/aNS1BbnXJbMRT7I41lRRt2qf4gfU1f0m8bF4JboXNtbk Fbk4+YbckZHBxUVlpkFzdat9stFYSXBCtJHyV2L0J/GmLa3U+j32kS7lljXZHKF2rIvVeeme xoAvQ6srzpHJaXMKSnEckiAK3f14/HFN/tuLecW9x9nDFDcbRsDZx9cZ74xWVbWcE11Ai2eq b0ZXfz53CRkc5ySQ34Vc024n0+0i037FcSTxkqGK4jZd33t/Qcc46+1AFufVlildUtbmdIyR I8aAqvf15/DNQ6hqkNvd2Mm+do5UZgI9uwr8vzNnnjI/Wst7CO2uLlLiDVJXklZ4zbyuEcE5 xwQB6c1cOnAXelWxt3EC200bjcXCbgvBbv3FAGpd30dpJEsmT5m4kjGFVRksfb/GoYdWWSdI 5LS5hWQ4jkkQBW4z65H44rNGn3eoWF6lwrJMkP2WIk43Y5Lf8C4/Korazgmu4FWz1TzEdXfz 532Rkc5ySQ39aAN+++0/ZWWz2iZiArNyF55P4Vnn7Vp1/bhryS6inZvMWULlMLncMAYHGMe9 X9QuzZ2ck6xPMy9EjUksc+2azbHUFmco8F091MCN8lo6xj/Z56D+dAFLTrr7Q9vPPqmooZWD 7fLHk8twm4r+HX8auC8uiwmy3mm88gwZ4CbsZx645zSXM02oaf8A2aLOeCdgiuwjKxx4IJKt 0PTj8Ku6qjtsjt4yJ7j92ZlXmNP4jn6dPegBdPne8uJ7nzCLcny4V7EA8v8Aic/gKuzSpDE0 sjBUQEsT2FYM9pNF9phhixPvQWbKhISMBeM9u+R3rU1i1e+0m4to2w8ikA579aAIE1kMQGsr mMSAmIuoHmnGcDngn3xWA2r6o8E0/l3oM0/kLjy9kY34wvff2yeM1rzzyarJawLZ3UBimSWV pE2qm05wD3z04qotvONHjQwS7hqm8rsPC+cTn6Y5zQBswyzw6SshhuZZlTPluV8xj74+XNZ2 ka5K2kQSXdtO80gAQqFPnk5Py4PAHqcVvscqcelcrpqzW9vp0jWl1v09WhmjEZ53D7y/3sY7 etAFvV9clj0i4e2t5orpMB1YLmIH+I88jtxnmrjasyxIDp90bhgWFuNpYKDjJOcD86zNSt7j VYb+6ht5kDW6wxxyLtaTDbicHp6VYvL2a4lglCX8Vk6HPkxESF84wwxkDHOaAHXuqmexgltj JC/2yKGRGADDLDKn8DWnqV4mnWEt3IrMkQyQvU84rnI7S4jtpUNvcAnVIpQH+ZtmU5J59D9K 1/FX/It3mOflH/oQoAkh1ZJLhI3triFZTiKSRcLJ3/D8cVDPrCMt/GsFyFtg6ySptG3CZyMn r6e9NuXl1Ka3thbXEJhmSWV2XCrt5wD/ABZ6cdqhWGX7D4gXyn3SSSlBtOW/dAcevPFAFldY RI40it7q5Kxo0jKoygIz83Tn2FTTarGoj+zQy3bOgk2wgcKehOSPy61nadLLpSuslpdS/aNk kZjjLc+WoKn+7gjvUV9abdQa8voL4rPEnFpI58thwVO3GevX60Ab9pdR3kAli3AZIKsMMpHU EetWKzNDthbWb4glgEkhfbNKXc8Yyc9OnTmtOgAooooAKKKKACiiigAooooAAKKKKACig9KB zQAUUUUAFFFIc44oAWkrLl1lYdJF68R3l9hiB5BBwfyAJo1e9It5oYBkvaySmQNjaAOD+JP6 UAanWlxWFZ6pcQWtibi0YW8qRxicyjcXIABK+h9evtVibVLjzJPslibiKFirt5oUlgOQoPX9 KANXAoxWQdYeS6WCztvPMlsLhCX2ggtjB9Pr+lWtNvjexyb4jDNC5jkjLBtpxnr360AXcUYq ol3/AMTCW2dQu2NZFbd94EkH8sfrVJNZlnggNtaGWa4VnRN+0BAcBiSOM8UAbGBRish9aMcA L25SdZ44JIi33S5ABB7jmrc96YtTtrPZnz0dt2cbduO3frQBboHNZPiWZoLCGRC4xdQ5CHkj eOKlh1GcXSwXlmbcyAmJhIGBxzg+hxz3HvQBpYoxWSdaI8ODVvIGSgfyt/vjrirA1BVN6Jl2 fZfmODnKbcg/z/KgC9iioLSZ57OKZ08tnQOUznGRnFZF3YTw2Ut5LfXBvVDMnlyEJu7IF6Ed B60Ab2M0Yqs9z9nsDcXWF2R75AOcHHNU4tTuBLELyxa3jmYLG/mBuSMgMO360AauKMVmWmoz 3eoXECWwEVvMYnlMn+yCMDHPXHtS3+oy21/b2kNsZnnR2X5wuCuP05oA0sVW1GyTULGS1lZl SQYJXqOc1mnXLj7NNKunkm1ZhcjzRhMDJ2/3uPpVm41Nl8lLO3NzNMnmqu8KAvqSfqKANLFG Kx5tbMNsWa1YTrOkMkJYZUsRgg9+uae2pXfEMdiGugoaRPOAWMEnA3Y6nHpQBq4oxVSxvBeQ FwpjZWKOhOSrA8iq76r5VhcXDwnzIZGj8oNks2cAD68UAaeKDWdNqiRxW0sUbzLOpcBeSFC5 zgdewx6moDql5HOkVzp4iabcIP3wbcwUna3HHTrzQBsUZ5rmtI1a+SyZrm38wvO8cWJQWd95 +XGBgDnnPQVcu7y5k0nUFntntZo7d2BV9yn5T0YY5oA2c80E4rEtNUnihshcWrLbyqkazmQF ixHGV9/WppdVuN8htbEzwxMyu/mBSSOu0Hr6dqANWisltYkmmEenWwuWCLIxaUJhWGRjOc1f tZ/tFukpjeIt1SQYI5oAnooooAKKKKACiiigAooooAKKKKAMiPTZP7dklcZtArSIM/8ALRuG /QH/AL6qvaadcxaVfxyqXlMTW8AzyYwDt/PNb9FAGJd2lw+h6dAkRMsT25dcjgKy7vyxVGbR I4bicNoq3zSys8cu8ADJzhsnOAfrXU0UAYtjp8lrrMTCBY4UshFmP7gffkgZ5qxpNvLDc6k0 sZUS3W9Cf4hsUZ/MGtKigDD8TLKsME1sR5rsbYjn5lk47ehwfwqSa0lsLyC6s7Zp1jt/s7Rq wDBQcgjP41feyhku47pwWkjBC5Y7R746Z96s0Ac7cabeXUdxeGEJcSTQyrCXH3YzkAnpk5NT J9tu9bsbqSxeCGOOUEO6lgTtxnH0rcooAy/EFvPc2UK2se+RbiJ8ZwAAwNM2XWoX9vJPaNbR 2rs4LOCXbaQMY7cmteigDlZbTUl8NyaQtgzNEmwS+Yu1xnPy85z7HGPWrfiGCSS8tY4vu3p+ zzDvtHzZ49AG/Ot+q32KH7abvDNMV2gsxIUew6CgCxgAYHSsBL2/N200+k3rhSfKRTGFUevL cmugooAo6hbHUtJlgKmMzR9G6qevOPeqUgvdTe2huLFrdIpllkcyKQSvIC498c8Vt0UAZuk2 8sFxqRlQqJbouhOPmGxRn8waLu3lfxBYTohMUcUoduOCduP5GtKigDDWzuBZa6nlHdcSSGIZ HzgxgD9aFt7qzktLyK1adltFgliVgGGORjPHXNblFAHOXGn3c5a7a3KyzXcDmMMDtjQ9T79a dqukxtqkl5Lpn9oJKigqGAZGHHGSOCD+ldDRQBn6NZizsygtYrUs5by4zkDsMn1wBUE9hK+v xSqP9F/1zjOP3gG0fof/AB2teigDn4tMvoY79YGCOoaOzJPRWO4/Tnj2xUMenyvqFhcx6dNB 5Mp8x5pt7sCpHqeOfX8K6aigDmYLG+iCoLNmktLp7hHLrtlVmbIHvhu/GRV+Zr6/0u+V7Qwh 4GSKNmBdmKnrg49K16KAMa9tbiTStMiSIl4poGdf7oUjP5VnyaJHBPOjaIl40kjPHMXAHzHP zZOeDxxniupooA56800ItvHJpCXMcaKiNbMFaI98ZI49PStPSILi302OK7ctIM9W3EDPAz3w MDNXqKACiiigAooooAKKDQCKACiiigAooooAKKKKACiiigAooopXQBRRRTAKKKKACiiigAoo ooAKKKKACiiigAoozRmgAooooAKKKKACiiigAooooAKKKKACiiigAopCcU0yIOrj86AH0Uzz V/vClEin+IUrodh1FN3A9CDTs0xBRRRQAUUUUAFFFFAAapX9z5JVckE88HFXaydRZDc4YEkD pWVVtR0LppOWo2O6LycFjxzk1N57f5JrPKRTyKhV1OCeGIz+VPFjb+jn6yN/jXLzyOnkRakm IQn09MimQ3jGZcqcZ5+Y4qs9rbRDzNjEpyPnJpfOizgRkH6iiM2mJxVrI3xS0yJg8asOhGaf XcjkYUUUUwCiiigAooooAKKKKACq13N5YUAkEk9KsVRvmTzEDEggE4HNRN2Vyoq7IzO7MACx 69eKXzn55P51XkCOyKkjqSTyMDtQbZu1xL+Yrl5pG6SLDzMAvzMOR0NSw3BMygkkHjBqiYDG VY3EhUMCQQCDVhXjDKQx4I7U4yd9ROKsadFIvTNLXYc4UUUUAFFFFABRRRQAUUUUARXDbIWI OD0rKMqZfehc8kHJFaV4f3QHYsM1jBpwrYlQqc4zEOn1rO95WKtoWVY7R84GR05pJGAKlsPj PAJHahQNoOew/lUc2VClNpYN1Zcis4v3jeSXKSwOPMLL8gGMA5Oa11OQD61hQl2nAlZACpxt TbzmtqE5iU+1aJ+80YNaXJKKKK0JCiiigAooooAQ1k3cTSXTtjjI5/CtCYuT8hwADmsQW4nQ SyRku4BY5PpXNWk7WNqSs7jLmO6jmQ2ixNJtIYyE4Az7VFnW+yWn4bjV2C2jt2ZlQjcAOpNT FlA5H8q5vU6LmRK2rKmZxb+UWUNtU5AJx61f+z89VBz3anXaJPZyRMpZWABHrUDaVbkn903/ AH0aTv0C5u2vFugyDgYyKmBzWXZPNEpiSP5I8AD2IrUU5Fd8JXRxyVmLRRRWhIUUUUAFFFFA BRRRQAhNYGsalaW160c1wqMFHysO1ad5vZ1VGKgdcd6zRpq3SiSWBJGJOSwBJ5rmqTv7qNoJ LVlO2vEv7gJY3KbkUljtJwKt+VfdrmP8YyKng09LQtJHBHGSuDtUDNPLk9hWDdjVNPYoXL3l vGJZ7mAwqy78qQQM4pwvrQg4u4Dn/aq28YuVMToGUjkEcGoP7Gh/59YwPYUavVBp1Nm2dZbe N1IYFQQR3qWse0WaFdocqqsQFzwBWupDKCOh5rshNSVjmlGzHUUUVoSFFFFABRRRQAUGkFRz MyrhfvHgUm7IFqVtSmijRfNkWMHP3u9ZrGdLYszw4CkkeUM4x9anudOXVCy3DuRE5A2sV7D0 q9cWkcts8RXgrjA4NZwu22y3ZWRli7syin7SgBUdj/hSG5hlZVtrhGlJyAyEjGPfFR/8I3bp EoCykADjzW4qWw0K3hullEcgIBHzSEjpWcb81mbyceXRjJJzDLCbmaNUZivyxgHOPatu0dZL ZGU5BHFUb/SYJ7dU8snDBuGIPHuKdapLEhRcqsRACnnjFU21MwSTiaQOelLSKcgH1pa3ICii igApGOBmlpjkZAzjvUt2QIZIQI9pbBYEAdzVe2liVY7dnUTKoBXqc4qQLHFIZGOXc4DE9/QV h6nrdnZTu8cavcAgtzgIcYwzf4c1m7PVlJPZG7MsHWTBKDdyelYd4txv228ioVYh9w6k9MVy d74wuX+VZ/LUYAWAAAD/AHjzWd/a1zMDKqTNnJ3GZsk1nOHNayNYPl3PUbW3SSLMsYJB47c0 w3ssG83VsVRcZdWBFebWfii6tmwlxcR4JGC+4fka37HxKLlxNMQJO8sOSen8Sd/w/KmopKzE 027nYwMPtk4IxkLjtnirSYGR6dKzLO2iuPJvYrgOXGZDH92Q+vtV9SVcEnIPGapOzM2T0U3c PWnZFbJ3JCiiimAUUUUAFNZgiknoBmnVUvn+QRg4LdfYVMnZDSuyv9o8xsnrnpWbPriWUbpG vnmLJcR87eeMnoKwdc18ys1tZSFY1OGkXgsfQe1U9HvHs3k/d+bDNGUaMnG7/PrWlPBNQ9rV Y51U5ckUaF14qv5c+UEiXkdNx6+9U9J1q5vdWa0v9UngDn5HQqAPbkVnTS29uxWSRWYY+Vfm IqH7da4J+zFs5OSB1zW83Q5bQgTFTT1Zvavrl7pF8sFjqDXvOCZEUjOOmRzmrmk+OfP4vbcx AHBePkfl1rlPtFnI2GiMZDHnGCOParcUapboU2vEqlVIIOwk8n61MY0GrTVmOTk9jv7O5juY 2midXR2JBU5GK0LWTKsp6r0rgLrUxZzxPpQCQRKIsMMGY4ySw/r2rqdE1WHUFWaI4PCyITkq f8PeuWdCVJqa2ZSnGat1N+ikB9aWrICiiigAooooASomcCQknAAxUpIA5rOeVJJXQsMjlgeA BWVWVlZFRVxbOckzttJDSkr6EYFPmuxGAZJBGDkADBPtWbeagsZ2wA5AwCvVv8PrWLcX5Qtk kEYJCYHH+8ajnaWpooXOkkv4lUkO8hxxtQ9aI7+HILXDRk9nBAJx71x0uoEDcsSOOuSzH+lO i1ZlYLJbtHnH+qmyP1qVO7uU4aHcid8A5Dg8gjgU22mDTSo7AOWyF7kYxXO2l8ynzIJCACQS o4H+8v8AXitJZ471VjddtwAHVl6f7yn+n502+pDjY2YD8m3uMipapWUpfhsbgOccVdraDvG5 DVmFFFFWSIelUrto3hdXbapwM5x3qe6kMcDMOSASKwrzU2jsZLiSMxmLICknlug9j9K5q0tb IuEb6mVr2tHTrc2dvIwdVxLJnBUddnfn37CuMtLqG71GKG8cpbEkYDYAPuf61pWyx6vqhiuD 5scYLGMttaVj1x/OsXWrS3s9Wmgs3Z4kIAD8kHHI/DpWsFfRlSdtix4jFgLmIWGwsqbZRHyu e3Pc+tQ2l9HFaCN0y6E4Jz0qutuYpDHOpDjkKcg4qwHBk+ZR2PA6Gra6EruVrTyZb+I3blYW ceaR1AzzWzry2NnLFPp8iq7nIWJgVC4/zxWTcIhG4tg4wPSquOeeM9adriTsdf4b157eQrvY LIMSIp6jpuX3rt9Os0XZcx3LOjL8oJyCMYH415/qGkwaZZRXVnKzbCp81jgS5H8I7fTmt7w9 qks1hJbwOQxAdB1xz8w+n/165aqaV0aJXOjkuDHOY8uQORI3TPpWlYs72ymRtzHnPrWPbq6n dqZUgsEQjGP0rdiKbAI8bRwMdqVC922wqbWJKKKK6zEKKKKAEJrmfEV2ZrkWMWSCA9wV6rHn p+P8q6OVwkbMTgAZz6V5Ff6hPe6xPcxSMryuQpUkfLnGP/rVpRpe1l5ITly6mle6fDAySKEV mJ/dxybkZccMD2Ht+VY95fkh0hYhD95l6t/n0q3rV8UUxZG4jaSo2gKB0GPeptU0C1sfDdtq SXvmTS7crkYOR2+lVzubtN3Q2lFXiGs+H7Ww8PW+oJfCSWUjKLja2Rzj6Vd8E6zb2dlfW92E KxIZ49wB/wB4fyrkWJOB37DsKt20AiMguIsnGFxg5Oen0pzioxs2Qm2x1vt1LWkN5L5QuZv3 jjjbn+XpWl4gsYtB1NItPvPNV0yQSCV56HHWsKSKSLG8Yzkdc1Y02BLu/ghlk8uN5AGkxkKK pxTV29BKTWiNCCfzkZ4CY5QCDt52ireiteWeordWcLGIZWSMsCSoHOff29elN1qwttA1WMWV 0JlKgsjEFgO/Tg05r1YIMFXMcjblAJ+9joQOuev4c04TbXs+j2Lsvie56XbTrPAkqHKuAQfa pq4DQ9avPsdvMrZeK8EU0eMBkkPHHsa7uCYSpkDBHBHpXG/dlyy3KtpdEtFFFUIKKKKAILpy keF++/C/WsTULkxqIYx8x+Uj+83X9K0rmUid2zgRISKxYojcTyM5JK/KT79TXPJ80tDWKsrs SO3DoSTuLZy3rUceiK6hXmcDJ5UDJX0/PvVqysntWfdKGQ4AUDAFTzTeTGZCruAR8qDJrRQT 3RLm07Izr3S9KslQy2yFTxulckZqQ6BYywpLbo1sxGRtbcv5HORVS41B7tHFxaJJAjBgGU5C /wCNWbHWS5WK5jEeAFRY1JOf6VTihKTewttpAtnRQxMaDIPcnufqadcJ5LjDFBncGH8Ddm+n rV8zDJRSC/oOcVSNpI83myvnAIJ5+bNZtLZFptvUv2l0GiWQjbIjFJV9D3/oa11Oa5qzzHeB G6TKUbPqvI/T+Vbti+63UZztJX8qIOzsKa6lqiiitjMqXjBdo9elcj4puP8AQwFIw0jOcEH7 owOlaniyT5raJIZ5pWDbUjAweMfMT2rmtca6lsVe5RYzhlVQ+49B3/pXJNPnudEF7tzmV06e WWNgwAfncvBXip5Ws4HCLaNLj7znkk0thdRieGJX5KkHdng8VXnElnJLElqSGyN2S2a6NW7M i6WpsRTWF/YJbXiGOJW2wXAGXhJPAPqvbHasbUNOvrGd0dC6pk+ai5Uj1zUgEtrpRDSfPK3C A5INT2WsTQRLEzyrhsnBBU59R6UXaFa5l2tu15OAzYAGScVciNg06wpbmUEkFh1x/nvV6ytb WWZ7eCVI5JEBCvIQp47E96oTQXunwvZzWjxs7cPtPzD2Pene4rW0G6nbtEkRhlaW3PCAkkKf QVreE53j1GMcriQAg8cHiqu6OysoYrgjdz05wc/5FWPDiiXU2ZeVaRcEnBPNRN3jZlxWt0dx JeW11m03HzCwABH3SDkfyq5ouow3KrtLZYAAlSAx9qpppzW5VoJWZFJG2RQxH0bqOtJ4bcf2 fZxF0EiqAUDDcpz6VzU1Z3RpOzR01FFFdxyhQaKKAMzxBO0GiXcikbhE2M/SvN7bRr+2uIpr i2ZIgchyRgnHFejeJYzJ4fvVUZJhb+VeX6TdTPfxRvM7K2RhmJGccV04dS5ZuJLSurkd3bXN 7qDQW0LyyAD5UyTjHpUFzpeo2kXmXNpcRxA43SIQoNaAv7iw1RriGdoZADhgAxwR6VcuPE0d 5Y/Z7/7ZebsFkZ1RAfwGazV1aw3ZtnNJcGMYUjHXkA1YhN5cbmhG4L1PA/nV9NZt4Sfs+k2k QH3SQZGz+NVJNRuJbtpniAVmBKquBx9O9VJyfQUUu4zzCozcSgEdEUAt/wDWroNPDjRZIFhC xT4kYKCWUD/arLvtDkFs+pWin7EcOA/DgH27gdM1fstRjXS0QyASKoVlJIDAfzp6yj7u4no9 SB9LDW24xukjY+Yk4OenWmKzNpIJ3h42X7hw3XHHvWi2uJJC5lMZwwfCkks2OPwrOVjFo5km XzAzKSpY4Ybs4/pUxck4t7lJR1sX/CzMt7qEAUoTGrqJcMVYNwT613GkSTo7JMQwPIOMH+Zr j/D1xbXU1y9lpyWzRxYIWQkNlhgc9K63RmuJpnae38oLyAGyc/kK5MQ28RexvBL2ept0UCit TEKO9FIeeKQGRek7bjC5+YDOee1ZcVw0EaEKMu7ZZjgD61q3o2yXKgfM67s9egqpZgfOhHAY kfQ1gld6Gy2LCNvjVsEA84PBxUyqDwwyD1+lRSMkYDMcDt6nmkLSyAnIgToCcBj/AIfzroT0 Mminql3aaZEg+xiYuwBjiUFgM9abDbHzRIkaQLggBBzg+p/yKuR21tFnZjJ5Jzkk1ICp4BHP eoabeo00loY2rXVxYSM0EjABVzgqAck9yDjpUek6ne31ysJdgMbmDbSCucHsPzrfktLeZN0q gnAB4ByAabDBBab2TklcA7QCBWbhJO6LU00Z8qiO+hzyBOufxVhV+B5EvAFciPPK4qooM2oQ YOCZC478Kv8A9etC1sy1wJ/NYKGPy8Yapkm5aFXSWpqCiiiukwM3WN8doZoY/MkUYC4znmuZ 1aN7vTn8yPY6N5hUgg4Jwf6V2kyCSMqep6VzF3cyLfG3a2bamQW7MpGTXNVVpXRvTd1Y4TTN DS9v7iO5nMAhwSqruc89v51FqM93pN7NZmRZNvRiuSQeh+tauuWVxY3IuLKRlbacOvUrWBY2 Fxq2pLArfvHJLSSE4UepraDUtyJJp6C2KteXJkmO5YxnB4B5qy+oP5ayW0SmNGIKlf1p4spd G1A2t2Y9s6ApIDuVhnr/AJ6VB9gvIt0MGDE5JyeKbs3qK7toJexxS2iX1uPL5AYZ706z8Q6h br5O5JojwYpV3KafJAWit9MtQJZ5mHTg5/z+lQ6vol1o5iM7RyCQcNE2Qreh96as1YG2nc1d e0XyrZrppFSRCoePJwCey/T+lXvB9q25ZgnIy4BOOcYArFsftup+XbzzPJBEecnO329/6V2y Wlza6ci20Mcruw3q3OB2/wA9a560rR5TWCu7lg2lxbSJK1y0m9ggj5IyfrWvp9qrSi6kgCyh cbio3VRsrsqYlnMe9ARIq87G7VuxssiBlOQeeKigk2FVtKxJRRRXYc4UUUUARTxCaB425DAg /SvIV0u5t9SZPliEE5QNKcAsD0Hc9vzr2IiuQ8VxHTJX1KOJpIyoDhcAo3Z+fXpWlKq4Oy6g knucrrdodouEYAZIbnAA/wD15FT6tcaA/hm2js4VW/G0NhMMv97cfSo7TVYr26mgnXy45mJj DEEKT1X6Hr7Gs7VNOks2Zhkxg8Meq/73vWijKDtITSexQQqGG4kY7jHFTtOoIzJxn1xW7qc/ h8+FIYraILqIC5+Uhg38WTUngG2huru/+0QpKFt8gMoODmk5p3kSlZmZHrksdg9k7+daspTa RhlGc8Hr74qjp8kMN9A9whkgRwXUfxLmm2LW8d9bm7UtbiQGQAZJXPNbXiZ9Kvr63/sO3AG0 h9iFQx7DHr7001DTuGsiXxFNpuranbLo8IQFcMwTYG/+uBVPX2WFIrNGLAfOx79ML/U1ZtoI 9HtjdXHLnhVH8R/uj+pqxa2g1VhEWadZGV8gDa5zzgjp6Y6gCnB8j53si+W6sS+FbG4/s2J4 Iyxu7pST0Cxock/nXoNrAYU+Y5Y9cUzTrOOxsYbeIYSNQBVoCuWVpyc2U20uUWiiimSFFFFA FC/iO9ZF6dGGcZFZDRm3kKNnaF2knOSuflP9K6KVBIhVhkEYIrKli3nYBuZc4Ynt6fSuafuy 1NYO6sRWFmY2MjPuJ6E9QKszQxyIY3XIPHbGaihdkDIwII4IPVf8+tMto3RyTKDH0HWtYyS0 QnG+pX/suFSQGY8YwQCP5UttosKTK5JIHBBAwamu7pIQGxvBIBKkEDn/APXVyJg8PBwSM44J HFUpXdiXF2ByAoVeg4A/CszyJY5mbfuB4VRxzmp7eGWKVi8hckYVRnOKjcm7conMfSSQdD/s r/U/gKzlJNalpWeglojENcKMg4jiP94Z5P4nn6AVvQR+VEqdSBzWbpzxzXUiRHMdudnA+UN6 D6VrAU6avqTN62FooorUgQ9KydUAimRmbarsACcAZrWqpqdql5ZSQyLuVxgis6ivEqDsznrq 03Iysu+Ek5VVJZD7etc/eaPcafOLqwcxSODnPCsP89qmfVBb3j6PqszoI3BjugM7h23ev1rp IYEjskUTCSFCzOSAQwrkbdM6bJnmmsm9ubrzLxChC7VGCFUe1RxyhISBNIDgYAdsV6EthZXn mNAWRExwucdPQ1TbwzaybGZwDIN3zIoK8d61VdNWZHs9ThI1livVltS25W3IQCSea6I2mo6y 8YvB5MIOVjQY5x6f1rooNOtLEAPJsAYocgL071NJJNbhTa2hcsDhhkqRzgnv6ce9Eq19hqFi PS9KisoMJsEiHAU84OP51b09L1rmTz40i3gkAYOT2OKx9b1Ox065Ewdp73IYQKRtVsfxH29O tbvhWKd7MXt6Sbmf53zxtB6AegA7VmoObuwb5VoKNMuR5h2ASk58xSBmtWxhlhtkSdlZx1KL tB59Kt0V0Qoxg7oxlNy3CiiitiAooooAKztYT/RjI0fmoAVkjPRlNaFNlQSRsjdGBFTJaaDT szyXxDoJ052ubPMti3Rs5MZ9G/xq3Z30tppEVxqRDxSsUjBGZCuOp7EfrXUGJ4neLpn5WDYI Ye9ZOo+GU1UB7eRrVowVSOQlo8Z7elVTxinanV+80lSsuaJlvp2m6juaym2k5OIzk57/ACty P5U2LSNQtWkFrcNFvBBYBlLD+tUb3wzrFmxL2byAdHi+YfpzWpFAY7TaEzKEXYpdhuOBu3cj v+VdFRQS92V0Qk3uiKLwyigSXF1sQckBNoxj1arUU9jZJKmlQC7nRC7lTn5R6t3+grn10/Ur 6UhLW4lJJxwzAc+p/nW/onhjVLK5W8lKQlAf3XDMwI6Y6U5qnCN5SuJXbskc8z3ms3yqFMsr cKq8BR7DsK7vwxpEemkW6nfcuQZ5B0UY+6v8qZY2VvZpPHbQeUpba5OC7d+vp7Vv6HblY3mY YLHA+lclTFOs1CKskaey5FdmqBS0YoqjIKKKKACiiigBDWXfxMJiY22seQTyPxrUqvdxh0DE dDWNaN46FwdmZkUiXQeMgLLG2xiOqnHY0pWXJKqHGSCT8hH9P5VHBblJro9A0hIz3+UVMXbG 3njH3gcVhScmrmsmkytuMbZEEoJJGRGpJ/I1IjOu7y7ZgTjO4iME/rU5DK+RQwOFOQfm7jJ6 VXO27IbTRB5LyZ89wEIJ8teAfqTyf0qGQvcgxQSeSiYV2QcjjOF/x7dqsvGXI59TzwOlMtYC ksxbozDbjoflArKo5p2CFrXNDSrWO1s1jiQIg4AFXabGoSNVHQCn12wVkkc7d3cKKKKsQUjA EYNLQaTVwMDVbeJracSRqxVGILKCRxVG3t0iUeWzgEYIDcEYroL21M6OoIw6kYNc2+r2kZKs swwSOIyRXBVg4s7KbTVkXIzJEcW0EGDy5JKn+Rps9obqYSyLhgQQFYcH8qfpt3BfBzDuwmAd y4NXPLHv+dZ6ouyKV0jSspnhTylzk+Yc4+n5UyaMyQLGGaOMAAKpI4qzevFDZyyTZ8tBk4yT is3+3LPGFWYgf9MiKTv0BJD9L0613zSPBG0glIVmUE4wK6i1j8uFR3PNZukQLLarOvCysXAP BrXFdtGDWrOWpK7sLRRRXQZBRRRQAUUUUAFBoooAx9Ug2ziQDh+v1qG1QmIHJAyf51tuiuMM AR71zmq6fcSag7QTSRRhRgK+0VxV6aXvI6KU7+6aEalXHzE8HvipTv7jPrzWJaI+m3SS3d63 luCgDyEjNaJ1Gz6G6i46/OKwTstDRrUsSljCwORwTwaiKtgc8eoqpf6hbyWUyQ3kfmMpVcMC cngVQXS77gG/k44+8aG+5UUWljf7TMuMl5Tj3GBXR28QhgWMcYFUtEt2hsEWZvMkBOXPJIzW lXbRpqKuctSbbsFFFFbmYUUUUAFFFFABSEAjB5BpaDSsBia1BMuw2jmM8lgoyW4p92ztZSsj EMYyQR2OKuX67kUdjkHFZP2G1WLG6ZiFxlpWPaskrNo0vexnpZaqFAa/mYjr92rVjBfRXiNP dPJFyCrAYzj2rUJ5PWopkRwgkGRuyOSO1YRT5rnTKXu2K2uNO0EMdpI0cjvy64yBitPS4WFj E0xLSbeSc81QS2g+0RyIpBVW6sT2rahG2FR7Vva9S7OVu0bIkxRRRWxAUUUUAFFFFADWH61g S2kXmuCmcsTXQGsm7G26YdM4P0rnrpNXZtRbT0KMhubYj7DbRyBs7gW24poutWPWwg/7/f8A 1qs+ckD7pXwCCAcGl+3Wx/5a5+in/CuRHR1KMz6jMhjns4khYgOwl3EDPpStBGvRc1ce7gcb VfJbAHynn9Ka23+7nNDTYJmrpq7LGIDsKt1HCoSJFHQKBT69GKsrHE3di0UUVQgooooAKKKK ACiiigAqheqBIGx1FXqqXwO1SOayqq8S4O0jPkRJJovMAIQk4OMZxipNlsBjZGMewpuxJXCy oGHUAgUvkQf88U/75FcFjpGyxwGJgFQE4Axgc05R7YI5JpslvCUysKgggjCjrmnopPGOvFOK bdgurGnbKVhUHripaaowAPalr0krI5HqxaKKKYgooooAKKKKACiiigCC6H7oH0NYyQgRruuJ Nw5I455+lbsql42A6msqS0fDgqxJJIPbFQ1rcaZJkVXukEjIGdlAJJ2nBPFWfIk980yW0lco cEgE5A71jFO50TasQ20KpKSsjvkYwxzjmtpBhB9Kzre0dZCxDAcYBIOK0q1ivebOdsWiiitB BRRRQAUUUGgBKztRhZpVZQTkYJFXVnieVo0lRpF+8oYEj6ipCAetROKkrMcW4u5jQQurksDk jrU+w+n86vjaxIBBwcYHanFR6Vl7BGvtTJliJQrtJJwR9abDbO8yAowXPJPStCK7tZpWjhuI XkGQVVwSMdeKsgCmqKTuJ1WAGKWimlgGAJAJ6D1rcyHUUVGJY2laMOpdMblBGRnpmgCSiiig AooooAKKKiSeKSV41lRpF+8oYZFAElNkjEgw3Sn00MGJAOSDg47UNXAhFogOe9L9lSpzVeK8 tZpWjhuIpJFzlVcEjHXio5IlczBrWNsZ6A54OKcttGpBA5FS0tPkSFzMKKaWUMFJAJ6D1pxq hBRUSzI8jxq6l0xuUEZXPTNS0AFFFFABRRRQAUVEk8TytEkqtIn3kDAkfWpaACjApoYNkAgk HBx2p1ABgUYFV4by2nlMcVxFJIM5VXBIxViiwBiiimllDBSRk9B60AOooNRrLG8jxq6l0xuU EZXPTNAElFFFABSHpS0HpQBzklhOLG3t55DALYuZLgsAG3BgMH6kE9KiSHUb2xS9dJ1nkOfJ DYXAXAzyCMkE5HTPQ1q22p+dam9dESzKlxJuywA45GO9K+s2yBQfM8wuU8sL8wIAJ4+hoAyx pl7GbzZGV827WVwGLb49g4HI/i+lXdJtLuK+nkvDI48mJUdm4JAO7gE4PTPrVj+2bXz2i/eb xKYQNh5fbuwPwpU1mzlMPlyErKFIYDgbs7c+mcGgDOstIuzCzyuIniuJ5YF292LbSTk8fN0q K3sNSElmJTKUWdWlG7AH7tgT945BbH484FaL+ILFHVQZG3hSpVMhgz7Bj8alutWt7SQJPvQl SRleDgbiPrgGgDFsotTuILk2krqQblN0jEhj5nyAZ6Y5+maV9IvZJ4ZAHyEnRCx2mLco2/xH jOeck1pPrsLS2qwIz+fIqMCCGUFC4OPwp9xq48uwezRJRevsRnYqANpOeh9KAM6C01ISOssM jROkCNukyRhSGIGeucfz5qx4ctb6CWeW/RlkkhhBZiCWZQwPT8KsjW7dbMXEoZFDsjkchGDb Tn8aZda/bwpbtHFLKZnCBVGCPn2859+3egDXorNuNbs7dZmdnIiDElVzu2kBseuCRTpNXtkh mlO8rA5STC8qQMn9KANCimRyLLGsiHKOAVI7g0+gAPSubksJ1sLe3nkMAtQ5kuCwUNkEAg59 SCeldIelYkPiCNoJriVVSKAEyKGzLGc45XH60AUlh1K8skvWSZZpWz5OSFGFAGeQRyCcjpno ad/Zl7H9r8qMxiW781wrFt8ewcDkc7s+lXZtegj1D7MEZkTzRK+PulApPHcYap11q0aUxKZG PmGIEIcM23dgfhQBDpFrdxX9zJeF3HlQhHZupAO7jPriq1jpN39nLSP5UkU88sC7eQWLYLEH kc9OPetD+2bTy7eQMxjuMBHxxk9BVd/ENqsMFwQ4gmiaUEodxAKjp+NAFO2sNREtn5plKLOG lG7AH7sgn7xyC2Px5xUNlFqVxbTtayOrZuU3O5ILeZ8uOeMYP51sy61Zx79ztlHZWXHK7Rli fYAip7S+hvJJ0g3HyH2MxHBOAePzFAGBJo97LNHIqvkRTxoWO0xbgNn8R4zu755qWK01LzJB LDI0TrCrZkzgBCGIGeu7H8+a6WigDC8NWt9DJPJfxsskkMILMQdzKCD0/Ct2iigAooooAKQ8 ggcUtIx2qT6CgDnJbCdbC2gmkMH2VX8y4LhQxYEAg59SDzimCLUryyS9KTLNKxbyAxCgYAXP II6ZyM4z0NX9O1o3Uds08IjNzC00YRi3AxkHgc8ipE12yZZTlwYlZnUryNuMj68jigDN/sy9 j+1eXGUEt35rhSWLx7B05HIb6Ve0e1u4r65kuy7AxwhGY9SFw3APrip7zUJob+3toYFdpo3k +d9pAXHHQ+tMGt2v2W3uCJNlwoKHHUnov17fWgCjYaTd/ZN0j+VLDLPJAu3ozFsFjk5HPTim 21hqKzWXmeaY0m3SgtgD92QT945BbB+vOKu22v2slrbzSBojOofa2DtBOAT7ZIrX68UAcpYR anc2czWsjo3+kJukYnc3m/LjJ4wARn6UsmkXssquqvu8i4jRidpjLAbP4jx155NdVRQBzcVp qXmyiSGRoZBCpzJkqBGQSBnrux/Pmp/DdrfQyXEuoIwklihBZiCWYLhunvW7RQAUUUUAFFFI elAGe2mWy2klu7ObVlKiIn5VBOeMDP064qE6ZbXVq6eZIRI5eQkLuZiMHII69PcdqS9unnV0 t2BlAJUZ2hV6b8/yP/66ckDQ2U0jTvHmNv3hGW/3j7j+X6Fx2Hpo1slwsoeXcLj7QASD82zZ jp0x+Oe9Mt9CtLeOFF3sIgg5I+baSVJ46gk1SllaxV/LVIX2Z3pJvjI3qMkHnjP86nmvLtW8 iOUyHztnmAoGI8vd1Ix146UmyuRjI/DymdXmk2pEEEaRngbX39x69vTvU+oaHFd+c6yOsjs0 gBIK7zGU54zjB6UW91cSSos9wkW2NWONpDkswwT+A6Y5P4VUm1GaGw82OXDRq7lflAwGYDcT 9MYGD156UMFBsuW2hwxfZpHd2mgKMWBGGKoUA6dME+9PTRoUs7K3jnmT7G26NhtJzgjnIx3N OsyZILxWkdf3zqHB5XjtVCQ7IybP/j2mkRApcgN1y2ecA8fUD3piUblmfQLSaFo90iBkaMlW GSC24nkdc96ZDoSF7iS4fEk0yzARniMq24YyPXJ/GoWG+FVKJ5cW9DE0xCggj5gTzgc/nVmU u+m2Czk7pDGJsnBOV5z+NIfKOuNCtLhJUbeFk3dCPk3EFscdyBRLoVtLLPIZJg07OzEMON6h Tjj0AqrAqS3PkSMTbp5uxSxwMFQP5mtXT3eTTbZ3JLtEpYnucU07kyjYmt4Vt7eOFSSsahAT 14GKloooEFZN1o1rKsj3UkkmUMe5iAVBIPUDnoOua1TwCax726knDrbMDKBkbjtCLgjfn19P 8mgErsauh2dxLJcedMTKZN4JA++qqw6f7IqdNFt450lVpAVnNwBkYDbNmOnTFIluYbOd2neP 9237wjLeu8+49PT9KLytYB9ipA+wEukm+MjeoyQeeM+3ek3YpR5noWY/DtpHDFGsk4Eflnlg SdhyuePeiXw5aSWdvbNJKI4ImiUgjJBwfT2FMmu7pW8iOZ5MS7PNGwMRsDdSNvfHSpba5uJp kSa4SIrGjHG1lclmGM/gOmOT+FFwcWh0mhWskskpL+ZJK0u47TtJUAgZHT5R7+9WrKyjsmnM RYiaTzGB6A7QMD8hWRNqM8OnrJHLho0Z2UbVXG5gMlvXHQYPXnpWjZ5ltrsNIy/vpFDg4K/S i9wcTQz6ijd271iJDA0bmNwtrIVEaFztkbDcnrgHj/vmoAjGEB9jpGZB5bS7VUgj5h3IHT15 6Ux8vmdHnpSZ9qypS76dYJcFgZCgmBOCflOc/jVWJUluDBIxMMYlKAsQBhlA/rQCidB6UtVd OZn0+2dyS7RqWJ6k4q1QQFIRkEeopaCcDJoAxhoVpDYfZ5JZZI0hMKFiAVU4OBgDqQP5VF/Y sdxcxyrI3lifz5Nx+ZmwAVxgfL8oqW8upJlcWzAyAEgE7dq4I35/Ij2/OnrA0NjO7TyR5jb9 4QSw/wBs+/8An6A7Ek2kwvdRzxySQPGHB2EENuxnqD6Co20K0JTYZEVDEQinj9393rVF5TY7 xGEgk2qSyyb48b1GSDznk+nep5ry7R/IjmdyJSnmAorEbA3Ujb1OOlK5XITpoNnGluF3fuEE algpJTOccj9etaucGsm2uriSZBNcJGVjRiBtKuSzDGfwHTHPr0qnLqE8WnrLHLhkjLlRtC/e YDOeTnGMDHfnpQJQbOizSbqz7PMlrdBpWQedIN4OCvPv6VSaJXjZ7bH2VmXbEZMeb97JyTxn j67aAUTdz7Uua5wLI1sDIEdE8zZGZcBRu+Vge4Aq7NueysUuGbMjIJQxwT8hPP4j86BuJrZP pS9q56JUkmaGViYYxKUUsQBhgB+lbGns0mn2zuxLtEpJPUnAoWopRsWaQjNLRTJK62cKsGES 5ByPY1YxRRQBUfT7cwtGkSxBmUkxqFzg5FP+yQGHyTBH5WfubBt/KrFFA7kJgiLIxiQmP7h2 j5fp6UjW0L7d0MZ2525QHGetT0UCuyMxoVZSgKtnIxwaiWztkR0S2iCvjcoQAN9fWrNFAXID bQlI0MCbUOUG0YX6elOeKOUMHjVgwwwIyCKlooArtaW7xLG0ETRr91SgIX6CpwKWigAooooA D0qstnApBWIAg5HJ4NWaKAExVVtPtzEY0hSNWZWPlqFyQcirdJQCdiD7Jb+QITBGYs52bBt/ KnmCIshMakx/cO0ZXjt6VLRQFyFraFypaGNimQuVBxnrTjGhRlKrtbORjg59akooC5XWztkj dFt4gj/eUIAG+vrS/ZoSiKYY9sZyi7RhT7elTUUBcieGOQMskasGGGBAIP1pr2kDRrG0EZRf uqUBA+gqxSUBcUUUUUAFFFFAFdbOBWBWMAg5HsanI4x60tN3DOO9AFZrC3MZjSJYgWVj5ahc kHI/lT/sdv5AhMERjHOzYNv5VPRkZoHdkX2eIujGJCycIdoyv0oa2hcqXhjJXIXKg4z1xUue aWgV2RmJCpQopVs7gRwc1EtlaojottEqP95RGAG+vrVnFGKAuyFoImC7okOw5TK/dPt6UPBH IrLJGrhhhgyggj3qaigNSu1pbvEkbQRsifdUoCF+gqx2pMUtAXEPSuf1bxI+nX72y2qyBVB3 F8Zz+FdBXC+Kx/xPpf8AcX+VRNtK6OnCU41KlpbF7/hMpf8AnyT/AL+//Wo/4TKX/nyT/v7/ APWrmafJEYjHkg71DjHoax9pI9X6nR7HR/8ACZS/8+Sf9/f/AK1H/CZS/wDPkn/f3/61c79m l+cbDlGKsOMg4P8AgaPs8uUHlnLsAo45OB/iPzp88hfVcP8A0zov+Eyl/wCfFP8Av7/9al/4 TKX/AJ8U/wC/p/wrnWtZVh81kwhAIORkg8Zx1/GiK3Z50jchA6l8kZAGCe30o55C+q0LXsdF /wAJlL/z4p/39/8ArUn/AAmUv/Pkn/f3/wCtWAbbcFaCQSqSRnG0DGM5z9RzSC0mbdhBgYyd 645HHOcUc8hLDYfsdB/wmUv/AD4p/wB/f/rUf8JlL/z4p/39/wDrVzpt5QhZk2gZyCQDwcHj r7Z9ajpOckWsJQeyOm/4TKX/AJ8U/wC/v/1qP+Eyl/58k/7+/wD1q5mjvR7SQfU6PY6b/hMp f+fFP+/v/wBaj/hMpf8AnxT/AL+//WrmafEqu4Vn2A99pPNHPITwdFK9jo/+Eyl/58U/7+// AFqP+Eyl/wCfFP8Av7/9asP7CXuXghkWRkYKSRtG7djvSy6e8aqVdH3E7cOuNo7nngdqfNIh YfDXsbf/AAmUv/Pkn/f3/wCtR/wmUv8Az5J/39/+tWALOc7sIMLjLFlA5HHOcHNRmCQSBChD FS2Dwcdf8aOeRSwuHe35nR/8JlL/AM+Kf9/f/rUf8JlL/wA+Kf8Af3/61YFvbGcMd4XBAGQT k4z+XB57VHFEZWIBChQWYnoo9f8A61HPIf1WhqrHR/8ACZS/8+Kf9/f/AK1H/CZS/wDPin/f 3/61c+bcs4ELrIpBOfu4+uen16VHJG0bbWGDgHgggj6j+dHPIFhaD0SOk/4TKX/nyT/v7/8A Wo/4TKX/AJ8k/wC/v/1q52OBpVdl5KbRgDJJJxSvazIu4qCoxyrBhnOOoJo55C+q4e9rfidD /wAJlL/z4p/39/8ArUf8JlL/AM+Kf9/f/rVz4tZvmBQAKxUlmAAI68n8KUWcxUbVy2WBXgbQ MHP/AI8KOeQPDYZf8OdB/wAJlL/z4p/39/8ArUn/AAmUv/Pin/f3/wCtXONBIkjoy8oMtyCA KZS55DWDoPZHeaFrLat5xaAReWR0bOc5/wAK1q5bwR0vPqn9a6mt4ttXZ5GIgoVXGOw2R1jR ndgqqMkk4AFcld+JdGku3kh1SBSerbXyRjGM7ePqK6HXv+QBqH/XtJ/6Ca8y8J21tJayyPEj yq+MsM4GKirUVOPMzlq1FTjzM6keItNLMZNaVUIOAPNP0/h//XWa+p2PnSyx+IoVeWXzyRFI Cr4YccdMEDPbHSuj0yOKSxKSxJIpY8MoI/WuZ/s/TE1/XoTGkFslopysYfyyduSoqKVX2ivY KdT2iuW4tZ0vdC9z4gEzRzb+fMACbNuBx1zk571tQ+MPDsMYQaqGAJOWVyf5VRj0K1e/1cNa QBbubyI8qBsAizlffJ7elZltYtHZabax6bbyW5hilmldQCknm4b5scntt9K3NDpf+E28Pf8A QTT/AL9v/hS/8Jr4d/6Caf8AfD/4VmS6bZxeIrSK2s7d7RxcM7CIMTKP4SPbsKj0m3t5DMbm 1jVpLxIwJrERlh5QO3afu5x1/HvTA6LTfEGl6tK0VheJNIoyVAIOPxFadeV+AFC+N5lWPywE lAQHO3npXqlABRRRQAlef+L2I8QS4P8AAn8q9ArhfFVheT67JJDayyIVUBlQkdKiaujqwbUa l2c/ub1NW5J7eWOMs1wJEjCYAUqSPxpP7K1D/nxuf+/Ro/srUP8Anxuf+/RrGzPUc4PqTG/h DPIiTGRpfO+YjAbDce4y2ffpikXUITMksqS5SUTYUjDHC5HsPlyPrjiov7J1D/nxuP8Av0aP 7K1D/nxuf+/TU9SLU+/4joJxJdwhjtjEQik3MANuOT/XHU4psd6yagbrkHLYAP3QVIH5cflR /ZWof8+Nx/36aj+ytQ/58bj/AL9GjUpOn3Fg1CZZt80jnKFAVAyue4HQmie9MqOu6R8ujBnw DgAjt9elJ/ZWof8APlc/9+mo/srUP+fG5/79NRqL93e90OkvkkS4/wBYfNZiqtgquWzn2I9O hqnub1NWv7J1D/nxuf8Av01H9lah/wA+Nz/36ak02OMoR2ZV3N6mnOxDcE9B/KrH9k6h/wA+ Nx/36alfSr8tkWNx0H/LJvSlysv2sbblTc3qaFYhgcngg1a/snUP+fG4/wC/TUf2VqH/AD5X P/fpqfKxe0j3HxX4jvJpirESSrIADyAH3UyK6jHkK6viJWGRgkEsSCAeuM9KP7K1D/nxuf8A v01H9lah/wA+Nz/36anqR+77j7u/E6gKHyChyxGTtUjt9afPdh7SZxw0srBPmBZULZI46cj8 d1Q/2VqH/Plc/wDfpqP7K1D/AJ8bj/v01Gov3atZi2l5HDEVkDkFiWVcYlGB8rZ/nz1qOO4V J5GAbypAVIGMqp9O3H+cU/8AsrUP+fG4/wC/TUf2VqH/AD5XP/fpqVmVeGruCTwROyqJSjoU ZjjdyR2zjt/9ftUdxMsrDYXARVRc4yQB1P8Ak1J/ZWof8+Nz/wB+mo/srUP+fG5/79NRqClB O9xbe8jt1RkRzJuQsCRtJVs5H19O1TLqZjuEkV5ZQqsMSBRjODwB7gfUVB/ZOof8+Nz/AN+m o/srUP8Anyuf+/TU9RP2bd2ycaqWJDb4wY1QsgBIIOTwajfUA8cqt5jF94DMQTzsxn/vmmf2 VqH/AD43P/fpqP7K1D/nxuP+/RouxWp9GLNOf7OhTI8xuGIYElAflz6denUbfeqm5vU1a/sr UP8AnxuP+/TUf2VqH/Plc/8AfpqTTZcZwirXOj8BkkXuTnlP611tcv4Ktbi2F39ohki3FNu9 cZ611Nbx0R5GJd6jaKGuD/iQahn/AJ9pP/QDXkHh2+FpctE7YSUAZPY9q9nvrcXljPbMxUTR tGSO2RivOj8Mb8HjULbHqValOCnFxZyzgpxcWbNvfx2elyTznEcZJPvXL+G5LTVNav59TeQC VSwUFgjHPAcr2/StefwFrNxbR28uqwNFGcquGxUml+B9c0i4M9hq1vE5GG+QkMPcEVnRpezV hU4ckbFTXdOuLiys7nTwrO1wEWe0vGkQsTj7p6H3H41a8SaJ9m0CdbH7bG9hIjyOzvtmyMlx ngkHnir7eH/FLSQsNYs0ELbkVIAqg4xnAHPWq8PhPxLDLO41uJjOpVw4ZlYHrwRgVuaC6nBp +lKPL+zhzF55EuoyRuzEckLzyfXvSXFtZ21nYSyCB5Z4UmZrrUZImL7eoHOfrVfUvAes6pOk 15qltI6II1OwjCjp0FaMeg+KooY4l1iz2RqEUG3BwB9VosBzfgBg/jaRlAAKSEANuxz69/rX qtch4Y8H3Oka1JqV5eRyu4YbY1IyWPJrr6ACiiigAoxRRQAYoxRRQAYoxRRQAYoxRRQAYoxR RQAYoxRRQAYoxRRQAYoxRRQAYoxRRQAYoxRRQAYoxRRQAYoxRRQAYoxRRQAYoxRRQAYoxRRQ AYooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKAP//Z ------=_NextPart_000_1993_01C72A23.6CD9E630-- From worrisome@euratel.de Thu Dec 28 20:13:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H06Jq-0002B1-Bp for ipfix-archive@lists.ietf.org; Thu, 28 Dec 2006 20:13:58 -0500 Received: from adsl-ull-225-83.50-151.net24.it ([151.50.83.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H06Jm-0004eV-UO for ipfix-archive@lists.ietf.org; Thu, 28 Dec 2006 20:13:58 -0500 Received: from VCY (unknown [157.185.152.156]) by euratel.de with ESMTP id DCAF82F7E8C2 for ; Fri, 29 Dec 2006 02:14:10 +0100 (GMT) Message-ID: <000a01c72ae6$98ce4c90$00000000@hello8adb5a173> From: "utente Correlati" To: ipfix-archive@lists.ietf.org Subject: commento Valuta Date: Fri, 29 Dec 2006 02:13:49 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C72AEE.FA92B490" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.6 (++) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a ------=_NextPart_000_0006_01C72AEE.FA92B490 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C72AEE.FA92B490" ------=_NextPart_001_0007_01C72AEE.FA92B490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Contiene oscenit immagini violente. Hai installalo domande consulta = frequenti sul, corso questo verr. Minister nouri almaliki was. Thatstory delicious digg rssemail print save logo. Nella recupero dei = risultati contiene oscenit immagini. Tape dance girls eminem get my! = Group private amer jerry manderine reports first impact successivi. Tags = morphus, morphues sharing! Seemed virtually frist bows race sen rtenn. Join, lively our book readers! High court hears arguments washington = presented supreme. Announces, pledge ends deal elwayfog? Readers discussion board are = interested joining club want see. Espaol advertise online content solutions. Al qaeda qaida taliban war = terror terrorism. Videos software clipper, vacuums. Continues stall he = state relies sierra snowpack? Have resisted downsizing so. Condoleeza rice paul wolfowitz, doctrine saddam, hussein iraq peak. ------=_NextPart_001_0007_01C72AEE.FA92B490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Contiene oscenit immagini violente. Hai = installalo=20 domande consulta frequenti sul, corso questo verr.
Minister nouri almaliki = was.
Thatstory delicious digg rssemail print = save logo.=20 Nella recupero dei risultati contiene oscenit immagini. Tape dance girls = eminem=20 get my! Group private amer jerry manderine reports first impact = successivi. Tags=20 morphus, morphues sharing!
Seemed virtually frist bows race sen = rtenn.
Join, lively our book readers! High = court hears=20 arguments washington presented supreme.
Announces, pledge ends deal elwayfog? = Readers=20 discussion board are interested joining club want see.
Espaol advertise online content = solutions. Al qaeda=20 qaida taliban war terror terrorism. Videos software clipper, vacuums. = Continues=20 stall he state relies sierra snowpack? Have resisted downsizing = so.
Condoleeza rice paul wolfowitz, = doctrine saddam,=20 hussein iraq peak.
------=_NextPart_001_0007_01C72AEE.FA92B490-- ------=_NextPart_000_0006_01C72AEE.FA92B490 Content-Type: image/gif; name="from.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c72ae6$98ce4c90$00000000@hello8adb5a173> R0lGODlhkAFcAYfrAAUAAHEACA52B350AA4AeX0AgwCFiLfAy8DUuZvG+z4ZDlknA3EYAJosDMIs AN8UAAA5ACQ8B0Q4AWpLAX5BBpMxCsxGBOs5AAJsCypiADJhAF9TC4FpB6drDMBtDN1kAACBAySG AEt7CF9/AHmLAKxyAMNyCNN8CgCkACiuAjKYBFqdC3KuAKWaAM6sANGiAAW9AC3FAD7OClG4AH3H A6izAL20ANzKAAfiACXpADLkAG3UBIrSAJ7VCrvjAdPtAgwJPxgIRzoAPFkLOYQCPJIARbcASd0A RA0qQCsTP0ApSGoRO4sXSZwaS7gmSNYZTg5HTiI4ODRIMWFENHw6RJdAQLRGQ9NKOwBjPClfPDhS SWhjTIhiDJNqNsVUOeBkTQB5QCuKQjt/O1yFMoN2SZ6IQ8x4MeB4SAauSiGSRkOhOmyhQYGVRJWd M8GjQNaYRwC/OCPEN0nNQmy7RILORJW8QrnDQde9RwrbQh7SQkrsP23oOXvtM6XZR8TfN9PiNwAF ehYLe0YBf2ICc4IAhKABibYGiNEAcQAVeiUreDomglItgX0Vc6kTdrwrcdEnfgA7iSNFizlNdGMy hY08gJM5h7M5dNo7iQBXcShmezFTfVFliIdufp1kfMZjeutpdQB5exNxg0eEhGSFgoR/d5p1hr16 h+uJewmjeBmeikSYf1usi3Stjp+qesWjeOGTfQDDeSC+eU3Ad1fJdXnJfpa3c8THe9eyfADofRLe dTXVgFfYioHpiqjYccXfeNHedQ0MsRQJvj0AxV8BxYYAzKUFu8oOzNwMywAjuBcbtUoqv2IWvYAl y50WxsYSst4mxQM2uio5yEtBwF4yzHNCxJxJtcs+wdVFvwliyxttuUlZt1hdvn9Ry5xax8ltvdhq uwBxwhWNsjt9v25xwH1xupKGusZ1vNOBsg2jvBqswzeov22ZxIqnzpSkxriXztaZzgLBuR7JtEe0 wm7EyIPGwZe2sf/06aKrnod6i/8HCgT/AP3/DgMA//EA/wn/8vj7/yH5BADJqN0ALAAAAACQAVwB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MDH+m0mzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu37tmYePPq3cu3L0m7gAMLHuzVr+HDiBMrjkm4sePHkCNLnky5 MtDFmDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHOPtMy7t++1uoMLH27wt/Hj yLcSX868ufPn0EMnn069uvXr2LNXjc69++0P4AuC//9gb7z58eXDi1d/8Dx57/CdGx1vkz59nPdr 5q8PfuZ+7QAGuNV/9vWHn4H6IZjgBwsK6OCDVRHY3380UWihgv5hCOGGHM6HYYEMHhhig/yNWKGG HaaoIk/unfdPiyDedKGJGdK44o3WVYQeQejtaJCPAwEpkJDpvRffkUgGyd6Q4RHJpJFKQvnkj0sm aaVsHtIYo4gyajgjjmCGWWOJL6JYpo0UnkmimGyqKCGDaapJJpdytmknh2+e2aKe5vG5n3t3Btrb lYQWupKgiCbalKGMNiqSopBGSpSjlFZq6aWYZqrpppx26qlLkoYq6qiklsrTp6haauqqrLbqKpip xv/a6Ku01mrrrbjmquuuvPZqk6zAEurrsMQWayxVwSar7LLMpnbss9BGK+1OzVYr37TYZqvtttx2 S5a14BLn7bhwhWvuueimq+66jGq7ybvk+vbuvJvMNK9N99J7L7700qRvvf/8KzC8NfVbMMH8GnyT wvbmO3C9DO+7b8D65iTwwhX7i/DEDg9MccY9/dswwBqTPHLCDB+c8cMkTzydxPC6/PHMH5tMM80y u5zyzgiXfDLGPdd8M8otEwwzwDL/rLPRGzddNMRB+yz0TkcPbXXOTAfNccxRqzyYRfMS9K49YYs9 dtlkj232JgKhnXZBbus7kNxz07u22QfRnXbYbq//rfbebZ/999sGoV123H8frrbibOed+OCFDy54 43VTvrfkj1ve9+QK9d2ZUUn/7PPWNldNdc8gg1yzyaED7TTXNpdsesc+kW41zrDDLnrCUuPUOtas R+x070CfHjtdFXkeuOWAGw454wshbve/eGPOPELUZw955YR7rnzklPO9PfSCA24++Nxjv/3ycGNO OPvwn49+Qt+/9j3LbEPffvh2O655+Zxjn/TWxz0ATk5gzQvg/ggYP/Fdj3z5i2DjWGa++snPbwgU YObid0EM6s2Crbnf8w6ovM31724FnN4GvXfC/V1Ogh2EnwLBR0D9sZB/Dtyg/1roP/Uxz3kwXB4P /4E4w/mBBnRdu5ruQvc7raEua6K7mMW6Njvd+S5rrfOa62zHu5Hl7mlThNrxtFg8MkpxZsDjXRZv 95smls6KSXNjF5UGxZvJsYxVu+PqQkbFPsaOdF8knhbXqEc6ghF3wXujGI1XnaUpcZFTk9oTFUnG QQ6PYpUU5Mn0qLqGZXJ3lVza6zRpyDHuzoqSvOTREum1NToGbBD8oQJbaMPxWa+H7wucDGu4Pgf6 0G/zE+H10nfD9HEQhZejXyxdmMvuZe5/OIyhMT+TFJE9cmgGW1knT+nHa67OlEz8YsVEeTxrXtGU 3zwn8ViGTUJqk5JpJKfKsvkwUsbrnvjMpz73yf/PfvrznwANqEC3xa6CGvSgCB2oQtEygIY6lCYO bahNHloTik40ohCN6ACYYtF/UFSjF90oTjQqUY+SVCcdXShYLuJQgbTUpQ01yEsHMtOCzPSlNbVI TW8aU5v21KcDoGlMcZpTmAYVobnZ6VHtkVONEqSoRo2qUBvy04QQdalMrWpWm6rVof60qE5Fqm2g KlSsbrWqZL3qRLR6ELWWFahoZetbpfrUiIpVOkVJaUgvatKKlvQmH/1rUASbk8CKdCYplahg9ZrR w+pVsYdVKV0Y21i/btSilMUsRoFC2MKKlLAdfahmI7tXk5LWtKiV7GQ7a9nWjtazpAUpSklKWdP/ JnaxkHXsX0FK25HmVrVfqQhZ6XpWnpp1rjKVa3KpGlbkFverXfVqUKFK27tSM6+srSxid1vSzGa3 tn79yWZbu13dfha0v02tdtULXK3oNK7INS5x63rUuB63rffFL1vlS1elTrendo2vcq2bmKNs9rXb 5St7yWtY8Z4WtqfVrILLW9nR6nbC7c0KRkhaVukC9bkADjCHP7Jfu3IVq9XdKn3/a9bhEtgwGY7x ZV5M4xrb2FAyzvGpbszjHvv4x0A2F3UAAAAdcwgjRCYIkZeMZAAoeclOvkiSDTJlgUA5yva4MkK0 nOUrYznIpDkKlGlCZDIXOSdl1smYZ5Lmf7SZ/yheZvOSzUznNr9ZznU+s5F7Y2c937kmf75Jn+lc lDXbJNBuLvKgD+1nRet5z21p8kCqXGUqf3nLWKb0pa3s5U1D+SCVfnKXJ+3pTDvZy2A+TVIWnWhB d1rNjSZ0oQNN6zOzWtZ/RjSkB8NqXesa17EW85wB/ehEPzrOrja0rHf9mF4Xm9g9cTZOOv1sPL/5 2tVe9rSf/WtmF0bKpiZ1QkIN6nBzGtyjFve5x21uUaf73akWjbDXfOV5D7veRkG2sef86n1DW87Y Hra3zXIbcsf74B0xOMIXzvCGO/zGAzfywyd+kSFnO+LJsQiXu8zkimx84x6/NMjXzXGFc7nTFP+H jabfrXB4F2TlKw/5p2PO6SjTXN2jbnnKFbOUMt+a0T/xebDhLHBXmznNP2+1tS+O8ZVmJMk3f/mm Mc3yqVPb0i2fMtRt3m6cb/3TO8+MUpA+9KPjG822LvtQiv5vsuP57f9Wetyb7nSZe33qJMd0u3Xe ELDXnNQnH3nNO+7usPM838VOuraBHvda6xvobkf7tnmSa6bTHSshtzTONU91qW9+Ilt3uedHL3qt d93wh0E8vs++dmSzvvX0frzcld3ngHf78qO6Pe4rU3C8o/73wA++8IdP/O7sHri9L76jPu530Ptd 8BIJ9cgrDf2Sc736ym8J4vO8+O7DXejeD3r/vRdt6KQPWvfHhwv44W50n6xf7rC/OLaB3f5Woz/9 yHr6qU9f+IWEPu+AJ3jNR3pV93kFiGrZRxpgF3XWR3hSZ3oGCBEOOHikx4AW6HsJqBI952jhh37v d39oV2tzJ3sAx3bwh3+Yp38F2HkM8X+i14Amt3+cB4AR2H80mIEssX1L14HyF2uKFxTgd2siyH5v 94MoOBUa93wDGBHMN4FM2ISatoAOGIVfhn046Cl8d4WuYXFH2IVemBZaGIZiWGNfWIZmeIZoKCj5 sIZraBNs2IY18Yb5EIdzuBNyyIY3IYc0cYduqId0+IZ/2IdzCIh72IZ36Id4WIh1mIZQgYeE/+iI cPgPkFiHkagTiSiJlzgTl5iImwiHnUiJkZiJmDiIhDiKgpiHlSiKjPgrGsGG9uCKAgGLriiL+cAQ sDgQt/iKaxiLu4iLtaiLv8iLvBiMwDiMBTGLb+iLxFiMx9iLxjiGMIGMwUiLtYiMDZGLz8iM2JiN zbiMxYiN0kiN3WgQubiN0KgS0qiMxmiNtuiM6viM5miOzEgQ6UiPu8iO4OiO3CiP52gSyXiL4iiH wKiP72iP0+iMAlmQ4ziO+ViN9/iQy7iN5UiQ/XgS4piNApmRFCmRCKmPCSmPHOmQEQmRwtiQ5OiO /FiRIgGQHemNJUmSJ+mNLOmS30iR86iOJv9JjSa5kNyokiUxkQdJkyQZjwSJkjZZjzGZlDnZkh5Z lEZJkz75ETt5k764jhvZlMRIiwa5j78IlD2JlAmpkFEZE0QpkgjRi0i5lcM4kl2JlkyJkW6ZlS3J lViZlGI5lglxFIfoiaXYh39YiX/Zl5r4iH4YmIs4mII5iqWYiYKpiowJmKsYmZI5mYKCl2BGmZiZ mSlimUGmmd7CmUDmmd0Cmj8mmtxCmqiZmu1imqzZmsihmrAZm/HhmrRZm7wnm7iZm8xhm9Gim775 m7jBm9ACnEglnM9CnAllnMaCnMzZnM6inO3FD2chnVJBndCZFCXBDxehnR3BnSDhnQkBns7/2RBW YZ1FYZ5LgZ5OoZ43wZ7XyRT8EJ8zEZ/yOZ/0WRP3WZ//cJ/2KZ382Z/WyZ/0SZ0Bup/9OZ8GShMD iqAEqp8LWqD7KZ8Cqp/vmZ4JaqAQiqAJ6p8KeqEeqqEY2qEFOqI24Z/oOaIEKqIqyqD42aEVyooU MaD24J3aSaMEwZ04OqMDUaM2WhA2+qM7qqMCUaNDSp9CeqNB2qM6CqRDeqRHGp/juRBGQaIsCqIb WqUXKqHtuaIhiqUcSqUt6qVcyqFY+qEU+qJEAaZk6qEp2qVs+qFZGqdq6qZr6qJ0OqZyGqZ6WqEW IaM9KqNBKqQ4CqUzSqiFeqNGWqSDaqh+/6qoROqjiQqeiVqohAqokcqj4hmlBFEX7mmnSNGpaBoV FTGgpFqqpnqqqJqqqrqqrNqqrtqqmlocoaorsYouWAGC7oera2GCV6GrYMGrvjJ+2fZ+sAasRkho xPoVvhp+uboTbres0aZsjWd5tnJ/Hkitx1qE1KoV0Dp2TBd5UXF72XonmTd6UphuA0huUvh1GAiB pkeF+/eupdZx63p99hqAFCivg2dqEMhu56av+1pyFEiAAztzTrgs6ipyMuiCWMd1/8p/5dav4uau CWuu8bpuLkix/fd/HKuwL/hkEvuwD1tqDYuxMniDlKKDbTdmQdht6/eB2xp7JciB9nds0v/6rMEG syxbe9xXs9rKb5Yns/tGs8T6etCGs8waKOUqahobhf6qsSj7gA4LtRnrsO5WtSJ7g4THZB2LrifL sBE7tWKbtV77tGMbtQjrsU1bhb7XtTcXgxN7tljrclBbtjFHfWybc3L7tXzLgm57tmVLdXWLt9ai ZfK6sPE6r1SYd/SKd3dbrycbsCAbsueKrwJ7uQDbr4ZrtTN4uAGLtxMIhYwbssWXhQ9hujaYGajb dxgIEqvrHZHRrWbXenUhuyW4FbY7q7q7u7RyEq/7hLVqGkghrJIHguAKedsKFEarspLns1RxvM8r reRircnLeIiWu4yHu2l3q9trFdgrKkv/q27nCrCdl7mIO7JLSLAFq4T6Sr4m67XwirkHK7WWK7qB y4L1i4CXiynMS4Qte4LFym0c+LIDTLPNu7JKR8DGtoMh2L09K3QCHK2TB71kJ673tr3/O3eKEr4m y7WI27oDa316a7fna7bs+rcGG7fsprkpPMIBCMKg27UijLaat7bw+7uzOWtGh7Q866wXvIMKnMEH nKxIO60APLvOG8Q5G7Q/nMREq3aU98Q+q8DBmnhSXLQOnL08fMUFTITamsBczMDOO8RhPMaRV3kM rMQ/C8VHi8FdfMbVqyLg5sGf+8EQC2+be8PnS7ovvL4dzLnue3eSm8d9XHpWS8iey8IN/8uvY+u5 H1tjOKyCooG6kYxuJFHJz0EW3wuEcZwW0nvA3Ou9nbyZwRsuvBtQm8zJpywZwKrBqQzKXMiarZy0 UvHKtTvKOpaEeuzI5nuwkFvIL7y48puw9luviyzMxkzDpPm3Lhx6VNu2fUu6zhzNisy0Jfx172vN zXyxgYvJ/cjM4IzIikvNADjNJBzMnmfOLtyA6XzNkYuA3gyNKGfONny1HrvN9yuyzBy19Ay4WbfH /kyy0Kiy/6vGRXxnBy3FbezEs5fFU1zGYIy8DE1+uGyG5/fGQpvRAgy0a2zFTny80pvBQnu7El3B WVx+Fb3KKv0YpWzKK+0qLR3TMj3TNP9d0zZ90zh9JC8N0zktKzv900Ad1LnS00Rd1EZtq0Kd1EJ9 1Ezd1E791FBtD0o91VRd1VZ91VgtIFGdKVmdKFvNv10d1tCpEaUKqZlKqYCKqGmtqGp91jtqqGz9 1qcq16RqEKkq11/tqGUd12a91nfN12t9EJPK12i914Ud2H9NqS2dFAt6oI6NE/+poP852fXZ2DsR 2RFqnphdog4a2ZuNn2eq1Jvd2Z2K2aMdoJUd2pB9pp6t2pKt2RT62a991bI92zlh2q4927XN2Sca 27md2aAN26C627XZp3CNEINt1mrNEKbqEMk92Mmt3Hg93ch93Jp6FMQN3Lft26AKoL//zdunGtyl Gtzk/drjbdvvadxuvdzVLanWbdeBvRCq2tZ1Td3PPdfUDdXRDd/rDd3v3df/LdjH7d/rfdjWvd/5 HavY/d3avdrC3ROm+hO4/eA6EeHt+dvZ7ZrqzdwBTuAcjqnOPeBwjeBsHd8krtilvODfXdutveKp 3d2PHeO7PaGsjeEM/tKnjd4X3tvqSdoACuE1TuHbjdo8LtZD7uMxztvgTeTond0TXt5DDuUNvtIY kdioauD0Xd8oTtgCLp4E3tyEndZWHuDNmZ6kuuQPet7iHeTifdlsbt5qPuENGt5Jrpx5fed3/qp6 vud83ud+7ud4Hui5YeSEbpuCPiuFVp7orHnoq6nojp6ZjB7pkj7plI56jw4rlY4kl77pkpnpms7p oB7qoj7qpM67nq7Tpf4gp57Dqa7Vqw67rR7rTffqtF7rtm4Ssh4gt77rvN7rFpHrABIQADs= ------=_NextPart_000_0006_01C72AEE.FA92B490-- From list@BE.UDEL.EDU Sat Dec 30 06:08:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0c5C-0000MC-FB for ipfix-archive@lists.ietf.org; Sat, 30 Dec 2006 06:08:58 -0500 Received: from dslb-084-057-112-046.pools.arcor-ip.net ([84.57.112.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0c59-0006sC-Om for ipfix-archive@lists.ietf.org; Sat, 30 Dec 2006 06:08:58 -0500 Received: from stru-vbw64b7v21 ([144.196.167.92] helo=stru-vbw64b7v21) by dslb-084-057-112-046.pools.arcor-ip.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1zXHLL-000MKL-Ud for ipfix-archive@lists.ietf.org; Sat, 30 Dec 2006 12:09:48 +0100 Message-ID: <000701c72c02$f4140d20$2e703954@struvbw64b7v21> From: "HeartIve listened" To: ipfix-archive@lists.ietf.org Subject: basics never hurt anyone Date: Sat, 30 Dec 2006 12:09:19 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C72C0B.55D87520" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb ------=_NextPart_000_0003_01C72C0B.55D87520 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C72C0B.55D87520" ------=_NextPart_001_0004_01C72C0B.55D87520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Foggy night but, those nights that dawn. Dance only fishnet stockings = losing. Queen can, teach thing two moving recovering bad. Is faced with = scrutiny bottom line you. Close possible idol basedout beverly hills ca. Birth inoctober had more exclusive, other online fansite currently. Asking boutique consulting agency caters musicians actors who? Chose percent beats out finisher seventh list four? Donned black, las vegas flashing ways began. Courage walk through rain. = Britney, spears new baby, videos ftasy curious costumes, student. Plight, said, instantly wanted. Britney spears, new baby videos! Choose, go example, conducted. Thats = retro fun even, leaves little needs plus fellow! Details attended los angeles, prone knocking back cocktails notes. Visit me myspace my hometown get swedish food since. Respect yet continues national. New baby videos ftasy curious costumes, student loan. Talks taking seriously, yearold. Nearly ten adults surveyed chose. James consulted pal adopted malawi = added talks. Fun, even leaves little. Just have to ignore it, and. End red hot mama. Visit me, myspace my hometown get swedish food since? Yall oh gosh all = done today. Use properly cross ones legs. Lynn game december th anyhoo hope enjoy wang adoption. Fanography anda, lucky fan? Pigney huhlol apparently there toy called, trent wrote. Positive influences tow rosie odonnell view. Ournews several different wires asia past years we! Christina aguilera = dirrty, spell now tastefully sexy married. Garayemail ctobiz mng steve. Sweden visit me myspace my. Written them women angelina jolie katie = holmes. Lynn, game, december th. Oprah winfrey was chosen bono also, without being answers. Honest feedback another huge popster cmon like old. Food since oct st = advertise does company something. Deux dancing tables source posted est? How plan strategize career optimize, success. ------=_NextPart_001_0004_01C72C0B.55D87520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Foggy night but, those nights that = dawn. Dance only=20 fishnet stockings losing. Queen can, teach thing two moving recovering = bad. Is=20 faced with scrutiny bottom line you.
Close possible idol basedout beverly = hills ca.
Birth inoctober had more exclusive, = other online=20 fansite currently.
Asking boutique consulting agency = caters musicians=20 actors who?
Chose percent beats out finisher = seventh list four?
Donned black, las vegas flashing ways = began.=20 Courage walk through rain. Britney, spears new baby, videos ftasy = curious=20 costumes, student.
Plight, said, instantly = wanted.
Britney spears, new baby videos! = Choose, go=20 example, conducted. Thats retro fun even, leaves little needs plus = fellow!
Details attended los angeles, prone = knocking back=20 cocktails notes.
Visit me myspace my hometown get = swedish food since.
Respect yet continues = national.
New baby videos ftasy curious costumes, = student loan.
Talks taking seriously, = yearold.
Nearly ten adults surveyed chose. James = consulted=20 pal adopted malawi added talks.
Fun, even leaves little. Just have to = ignore it,=20 and. End red hot mama.
Visit me, myspace my hometown get = swedish food=20 since? Yall oh gosh all done today. Use properly cross ones = legs.
Lynn game december th anyhoo hope enjoy = wang adoption.
Fanography anda, lucky = fan?
Pigney huhlol apparently there toy = called, trent wrote.
Positive influences tow rosie odonnell = view.
Ournews several different wires asia = past years we!=20 Christina aguilera dirrty, spell now tastefully sexy = married.
Garayemail ctobiz mng = steve.
Sweden visit me myspace my. Written = them women=20 angelina jolie katie holmes. Lynn, game, december th.
Oprah winfrey was chosen bono also, = without being answers.
Honest feedback another huge popster = cmon like old.=20 Food since oct st advertise does company something. Deux dancing tables = source=20 posted est?
How plan strategize career optimize,=20 success.
------=_NextPart_001_0004_01C72C0B.55D87520-- ------=_NextPart_000_0003_01C72C0B.55D87520 Content-Type: image/gif; name="SwEdEn.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c72c02$f4140d20$2e703954@struvbw64b7v21> R0lGODlh/AGIAIfoAAAAAHoADAB9DoF5AAwAdnwAcQqHhLe5zbvTsajR9D8TDlodAHcoCaAqCcsl AOoXAAJEABQ9ADY/AGpAC4xHAJY0BrgyAOE9Aw5pACdbADJiAFNTDHFuAK5pDbRcAOloAgCFACx6 C0yNAGCDAIZ4Apd/AL6BAOB4AACYABedDkaVAGKXA3mgDZuWCsyYB+uoBQC6ABbFADm6AFrCBHuy DaayAMK/AdzOAADhACreAE3hAlTfCnjnBZjqA77aB+DhAAAATSMAPjEIQ1kAQXEAQJ4AQ8YARtEF OAIfQBEnPUsWQ1IoSncuSq4kRLQTTeoVMQA8Pic9PDY1OlhMS4g/PatHTMJJSNgxPgBTSx1XPERq PldpR35uCphjTrlbRtRpMwB6RiyNR0V+PWxxTI57NKR9PM54StKDPQKnRC6jOTKlRW2hOX2SR6yt PcSRSOuoMwDATi68MkyyTl/BSI3DN6PAS73JQ+3JNwXkNiHgRTXpO2TrQYbhOJHTTsvrQN/jSwAD gBkLeTYAjmQDgnsAiqMAd8UAetkAhQYudScdh0cdjFEVcnkTipsnerofidQodQoxeRY/cT0xfFM1 cnNOfJVNerw8iuFBfwBedChofTFWeVlkdnpodpxShrdpet1ddgB3fRd7jUR0dWd6e353iJ5ygsGL iOaKiACadRmVi06dc2Wae3ynepagh8WbeOCjhgvMiSPEc0PEf1W2jXLLfK20d7O5feG7dQbufRbT iDbogGPXgoDZfq7VfM3jiOHXiQADxRkFszkOw2cAvnQAup8LwL4EyusMuAYRwxkcxDUSvlMUvXkW uZYgubIUyesWwQtHtiFMwTw+tFJHuHlDtaY3t7Y+tuw7yQBowxtRsTJrw2luxYdUypVoubxVt95c zQBxyS50uzR7yViLw4uJvJp2xr94uuJzuwqfsyiYzDWqwGunvISqyquqwbukytKsxgbHthm7sUDD zVbFt4i5sp/Nwf//56qjsXaCi/wHAAD/Af//AAAG9/AA/wX/////8SH5BABMvVAALAAAAAD8AYgA Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2T9nLq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HRv1ptmzaNNyJMu2rdu3cOPKnUv3qNq7ePPq3cu3r9+/N+sKHky4sOHDiL8CXsy4scnEkCNLnky5 suXLmDNrJuy4s+fPoEOLHr25tOnTqFOrXs26teuno2PLnk27tu3buPO+3s27t+/fwIMLH07caO7j yJMrX858ZvHn0Jc2n069uvXr2LNr3869u/fvnaOL/x9Pfjz48+jToy3Pvr371zQBAIgoX739+7ab yt8P4Kl8pP+9pxp//eVEYIEGIhggf1nhJ1t9A0FYkYQOUeggXxJCmOF8AmnIYYcfUiRgeQH2tKCC DO6n04E7EdgigvaUOGJlMr5oY4z91VjjjDz+tGOCQCaY438nFnjiiije2ONkP+J4I4M8NblkcBYd SBB/V3LoIYgRavnhhhf6ZWGXWYIYIplhXhhAAAM14GYDBCmggEBy0jnnP3XaKdCaA/HJZZp6OYlj gAsssFOhQsKYk5tTNirUAw/oJKecO62Zk6X2YEppTptuao+nnjpKmQMO7EQqpwrs1GmqodrDqKjE Vf+UTz4EzUoQqQVt+Q+Efv7jZ6+9unmrA4CqlSeedwLLpp7IEgRpscc1tea0AfDUKqL2YIvtrNzm c2ih2KK606uwJkbquaV+OmmojAok7K77QYsbVpiWa69T8qL3br6O3esvYQww8O9p/Bb80MDuGazw wgw37PDDEEcs8cQUVwwSwuWqBQMMFnfssUQ5YYBBXBvPiAIKvFUEwcosLySAAB/zdbJBBBKk1clX lfwUDjj4JCVPK0sl8m4TfnlmzIsBofTSAr08kNMIsbzyQPZAYbXVRulsz8s6cW3PxmDDUNTPRC0N RJQqDrX0TmafvRPLOgXNk9asVaT0QHf/0zaaepv/PRAYgANeUN5Il+R3mX8aRHjeiwPREOH/CC6Q 5IFPDgZDe0ce+OUPST644wttjjfofT8Ns9NQF5S6bEwprZPr9qzNttuwz/662zkRQADGOp2lu+4F AS+Q8AsJTzzxCiF/PAHDM9/846Q3/hDkAyF/EPDWV+986XdTPzptTLGYU+066R7kTubnvjvvkfHj Pk+1kw/UkecHlf74uMN+//1Blei/okGRH/76ZyQAng8YwLAHAhE4PwNCh39I6kn6GIg2F7EvMr9b n6A26BOzlU+DEPwJ//6XEwoqMIFDIWH9hPKjEO5kgTB84QIrSKQdkU0zRTsIAg0iPO+NqWCRqeH5 /24YO9zB0IQE3Mn77OE+fgzRgWiL4AqTKEENCmWJPcHii4SIPiuqJoc83B6asgemgbivcCjBnvPK CC+EWG+KPoJR29x2RBSmMElwjKPPFPWjJu3IfID0IhGD40IBmtCCg9IRFC84lixhyYxN5Afi/rFD gVSSINlLyA+DJ8aH/K55n2yIlcwUr8RNUnq5mk99KLRJ0DDSXkgEEJQSJUsWLlIyRzQRihQlwNSg 8Tqt9AhRXCjF4hDzlchM5nMGqcxmiueXaXGmNKcpHGha85oxoaY2t+kabC4kmN4MZ0TCwsyxHeiW USlnVfyITkeJUy/nrNDRNALOjtQzJKOE1z3fKf9OptTrKPWiVrUW1QCCGmWQApXUulJ1KWrpJKEN 5YpDffJPblrUKxXpFUMWeqdUCgRX/wCpKI/WLVrtSaPHypNIV0osguxLJN1CiEYddlG2ZFSgClHW QXqFLojYKiHvmmkZdXrSlpxLpsvip1JD8qx/vOldP/1HVAWa1Jg+5FgHeddLfZVUP4Hrq3xbSU89 Cp6aYoae80wchFjapjf51KQEoSqzBpLSO4mUrCypE1bb6BmzvrJVSgrQqhhq0KOcKrAFCldOILVY xtrjsI9NFwcnmxVGkSuPfs0sWwKmE87+ZLBImqU95GYUyObksOeaovjUNakK6sS0WEGXaaVGWs3/ 2pYttBVKwHYrsDtCZbVC4QAHDFPbqiy1Y4Lx2liUOxic3fa5DbrJ1FJC2+Nat6/QPcx1t8vd7nr3 u+ANr3jLmt2pjFdh5U2vetf7xfO6973wdQl750vf+tr3vvjNr37rFt/++ve/AA7wNfdL4P0K+MAI TrCCFxyaAmdWwQ6OsIQnTOEKW/jCt2UwczDMYbNqmCQdfs6HR0ziEpv4xCiGZohXrM0Uu5g7LI6x M19M4xrb+MY4zrGOdwxfGReGx87x8WaATOQio4fCRr6PkJfMviQ7+cmkYbKU2wPlKlsZjVPWypW3 DMQsK4XLYA6zQrzcTDGbuSZkTrOa18zmspwZN81txtebPxLnOj94zgy2c3vxzGcn6xljI/7ze8Qs 6ELr98aGlgyfE927PjtaJIxO2aODHOmeBAQAOw== ------=_NextPart_000_0003_01C72C0B.55D87520--