From paitken@cisco.com Mon Apr 1 02:45:09 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357C221F8948 for ; Mon, 1 Apr 2013 02:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOFN5Yrg8KIE for ; Mon, 1 Apr 2013 02:45:08 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3E14D21F8935 for ; Mon, 1 Apr 2013 02:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=887; q=dns/txt; s=iport; t=1364809508; x=1366019108; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=i+KX58n+Kmv9rmEkK80Sjn2DMsnXewn/9wON9rp/MME=; b=fLygT5omSLEcRgjnrcLqnJ4Ee9j15usi5M2YRTh4TUkZ4b+8Z9vlppF5 hnbN2NnWsSb/hx10bTw+4P6krfK8pDCAJuHa1LCXTnxl1IREepdV6fSiD eRewdBHYUslwtzsPQE5FujvT34dmbnJIoMgxIKzaDNRSmqX5IwrQ7Sptz Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAMBWWVGQ/khL/2dsb2JhbABDDoMtAYJYvH2BABZ0gh8BAQEDAThAAQULCw4TFg8JAwIBAgFFBg0BBwEBiAoGDMADjzEHg0ADlmuBH4RiiwqCTEA7 X-IronPort-AV: E=Sophos;i="4.87,385,1363132800"; d="scan'208";a="81663524" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 01 Apr 2013 09:45:01 +0000 Received: from [10.61.98.172] (dhcp-10-61-98-172.cisco.com [10.61.98.172]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r319ixc8014212; Mon, 1 Apr 2013 09:44:59 GMT Message-ID: <51595720.6020509@cisco.com> Date: Mon, 01 Apr 2013 10:45:04 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Nevil Brownlee References: <51428743.3060101@auckland.ac.nz> In-Reply-To: <51428743.3060101@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX list Subject: Re: [IPFIX] DRAFT minutes for IPFIX meeting in Orlando X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 09:45:09 -0000 Nevil, Two points inline, everything else snipped: > + Mechanisms for moving Private Enterprise IEs into the IANA > IPFIX IE Registry, so that Collectors can recognise them > more easily. My understanding is that this registry would be outside of IANA. I strongly oppose pushing private enterprise information into a standards body's registry. They already maintain a perfectly good standards-based registry. > These will be discussed further on the IPFIX list. If we're considering new work items, please don't forget http://tools.ietf.org/html/draft-aitken-ipfix-unobserved-fields-01 It has expired simply because there's nothing new to be said. However, the work is desperately needed. Due to the lack of standardisation, cisco is already using several of these techniques to indicate unavailable and/or unobserved fields. Thanks, P. From muenz@net.in.tum.de Tue Apr 2 11:20:11 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4597221F8BBB for ; Tue, 2 Apr 2013 11:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDVTVRFSI17Q for ; Tue, 2 Apr 2013 11:20:09 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mailsender1.informatik.tu-muenchen.de [131.159.0.97]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5AA21F8BB6 for ; Tue, 2 Apr 2013 11:20:08 -0700 (PDT) Received: from [192.168.2.34] (g227197049.adsl.alicedsl.de [92.227.197.49]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 7C31A19AF833; Tue, 2 Apr 2013 20:20:05 +0200 (CEST) Message-ID: <515B2151.9090304@net.in.tum.de> Date: Tue, 02 Apr 2013 20:20:01 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: ramki Krishnan References: <515362E7.9040306@net.in.tum.de> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090703070603000808020802" Cc: Ning So , IPFIX Working Group Subject: Re: [IPFIX] clarification questions X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:20:11 -0000 This is a multi-part message in MIME format. --------------090703070603000808020802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Ramki, In your own implementation, you can use whatever parameter you want. Regarding the standard configuration data model, I do not think that an exportInterval parameter should be added to TimeoutCache and NaturalCache. This would change the meaning of TimeoutCache and NaturalCache as described in RFC 6728. Regards, Gerhard On 28.03.2013 22:06, ramki Krishnan wrote: > > Hi Gerhard, > > Thanks a lot. More below. > > >>- With TimeoutCache and NaturalCache, the Flow is only exported when > it is expired. At expiration, the Flow is immediately removed from the > Cache. A longlasting flow will result in a new Flow being created in > the Cache. > > For applications, especially security, it would be worthwhile to > periodically export the flow for monitoring purposes. We could add an > optional "exportInterval" parameter similar to PermanentCache for > this. Your comments/thoughts would be appreciated. > > Hi Gerhard/All, > > >>It seems that your actual question is how flow selection fits into > the IPFIX device architecture which has been taken as a basis for RFC > 6728. Concretely, you seem to wonder whether your flow selection is a > kind of Selection Process or a new kind of Cache (or maybe both?). > > The new data models I am trying to specify are based on the following > draft and presentation at the IETF Orlando meeting. It seems to me > that a good starting point is specifying a new flow selection process. > Your comments/thoughts would be appreciated. > > http://www.ietf.org/proceedings/86/slides/slides-86-ipfix-1.pptx > > http://datatracker.ietf.org/doc/draft-krishnan-ipfix-flow-aware-packet-sampling/ > > Thanks, > > Ramki > > *From:*Gerhard Muenz [mailto:muenz@net.in.tum.de] > *Sent:* Wednesday, March 27, 2013 2:22 PM > *To:* ramki Krishnan > *Cc:* IPFIX Working Group; Ning So > *Subject:* Re: [IPFIX] clarification questions > > > Hi Ram, > > The configuration model of RFC 6728 does not cover flow selection. If > you want to configure something like flow selection, you need to > extend the model. > > It seems that your actual question is how flow selection fits into the > IPFIX device architecture which has been taken as a basis for RFC > 6728. Concretely, you seem to wonder whether your flow selection is a > kind of Selection Process or a new kind of Cache (or maybe both?). > > I cannot answer this question because I do not know how it would be > implemented. > > Regarding your question: > - With TimeoutCache and NaturalCache, the Flow is only exported when > it is expired. At expiration, the Flow is immediately removed from the > Cache. A longlasting flow will result in a new Flow being created in > the Cache. > - It's different with PermanentCache. Here, the Flow remains in the > Cache, and the status is periodically exported. > > Regards, > Gerhard > > On 27.03.2013 18:40, ramki Krishnan wrote: > > Dear IPFIX experts, > > From RFC 6728, > > 1.Section 4.3.2 > > oIs there a way to periodically export the flows if we are using a > TimeoutCache or NaturalCache ? > > 2.Suppose we want to populate the cache only with long-lived large > flows (see Note1 below for data model definitions) > > oOne way to achieve this would be to have a selection process, > using a unique observation domain, which filters the long-lived > large flows. Are any other better ways ? > > 3.Continuing from 3) - suppose we want to sample the other flows > (not the long-lived large flows) > > oIs there a way to not include the long-lived large flows in the > selection process ? > > Note 1: > > -observationInterval: The minimum time interval to observe a flow > for performing further processing of the flow. Unit is in seconds. > > -bandwidthThreshold: The minimum bandwidth of the flow during the > observation interval for declaring the flow a long-lived large > flow. Unit is in Mbps. > > For example, a flow which is at or above 10 Mbps > (bandwidthThreshold )for a time period of at least 30 seconds > (observationInterval) could be declared a long-lived large flow. > > -- > > Thanks, > > Ram (aka Ramki) > > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix > --------------090703070603000808020802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Ramki,

In your own implementation, you can use whatever parameter you want. Regarding the standard configuration data model, I do not think that an exportInterval parameter should be added to TimeoutCache and NaturalCache. This would change the meaning of TimeoutCache and NaturalCache as described in RFC 6728.

Regards,
Gerhard


On 28.03.2013 22:06, ramki Krishnan wrote:

Hi Gerhard,

 

Thanks a lot. More below.

 

>>- With TimeoutCache and NaturalCache, the Flow is only exported when it is expired. At expiration, the Flow is immediately removed from the Cache. A longlasting flow will result in a new Flow being created in the Cache.

For applications, especially security, it would be worthwhile to periodically export the flow for monitoring purposes. We could add an optional “exportInterval” parameter similar to PermanentCache for this. Your comments/thoughts would be appreciated.

 

Hi Gerhard/All,

 

>>It seems that your actual question is how flow selection fits into the IPFIX device architecture which has been taken as a basis for RFC 6728. Concretely, you seem to wonder  whether your flow selection is a kind of Selection Process or a new kind of Cache (or maybe both?).

The new data models I am trying to specify are based on the following draft and presentation at the IETF Orlando meeting.  It seems to me that a good starting point is specifying a new flow selection process. Your comments/thoughts would be appreciated.

 

http://www.ietf.org/proceedings/86/slides/slides-86-ipfix-1.pptx

http://datatracker.ietf.org/doc/draft-krishnan-ipfix-flow-aware-packet-sampling/

 

Thanks,

Ramki

 

From: Gerhard Muenz [mailto:muenz@net.in.tum.de]
Sent: Wednesday, March 27, 2013 2:22 PM
To: ramki Krishnan
Cc: IPFIX Working Group; Ning So
Subject: Re: [IPFIX] clarification questions

 


Hi Ram,

The configuration model of RFC 6728 does not cover flow selection. If you want to configure something like flow selection, you need to extend the model.

It seems that your actual question is how flow selection fits into the IPFIX device architecture which has been taken as a basis for RFC 6728. Concretely, you seem to wonder  whether your flow selection is a kind of Selection Process or a new kind of Cache (or maybe both?).

I cannot answer this question because I do not know how it would be implemented.

Regarding your question:
- With TimeoutCache and NaturalCache, the Flow is only exported when it is expired. At expiration, the Flow is immediately removed from the Cache. A longlasting flow will result in a new Flow being created in the Cache.
- It's different with PermanentCache. Here, the Flow remains in the Cache, and the status is periodically exported.

Regards,
Gerhard

On 27.03.2013 18:40, ramki Krishnan wrote:

Dear IPFIX experts,

 

From RFC 6728,

1.      Section 4.3.2

o   Is there a way to periodically export the flows if we are using a TimeoutCache or NaturalCache ?

2.      Suppose we want to populate the cache only with long-lived large flows (see Note1  below for data model definitions)

o   One way to achieve this would be to have a selection process, using a unique observation domain, which filters the long-lived large flows. Are any other better ways ?

3.      Continuing from 3) - suppose we want to sample the other flows (not the long-lived large flows)

o   Is there a way to not include the long-lived large flows in the selection process ?

 

Note 1:

-        observationInterval: The minimum time interval to observe a flow for performing further processing of the flow. Unit is in seconds.

-        bandwidthThreshold: The minimum bandwidth of the flow during the observation interval for declaring the flow a long-lived large flow. Unit is in Mbps.

For example, a flow which is at or above 10 Mbps (bandwidthThreshold )for a time period of at least 30 seconds (observationInterval) could be declared a long-lived large flow.

 

--

Thanks,

Ram (aka Ramki)

 




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

 


--------------090703070603000808020802-- From steve.nash@theiet.org Wed Apr 3 02:52:26 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACD121F8814 for ; Wed, 3 Apr 2013 02:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYrtdNYQKc3i for ; Wed, 3 Apr 2013 02:52:26 -0700 (PDT) Received: from mtaout04-winn.ispmail.ntl.com (mtaout04-winn.ispmail.ntl.com [81.103.221.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7404C21F870F for ; Wed, 3 Apr 2013 02:52:24 -0700 (PDT) Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout04-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20130403095223.YWDJ8801.mtaout04-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com> for ; Wed, 3 Apr 2013 10:52:23 +0100 Received: from snashE6510 ([86.21.114.17]) by aamtaout04-winn.ispmail.ntl.com (InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id <20130403095223.EOKN11790.aamtaout04-winn.ispmail.ntl.com@snashE6510> for ; Wed, 3 Apr 2013 10:52:23 +0100 From: "Steve Nash" To: References: <000601ce2629$a6f0da00$f4d28e00$@theiet.org> <372611A3-F9A5-462F-888A-1742DDF66209@tik.ee.ethz.ch> In-Reply-To: Date: Wed, 3 Apr 2013 10:52:19 +0100 Message-ID: <000c01ce3050$f0124850$d036d8f0$@theiet.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEJPuFdnsVw9LJ+C4lx05MkeupbOgJwpx9RmixisdCADjmIkA== Content-Language: en-gb X-Cloudmark-Analysis: v=1.1 cv=GaEGOwq9FwezmTggA+b6yC6zDZF2HYaK6RN/tSqdnVA= c=1 sm=0 a=sdYygi45Ms8A:10 a=H3ZbhYdykLQA:10 a=k1zQAbrYauQA:10 a=MXF7X9f8RYQA:10 a=kj9zAlcOel0A:10 a=DZEExIYWAAAA:8 a=48vgC7mUAAAA:8 a=lI9dDh6gfVqaQbCTJs0A:9 a=CjuIK1q_8ugA:10 a=KnGVzd4Q2D0A:10 a=lZB815dzVvQA:10 a=ABv4x3ZNOaEiBoi-:21 a=VX-S-7LnplLz8J2P:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 X-Mailman-Approved-At: Wed, 03 Apr 2013 03:03:54 -0700 Subject: [IPFIX] FW: UDP Sequence Numbers rfc 5101 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: steve.nash@theiet.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 09:52:26 -0000 The third sentence remains incorrect. Only IPFIX Data Records are protected by sequence number . "IPFIX messages" in general are not protected (even templates). This is a retrograde step from rfc3954. It makes use of IPFIX for flow reporting over UDP less tolerant than rfc 3954. The unrecognised loss of a template change message could result in significant misinterpretation of data, which is worse than just recognised data loss. The second sentence seems redundant, as UDP is no longer different to TCP and SCTP. You can avoid any mention of transport protocol here. Regards Steve -----Original Message----- From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] Sent: 25 March 2013 00:32 To: steve.nash@theiet.org Cc: ipfix@ietf.org Subject: Re: [IPFIX] UDP Sequence Numbers rfc 5101 Hi, Steve, This is an error in RFC 5101; the intent of the Sequence Number is that it be Observation Domain (and in the case of SCTP, Stream) scoped (i.e., you are correct that transport independence, to the extent possible, is the intent). The language in the present revision of 5101bis still contains the same error. Thanks for the catch! I would suggest we fix this by replacing the paragraph in question as follows: OLD: The Collecting Process SHOULD deduce the loss and reordering of IPFIX Data Records by looking at the discontinuities in the IPFIX Sequence Number. In the case of UDP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent for the UDP Transport Session prior to the receipt of this IPFIX Message, modulo 2^32. A Collector SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages by tracking the Sequence Number. NEW: The Collecting Process SHOULD deduce the loss and reordering of IPFIX Data Records by looking at the discontinuities in the IPFIX Sequence Number. In the case of UDP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent for the Observation Domain in the current UDP Transport Session prior to the receipt of this IPFIX Message, modulo 2^32. A Collector SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages by tracking the Sequence Number. The document is presently in Publication Requested state, so I think this should be placed as an RFC editor note on the document. WG: any comments thereon? Best regards, Brian On 22 Mar 2013, at 0:45, Steve Nash wrote: > Please consider the wording of the paragraph on Sequence Numbers in Section 3.1. > Incremental sequence counter modulo 2^32 of all IPFIX Data Records > sent in the current stream from the current Observation Domain by > the Exporting Process. Each SCTP Stream counts sequence numbers > separately, while all messages in a TCP connection or UDP > transport session are considered to be part of the same stream. > The phrase I have put in italics is depended on Transport protocol. > Section 10.3.2 Reliability says: > > In the case of UDP, the IPFIX Sequence Number contains the total > number of IPFIX Data Records sent for the UDP Transport Session prior > to the receipt of this IPFIX Message > > This is NOT dependent on the ObservationDomain. Nothing prohibits the Exporting Process from using the same Transport Session for multiple Observation Domains. But in UDP the Sequence number is for the Transport session, whereas in TCP and SCTP each Observation Domain has an independent sequence on the same (and on each) Transport Session. > > The term 'Stream' seems to take different meanings in IPFIX, depending on the transport protocol. > This is not consistent with IPFIX being "Transport protocol independent " (Section 10 first para). > > Regards > Steve Nash > steve.nash@theiet.org > UK > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Wed Apr 3 03:41:46 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF93421F8648 for ; Wed, 3 Apr 2013 03:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lbNAQ446UXc for ; Wed, 3 Apr 2013 03:41:46 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5F37921F85E8 for ; Wed, 3 Apr 2013 03:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5862; q=dns/txt; s=iport; t=1364985705; x=1366195305; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Kb1FVWxbMHHNBOdL3I2E72Pr3OaQznRl/uOPUkI8vdQ=; b=iI83w9XeXc1D+KpN5qgpaSLmeY5b7WONy0TaVp9Sq1vtS5hPYIB2XlvE VGFl1dEjCjx7DpSw/FEWkmOwg6z0KmvCzR4tdG7mSrFN6cCNT53mnC7vV 9WmN+ZGtLtjaALtSo39NMIgMJM0VyCWWptU6r3joa9V8KfS0Nje/TTCKt k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0FACcGXFGQ/khN/2dsb2JhbAA5CoMHNgHAPoELFnSCHwEBAQQBAQE1NgsMBAsRBAEBAQkQAQEMBw8CFh8IAQgTAQUCAQGIEAzBMwSNXQSBLQsHBh0EgxkDlmuGAYsKgww7gS4 X-IronPort-AV: E=Sophos;i="4.87,399,1363132800"; d="scan'208";a="152446738" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 03 Apr 2013 10:41:40 +0000 Received: from [10.61.80.146] (ams3-vpn-dhcp4243.cisco.com [10.61.80.146]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r33Afbt6023426; Wed, 3 Apr 2013 10:41:37 GMT Message-ID: <515C0761.90208@cisco.com> Date: Wed, 03 Apr 2013 11:41:37 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: steve.nash@theiet.org References: <000601ce2629$a6f0da00$f4d28e00$@theiet.org> <372611A3-F9A5-462F-888A-1742DDF66209@tik.ee.ethz.ch> <000c01ce3050$f0124850$d036d8f0$@theiet.org> In-Reply-To: <000c01ce3050$f0124850$d036d8f0$@theiet.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] FW: UDP Sequence Numbers rfc 5101 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 10:41:47 -0000 Steve, The sequence number change was a deliberate decision in RFC 5101, so that collectors can use the sequence numbers to determine (and thus report) the number of lost data records. This is an improvement of RFC 3954, where the sequence number only counted export packets. In this case it's impossible to determine how many data records were lost, ie the amount of loss is unquantifiable. The packets could have contained templates and/or data records; we simply don't know. Neither of these sequence numbers helps to specifically determine whether a template has been lost. 3954 sequence numbers identify packet loss without indicating whether it's template or data record. 5101 sequence numbers identify data record loss only. Identifying template loss would require an additional template sequence number. If loss is a big issue in your network, don't export over UDP. If you must export over UDP, and loss is an issue, then don't redefine templates on the fly. In my experience templates are generally static (defined once and never withdrawn or redefined), and limited to a few 10's in number. However, there are 65280 templates available. Defining these incrementally at 1000/sec with a 1-minute lifetime, or at 100/sec with a 10-minute lifetime, ensures that no template will ever be redefined within its lifetime - although I can't think of any use case that requires (re)defining templates that quickly. P. On 03/04/13 10:52, Steve Nash wrote: > The third sentence remains incorrect. Only IPFIX Data Records are protected > by sequence number . "IPFIX messages" in general are not protected (even > templates). > This is a retrograde step from rfc3954. > It makes use of IPFIX for flow reporting over UDP less tolerant than rfc > 3954. The unrecognised loss of a template change message could result in > significant misinterpretation of data, which is worse than just recognised > data loss. > > The second sentence seems redundant, as UDP is no longer different to TCP > and SCTP. You can avoid any mention of transport protocol here. > > Regards > Steve > > > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > Sent: 25 March 2013 00:32 > To: steve.nash@theiet.org > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] UDP Sequence Numbers rfc 5101 > > Hi, Steve, > > This is an error in RFC 5101; the intent of the Sequence Number is that it > be Observation Domain (and in the case of SCTP, Stream) scoped (i.e., you > are correct that transport independence, to the extent possible, is the > intent). The language in the present revision of 5101bis still contains the > same error. Thanks for the catch! > > I would suggest we fix this by replacing the paragraph in question as > follows: > > OLD: > > The Collecting Process SHOULD deduce the loss and reordering of IPFIX > Data Records by looking at the discontinuities in the IPFIX Sequence > Number. In the case of UDP, the IPFIX Sequence Number contains the > total number of IPFIX Data Records sent for the UDP Transport Session > prior to the receipt of this IPFIX Message, modulo 2^32. A Collector > SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages > by tracking the Sequence Number. > > NEW: > > The Collecting Process SHOULD deduce the loss and reordering of IPFIX > Data Records by looking at the discontinuities in the IPFIX Sequence > Number. In the case of UDP, the IPFIX Sequence Number contains the > total number of IPFIX Data Records sent for the Observation Domain in the > current UDP Transport Session prior to the receipt of this IPFIX Message, > > modulo 2^32. A Collector SHOULD detect out-of-sequence, dropped, or > duplicate IPFIX Messages by tracking the Sequence Number. > > The document is presently in Publication Requested state, so I think this > should be placed as an RFC editor note on the document. WG: any comments > thereon? > > Best regards, > > Brian > > On 22 Mar 2013, at 0:45, Steve Nash wrote: > >> Please consider the wording of the paragraph on Sequence Numbers in > Section 3.1. >> Incremental sequence counter modulo 2^32 of all IPFIX Data Records >> sent in the current stream from the current Observation Domain by >> the Exporting Process. Each SCTP Stream counts sequence numbers >> separately, while all messages in a TCP connection or UDP >> transport session are considered to be part of the same stream. >> The phrase I have put in italics is depended on Transport protocol. >> Section 10.3.2 Reliability says: >> >> In the case of UDP, the IPFIX Sequence Number contains the total >> number of IPFIX Data Records sent for the UDP Transport Session prior >> to the receipt of this IPFIX Message >> >> This is NOT dependent on the ObservationDomain. Nothing prohibits the > Exporting Process from using the same Transport Session for multiple > Observation Domains. But in UDP the Sequence number is for the Transport > session, whereas in TCP and SCTP each Observation Domain has an independent > sequence on the same (and on each) Transport Session. >> >> The term 'Stream' seems to take different meanings in IPFIX, depending on > the transport protocol. >> This is not consistent with IPFIX being "Transport protocol independent " > (Section 10 first para). >> >> Regards >> Steve Nash >> steve.nash@theiet.org >> UK >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From steve.nash@theiet.org Wed Apr 3 06:49:58 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0430321F8AE8 for ; Wed, 3 Apr 2013 06:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2v3PjOJUxehO for ; Wed, 3 Apr 2013 06:49:56 -0700 (PDT) Received: from mtaout04-winn.ispmail.ntl.com (mtaout04-winn.ispmail.ntl.com [81.103.221.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA5921F8AD5 for ; Wed, 3 Apr 2013 06:49:55 -0700 (PDT) Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout04-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20130403134954.FNJM8801.mtaout04-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>; Wed, 3 Apr 2013 14:49:54 +0100 Received: from snashE6510 ([86.21.114.17]) by aamtaout03-winn.ispmail.ntl.com (InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id <20130403134954.LYFL21752.aamtaout03-winn.ispmail.ntl.com@snashE6510>; Wed, 3 Apr 2013 14:49:54 +0100 From: "Steve Nash" To: "'Paul Aitken'" References: <000601ce2629$a6f0da00$f4d28e00$@theiet.org> <372611A3-F9A5-462F-888A-1742DDF66209@tik.ee.ethz.ch> <000c01ce3050$f0124850$d036d8f0$@theiet.org> <515C0761.90208@cisco.com> In-Reply-To: <515C0761.90208@cisco.com> Date: Wed, 3 Apr 2013 14:49:50 +0100 Message-ID: <002001ce3072$1dd16430$59742c90$@theiet.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEJPuFdnsVw9LJ+C4lx05MkeupbOgJwpx9RAgVQwwEDgCkStJoOr5cQ Content-Language: en-gb X-Cloudmark-Analysis: v=1.1 cv=GaEGOwq9FwezmTggA+b6yC6zDZF2HYaK6RN/tSqdnVA= c=1 sm=0 a=4yr7x6X-KPcA:10 a=H3ZbhYdykLQA:10 a=k1zQAbrYauQA:10 a=MXF7X9f8RYQA:10 a=kj9zAlcOel0A:10 a=AUd_NHdVAAAA:8 a=DZEExIYWAAAA:8 a=48vgC7mUAAAA:8 a=XVPOSPGlsEV4HJyALTkA:9 a=CjuIK1q_8ugA:10 a=JfD0Fch1gWkA:10 a=KnGVzd4Q2D0A:10 a=lZB815dzVvQA:10 a=1IOBFcgOEoMbjXmR:21 a=UhijJAX80oXgy35q:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: ipfix@ietf.org Subject: Re: [IPFIX] FW: UDP Sequence Numbers rfc 5101 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: steve.nash@theiet.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 13:49:58 -0000 Paul Two things: 1/ Thanks for the explanation. The assessment of relative importance of template loss v count of data records is clearly case depended, but reasonable. 2/ Sentence three remains incorrect to my mind. It is a Recommendation that is impossible to fulfil . As it stands the sentence leads the reader to believe that IPFIX over UDP provides greater reliability than it actually does. Regards Steve -----Original Message----- From: Paul Aitken [mailto:paitken@cisco.com] Sent: 03 April 2013 11:42 To: steve.nash@theiet.org Cc: ipfix@ietf.org Subject: Re: [IPFIX] FW: UDP Sequence Numbers rfc 5101 Steve, The sequence number change was a deliberate decision in RFC 5101, so that collectors can use the sequence numbers to determine (and thus report) the number of lost data records. This is an improvement of RFC 3954, where the sequence number only counted export packets. In this case it's impossible to determine how many data records were lost, ie the amount of loss is unquantifiable. The packets could have contained templates and/or data records; we simply don't know. Neither of these sequence numbers helps to specifically determine whether a template has been lost. 3954 sequence numbers identify packet loss without indicating whether it's template or data record. 5101 sequence numbers identify data record loss only. Identifying template loss would require an additional template sequence number. If loss is a big issue in your network, don't export over UDP. If you must export over UDP, and loss is an issue, then don't redefine templates on the fly. In my experience templates are generally static (defined once and never withdrawn or redefined), and limited to a few 10's in number. However, there are 65280 templates available. Defining these incrementally at 1000/sec with a 1-minute lifetime, or at 100/sec with a 10-minute lifetime, ensures that no template will ever be redefined within its lifetime - although I can't think of any use case that requires (re)defining templates that quickly. P. On 03/04/13 10:52, Steve Nash wrote: > The third sentence remains incorrect. Only IPFIX Data Records are > protected by sequence number . "IPFIX messages" in general are not > protected (even templates). > This is a retrograde step from rfc3954. > It makes use of IPFIX for flow reporting over UDP less tolerant than > rfc 3954. The unrecognised loss of a template change message could > result in significant misinterpretation of data, which is worse than > just recognised data loss. > > The second sentence seems redundant, as UDP is no longer different to > TCP and SCTP. You can avoid any mention of transport protocol here. > > Regards > Steve > > > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > Sent: 25 March 2013 00:32 > To: steve.nash@theiet.org > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] UDP Sequence Numbers rfc 5101 > > Hi, Steve, > > This is an error in RFC 5101; the intent of the Sequence Number is > that it be Observation Domain (and in the case of SCTP, Stream) scoped > (i.e., you are correct that transport independence, to the extent > possible, is the intent). The language in the present revision of > 5101bis still contains the same error. Thanks for the catch! > > I would suggest we fix this by replacing the paragraph in question as > follows: > > OLD: > > The Collecting Process SHOULD deduce the loss and reordering of IPFIX > Data Records by looking at the discontinuities in the IPFIX Sequence > Number. In the case of UDP, the IPFIX Sequence Number contains the > total number of IPFIX Data Records sent for the UDP Transport Session > prior to the receipt of this IPFIX Message, modulo 2^32. A Collector > SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages > by tracking the Sequence Number. > > NEW: > > The Collecting Process SHOULD deduce the loss and reordering of IPFIX > Data Records by looking at the discontinuities in the IPFIX Sequence > Number. In the case of UDP, the IPFIX Sequence Number contains the > total number of IPFIX Data Records sent for the Observation Domain in the > current UDP Transport Session prior to the receipt of this IPFIX > Message, > > modulo 2^32. A Collector SHOULD detect out-of-sequence, dropped, or > duplicate IPFIX Messages by tracking the Sequence Number. > > The document is presently in Publication Requested state, so I think > this should be placed as an RFC editor note on the document. WG: any > comments thereon? > > Best regards, > > Brian > > On 22 Mar 2013, at 0:45, Steve Nash wrote: > >> Please consider the wording of the paragraph on Sequence Numbers in > Section 3.1. >> Incremental sequence counter modulo 2^32 of all IPFIX Data Records >> sent in the current stream from the current Observation Domain by >> the Exporting Process. Each SCTP Stream counts sequence numbers >> separately, while all messages in a TCP connection or UDP >> transport session are considered to be part of the same stream. >> The phrase I have put in italics is depended on Transport protocol. >> Section 10.3.2 Reliability says: >> >> In the case of UDP, the IPFIX Sequence Number contains the total >> number of IPFIX Data Records sent for the UDP Transport Session prior >> to the receipt of this IPFIX Message >> >> This is NOT dependent on the ObservationDomain. Nothing prohibits >> the > Exporting Process from using the same Transport Session for multiple > Observation Domains. But in UDP the Sequence number is for the > Transport session, whereas in TCP and SCTP each Observation Domain has > an independent sequence on the same (and on each) Transport Session. >> >> The term 'Stream' seems to take different meanings in IPFIX, >> depending on > the transport protocol. >> This is not consistent with IPFIX being "Transport protocol independent " > (Section 10 first para). >> >> Regards >> Steve Nash >> steve.nash@theiet.org >> UK >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Wed Apr 3 12:54:04 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFA821F8C04 for ; Wed, 3 Apr 2013 12:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vfuS27sS2DR for ; Wed, 3 Apr 2013 12:54:03 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9885821F8BF2 for ; Wed, 3 Apr 2013 12:54:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C1820D9308; Wed, 3 Apr 2013 21:54:02 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dpwNcHPtHPNc; Wed, 3 Apr 2013 21:54:02 +0200 (MEST) Received: from [192.168.0.5] (unknown [121.99.65.160]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 858A5D9305; Wed, 3 Apr 2013 21:54:00 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Trammell In-Reply-To: <002001ce3072$1dd16430$59742c90$@theiet.org> Date: Thu, 4 Apr 2013 08:53:55 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <99F19BEC-D2E1-4E9E-8B3D-BC0D16E7B6AE@tik.ee.ethz.ch> References: <000601ce2629$a6f0da00$f4d28e00$@theiet.org> <372611A3-F9A5-462F-888A-1742DDF66209@tik.ee.ethz.ch> <000c01ce3050$f0124850$d036d8f0$@theiet.org> <515C0761.90208@cisco.com> <002001ce3072$1dd16430$59742c90$@theiet.org> To: steve.nash@theiet.org X-Mailer: Apple Mail (2.1503) Cc: ipfix@ietf.org Subject: Re: [IPFIX] FW: UDP Sequence Numbers rfc 5101 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 19:54:05 -0000 hi Steve, all, On 4 Apr 2013, at 2:49, "Steve Nash" wrote: > Paul=20 > Two things: > 1/ Thanks for the explanation. The assessment of relative importance = of > template loss v count of data records is clearly case depended, but > reasonable. > 2/ Sentence three remains incorrect to my mind. It is a = Recommendation > that is impossible to fulfil . =20 While it is technically correct that it is Data Records that are counted = by the Sequence Number and not Messages, it is Messages that are the = unit of loss over UDP or partially-reliable SCTP, therefore the signal = available from sequence number analysis is a loss-of-message signal. It is true that you can't deduce the loss of UDP template-only messages = by looking at IPFIX Message Header Sequence Numbers. But you can't do = that in V9 either. There's no information about the contents of lost = Export Packets in V9. Template message loss can be deduced by observing = Data Sets covered by unreceived Templates in any case. > As it stands the sentence leads the reader to believe that IPFIX over = UDP > provides greater reliability than it actually does. In the context of the document and the documents around it (see e.g. = 5153 section 6.2, 5101bis section 10.1 para 4 and section 10.3) I can't = see how this is the case. Anything-over-UDP is unreliable, full stop, and we should not put a lot = of effort in to pretending it could be. Regards, Brian > -----Original Message----- > From: Paul Aitken [mailto:paitken@cisco.com]=20 > Sent: 03 April 2013 11:42 > To: steve.nash@theiet.org > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] FW: UDP Sequence Numbers rfc 5101 >=20 > Steve, >=20 > The sequence number change was a deliberate decision in RFC 5101, so = that > collectors can use the sequence numbers to determine (and thus > report) the number of lost data records. >=20 > This is an improvement of RFC 3954, where the sequence number only = counted > export packets. In this case it's impossible to determine how many = data > records were lost, ie the amount of loss is unquantifiable.=20 > The packets could have contained templates and/or data records; we = simply > don't know. >=20 > Neither of these sequence numbers helps to specifically determine = whether a > template has been lost. 3954 sequence numbers identify packet loss = without > indicating whether it's template or data record. 5101 sequence numbers > identify data record loss only. >=20 > Identifying template loss would require an additional template = sequence > number. >=20 > If loss is a big issue in your network, don't export over UDP. If you = must > export over UDP, and loss is an issue, then don't redefine templates = on the > fly. >=20 > In my experience templates are generally static (defined once and = never > withdrawn or redefined), and limited to a few 10's in number. However, = there > are 65280 templates available. Defining these incrementally at = 1000/sec with > a 1-minute lifetime, or at 100/sec with a 10-minute lifetime, ensures = that > no template will ever be redefined within its lifetime - although I = can't > think of any use case that requires (re)defining templates that = quickly. >=20 > P. >=20 >=20 > On 03/04/13 10:52, Steve Nash wrote: >> The third sentence remains incorrect. Only IPFIX Data Records are=20 >> protected by sequence number . "IPFIX messages" in general are not=20= >> protected (even templates). >> This is a retrograde step from rfc3954. >> It makes use of IPFIX for flow reporting over UDP less tolerant than=20= >> rfc 3954. The unrecognised loss of a template change message could=20= >> result in significant misinterpretation of data, which is worse than=20= >> just recognised data loss. >>=20 >> The second sentence seems redundant, as UDP is no longer different to=20= >> TCP and SCTP. You can avoid any mention of transport protocol here. >>=20 >> Regards >> Steve >>=20 >>=20 >> -----Original Message----- >> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >> Sent: 25 March 2013 00:32 >> To: steve.nash@theiet.org >> Cc: ipfix@ietf.org >> Subject: Re: [IPFIX] UDP Sequence Numbers rfc 5101 >>=20 >> Hi, Steve, >>=20 >> This is an error in RFC 5101; the intent of the Sequence Number is=20 >> that it be Observation Domain (and in the case of SCTP, Stream) = scoped=20 >> (i.e., you are correct that transport independence, to the extent=20 >> possible, is the intent). The language in the present revision of=20 >> 5101bis still contains the same error. Thanks for the catch! >>=20 >> I would suggest we fix this by replacing the paragraph in question as >> follows: >>=20 >> OLD: >>=20 >> The Collecting Process SHOULD deduce the loss and reordering of = IPFIX >> Data Records by looking at the discontinuities in the IPFIX = Sequence >> Number. In the case of UDP, the IPFIX Sequence Number contains = the >> total number of IPFIX Data Records sent for the UDP Transport = Session >> prior to the receipt of this IPFIX Message, modulo 2^32. A = Collector >> SHOULD detect out-of-sequence, dropped, or duplicate IPFIX = Messages >> by tracking the Sequence Number. >>=20 >> NEW: >>=20 >> The Collecting Process SHOULD deduce the loss and reordering of = IPFIX >> Data Records by looking at the discontinuities in the IPFIX = Sequence >> Number. In the case of UDP, the IPFIX Sequence Number contains = the >> total number of IPFIX Data Records sent for the Observation Domain = in > the >> current UDP Transport Session prior to the receipt of this IPFIX=20= >> Message, >>=20 >> modulo 2^32. A Collector SHOULD detect out-of-sequence, dropped, = or >> duplicate IPFIX Messages by tracking the Sequence Number. >>=20 >> The document is presently in Publication Requested state, so I think=20= >> this should be placed as an RFC editor note on the document. WG: any=20= >> comments thereon? >>=20 >> Best regards, >>=20 >> Brian >>=20 >> On 22 Mar 2013, at 0:45, Steve Nash wrote: >>=20 >>> Please consider the wording of the paragraph on Sequence Numbers in >> Section 3.1. >>> Incremental sequence counter modulo 2^32 of all IPFIX Data = Records >>> sent in the current stream from the current Observation Domain = by >>> the Exporting Process. Each SCTP Stream counts sequence = numbers >>> separately, while all messages in a TCP connection or UDP >>> transport session are considered to be part of the same = stream. >>> The phrase I have put in italics is depended on Transport protocol. >>> Section 10.3.2 Reliability says: >>>=20 >>> In the case of UDP, the IPFIX Sequence Number contains the total=20 >>> number of IPFIX Data Records sent for the UDP Transport Session = prior=20 >>> to the receipt of this IPFIX Message >>>=20 >>> This is NOT dependent on the ObservationDomain. Nothing prohibits=20= >>> the >> Exporting Process from using the same Transport Session for multiple=20= >> Observation Domains. But in UDP the Sequence number is for the=20 >> Transport session, whereas in TCP and SCTP each Observation Domain = has=20 >> an independent sequence on the same (and on each) Transport Session. >>>=20 >>> The term 'Stream' seems to take different meanings in IPFIX,=20 >>> depending on >> the transport protocol. >>> This is not consistent with IPFIX being "Transport protocol = independent > " >> (Section 10 first para). >>>=20 >>> Regards >>> Steve Nash >>> steve.nash@theiet.org >>> UK >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Wed Apr 3 16:17:14 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCF521F9058 for ; Wed, 3 Apr 2013 16:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjanmUXd15bj for ; Wed, 3 Apr 2013 16:17:13 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id E36E321F8F0E for ; Wed, 3 Apr 2013 16:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8814; q=dns/txt; s=iport; t=1365031033; x=1366240633; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JOwoZ/YQMJnlSwcd6pt7SXcd3VBvdCCrsLkXcet9jcI=; b=MBuVKEAhPgFuF7IJA4ClRbJ3K+av6XliafRwHBErV5B02CPdy19fubhA sZi2u7ad+4VSyJWmr2uHZFKzcCCszxIN61AsNfRapagp8lLeiCOf3LOXD yW/MphNbR0PnTg441LxlFAqfLrCip3r53HQLcZZNKw9HRCxUj/ttHaXDP k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FANi3XFGQ/khL/2dsb2JhbAA5CoMHNsBegQwWdIIfAQEBBAEBATU2CgEMBAsRBAEBAQkQAQEECAcJAwIBAgEVHwgBCAYNAQUCAQGIEAzAQwSNXQSBLQsHBh0EgxkDlmuGAYsKgww7gS4 X-IronPort-AV: E=Sophos;i="4.87,403,1363132800"; d="scan'208";a="13073065" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 03 Apr 2013 23:17:11 +0000 Received: from [10.61.80.146] (ams3-vpn-dhcp4243.cisco.com [10.61.80.146]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r33NH9xh000541; Wed, 3 Apr 2013 23:17:09 GMT Message-ID: <515CB876.4040801@cisco.com> Date: Thu, 04 Apr 2013 00:17:10 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Brian Trammell References: <000601ce2629$a6f0da00$f4d28e00$@theiet.org> <372611A3-F9A5-462F-888A-1742DDF66209@tik.ee.ethz.ch> <000c01ce3050$f0124850$d036d8f0$@theiet.org> <515C0761.90208@cisco.com> <002001ce3072$1dd16430$59742c90$@theiet.org> <99F19BEC-D2E1-4E9E-8B3D-BC0D16E7B6AE@tik.ee.ethz.ch> In-Reply-To: <99F19BEC-D2E1-4E9E-8B3D-BC0D16E7B6AE@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] FW: UDP Sequence Numbers rfc 5101 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 23:17:14 -0000 Brian, I agree, except for "Template message loss can be deduced by observing Data Sets covered by unreceived Templates in any case." This isn't true in the case of template redefinition, specifically mentioned by Steve. ie, a collector will be unaware that a redefined template has been lost, especially if the new and old data records are the same size - although records might not decode sensibly. However I'm not sure that many collectors come with AI to determine whether records are sensible. In the worst case, the new template will specify records with a length that's a multiple of the old record length, so messages will intermittently appear to be too short. As ever, template reuse over unreliable transport is best avoided. P. On 03/04/13 20:53, Brian Trammell wrote: > hi Steve, all, > > On 4 Apr 2013, at 2:49, "Steve Nash" wrote: > >> Paul >> Two things: >> 1/ Thanks for the explanation. The assessment of relative importance of >> template loss v count of data records is clearly case depended, but >> reasonable. >> 2/ Sentence three remains incorrect to my mind. It is a Recommendation >> that is impossible to fulfil . > While it is technically correct that it is Data Records that are counted by the Sequence Number and not Messages, it is Messages that are the unit of loss over UDP or partially-reliable SCTP, therefore the signal available from sequence number analysis is a loss-of-message signal. > > It is true that you can't deduce the loss of UDP template-only messages by looking at IPFIX Message Header Sequence Numbers. But you can't do that in V9 either. There's no information about the contents of lost Export Packets in V9. Template message loss can be deduced by observing Data Sets covered by unreceived Templates in any case. > >> As it stands the sentence leads the reader to believe that IPFIX over UDP >> provides greater reliability than it actually does. > In the context of the document and the documents around it (see e.g. 5153 section 6.2, 5101bis section 10.1 para 4 and section 10.3) I can't see how this is the case. > > Anything-over-UDP is unreliable, full stop, and we should not put a lot of effort in to pretending it could be. > > Regards, > > Brian > >> -----Original Message----- >> From: Paul Aitken [mailto:paitken@cisco.com] >> Sent: 03 April 2013 11:42 >> To: steve.nash@theiet.org >> Cc: ipfix@ietf.org >> Subject: Re: [IPFIX] FW: UDP Sequence Numbers rfc 5101 >> >> Steve, >> >> The sequence number change was a deliberate decision in RFC 5101, so that >> collectors can use the sequence numbers to determine (and thus >> report) the number of lost data records. >> >> This is an improvement of RFC 3954, where the sequence number only counted >> export packets. In this case it's impossible to determine how many data >> records were lost, ie the amount of loss is unquantifiable. >> The packets could have contained templates and/or data records; we simply >> don't know. >> >> Neither of these sequence numbers helps to specifically determine whether a >> template has been lost. 3954 sequence numbers identify packet loss without >> indicating whether it's template or data record. 5101 sequence numbers >> identify data record loss only. >> >> Identifying template loss would require an additional template sequence >> number. >> >> If loss is a big issue in your network, don't export over UDP. If you must >> export over UDP, and loss is an issue, then don't redefine templates on the >> fly. >> >> In my experience templates are generally static (defined once and never >> withdrawn or redefined), and limited to a few 10's in number. However, there >> are 65280 templates available. Defining these incrementally at 1000/sec with >> a 1-minute lifetime, or at 100/sec with a 10-minute lifetime, ensures that >> no template will ever be redefined within its lifetime - although I can't >> think of any use case that requires (re)defining templates that quickly. >> >> P. >> >> >> On 03/04/13 10:52, Steve Nash wrote: >>> The third sentence remains incorrect. Only IPFIX Data Records are >>> protected by sequence number . "IPFIX messages" in general are not >>> protected (even templates). >>> This is a retrograde step from rfc3954. >>> It makes use of IPFIX for flow reporting over UDP less tolerant than >>> rfc 3954. The unrecognised loss of a template change message could >>> result in significant misinterpretation of data, which is worse than >>> just recognised data loss. >>> >>> The second sentence seems redundant, as UDP is no longer different to >>> TCP and SCTP. You can avoid any mention of transport protocol here. >>> >>> Regards >>> Steve >>> >>> >>> -----Original Message----- >>> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >>> Sent: 25 March 2013 00:32 >>> To: steve.nash@theiet.org >>> Cc: ipfix@ietf.org >>> Subject: Re: [IPFIX] UDP Sequence Numbers rfc 5101 >>> >>> Hi, Steve, >>> >>> This is an error in RFC 5101; the intent of the Sequence Number is >>> that it be Observation Domain (and in the case of SCTP, Stream) scoped >>> (i.e., you are correct that transport independence, to the extent >>> possible, is the intent). The language in the present revision of >>> 5101bis still contains the same error. Thanks for the catch! >>> >>> I would suggest we fix this by replacing the paragraph in question as >>> follows: >>> >>> OLD: >>> >>> The Collecting Process SHOULD deduce the loss and reordering of IPFIX >>> Data Records by looking at the discontinuities in the IPFIX Sequence >>> Number. In the case of UDP, the IPFIX Sequence Number contains the >>> total number of IPFIX Data Records sent for the UDP Transport Session >>> prior to the receipt of this IPFIX Message, modulo 2^32. A Collector >>> SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages >>> by tracking the Sequence Number. >>> >>> NEW: >>> >>> The Collecting Process SHOULD deduce the loss and reordering of IPFIX >>> Data Records by looking at the discontinuities in the IPFIX Sequence >>> Number. In the case of UDP, the IPFIX Sequence Number contains the >>> total number of IPFIX Data Records sent for the Observation Domain in >> the >>> current UDP Transport Session prior to the receipt of this IPFIX >>> Message, >>> >>> modulo 2^32. A Collector SHOULD detect out-of-sequence, dropped, or >>> duplicate IPFIX Messages by tracking the Sequence Number. >>> >>> The document is presently in Publication Requested state, so I think >>> this should be placed as an RFC editor note on the document. WG: any >>> comments thereon? >>> >>> Best regards, >>> >>> Brian >>> >>> On 22 Mar 2013, at 0:45, Steve Nash wrote: >>> >>>> Please consider the wording of the paragraph on Sequence Numbers in >>> Section 3.1. >>>> Incremental sequence counter modulo 2^32 of all IPFIX Data Records >>>> sent in the current stream from the current Observation Domain by >>>> the Exporting Process. Each SCTP Stream counts sequence numbers >>>> separately, while all messages in a TCP connection or UDP >>>> transport session are considered to be part of the same stream. >>>> The phrase I have put in italics is depended on Transport protocol. >>>> Section 10.3.2 Reliability says: >>>> >>>> In the case of UDP, the IPFIX Sequence Number contains the total >>>> number of IPFIX Data Records sent for the UDP Transport Session prior >>>> to the receipt of this IPFIX Message >>>> >>>> This is NOT dependent on the ObservationDomain. Nothing prohibits >>>> the >>> Exporting Process from using the same Transport Session for multiple >>> Observation Domains. But in UDP the Sequence number is for the >>> Transport session, whereas in TCP and SCTP each Observation Domain has >>> an independent sequence on the same (and on each) Transport Session. >>>> The term 'Stream' seems to take different meanings in IPFIX, >>>> depending on >>> the transport protocol. >>>> This is not consistent with IPFIX being "Transport protocol independent >> " >>> (Section 10 first para). >>>> Regards >>>> Steve Nash >>>> steve.nash@theiet.org >>>> UK >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Sun Apr 7 23:50:05 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C315021F9156; Sun, 7 Apr 2013 23:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.855 X-Spam-Level: X-Spam-Status: No, score=-9.855 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYpsPw1j7EEl; Sun, 7 Apr 2013 23:50:04 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id CE59121F909A; Sun, 7 Apr 2013 23:50:03 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r386o0FI003573; Mon, 8 Apr 2013 08:50:01 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r386nj2A024078; Mon, 8 Apr 2013 08:49:55 +0200 (CEST) Message-ID: <5162683F.4070407@cisco.com> Date: Mon, 08 Apr 2013 08:48:31 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: ie-doctors@ietf.org References: <20130320111156.95E65B1E003@rfc-editor.org> <514F856F.9040601@cisco.com> <3F56EE0C-0200-4903-AA8B-EF8DE3E7E278@tik.ee.ethz.ch> <514F9642.1030904@cisco.com> In-Reply-To: <514F9642.1030904@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Technical Errata Reported] RFC5655 (3560) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 06:50:05 -0000 IPFIX ie-doctors, Do you have a conclusion regarding this errata http://www.rfc-editor.org/errata_search.php?eid=3560 ? Just back to work today, so maybe I missed it... Regards, Benoit > Hi Brian, >> Hi, Benoit, >> >> Though technically correct, this is, in my view, not what the range >> attribute in the registry is for. > I accept this point of view (as well). > I propose that the ie-doctors discuss this issue, and come back with a > consensus on this corner case. >> >> The intention of the restriction on the value of the messageScope IE >> is to be clear that it is not intended to convey any data in the >> record, simply to convey information in the type represented by the >> template. "Range" implies to me that the values actually have semantics. >> >> Further, it is not clear that it makes sense to go through the errata >> process _first_ on definitions of IEs in RFCs when we've just gone to >> a fair amount of effort to be very clear (through 5102bis and >> ie-doctors) that the IANA registry is the canonical reference for the >> information model. Otherwise, we logically have to file errata on >> 5102 every time the original IEs are updated through the ie-doctors >> process, which just seems like a lot of extra bureaucracy to me. > We have to distinguish three types of errata, depending on the content > of the "requester" in the IPFIX IANA registry > 1. it contains RFC5102. I agree with you. Let's wait for the > [RFC5102bis} and [ie-doctors] > 2. it doesn't contain any specific RFC: let's do the change directly > in IANA > 3. it contains a RFC but not RFC5102. In that case, we need an errata > on the originating RFC, which in turn, will change the IANA registry > > The errata in question is about messageScope, which falls in the > category 3. > > Regards, Benoit >> >> Regards, >> >> Brian >> >> On 25 Mar 2013, at 11:59, Benoit Claise wrote: >> >>> Hi, >>> >>> This errata looks fine to me, but I want to hear from authors first, >>> as this is the first time we will have a range of "0-0" in the IPFIX >>> IANA registry. >>> >>> Regards, Benoit >>>> The following errata report has been submitted for RFC5655, >>>> "Specification of the IP Flow Information Export (IPFIX) File Format". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=3560 >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Paul Aitken >>>> >>>> Section: 8.2.11 + .18 >>>> >>>> Original Text >>>> ------------- >>>> (none) >>>> >>>> Corrected Text >>>> -------------- >>>> Range: The valid range is 0-0. >>>> >>>> Notes >>>> ----- >>>> 8.2.11 messageScope requires a value of 0 ("The value of this >>>> Information Element MUST be written as 0") but no range is given. >>>> The range should say "0-0". (Compare with text in RFC 5102). >>>> >>>> >>>> >>>> Similarly for 8.2.18 sessionScope. >>>> >>>> Instructions: >>>> ------------- >>>> This errata is currently posted as "Reported". If necessary, please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party (IESG) >>>> can log in to change the status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC5655 (draft-ietf-ipfix-file-05) >>>> -------------------------------------- >>>> Title : Specification of the IP Flow Information >>>> Export (IPFIX) File Format >>>> Publication Date : October 2009 >>>> Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. >>>> Wagner >>>> Category : PROPOSED STANDARD >>>> Source : IP Flow Information Export >>>> Area : Operations and Management >>>> Stream : IETF >>>> Verifying Party : IESG >>>> >>>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >> >> > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > > From n.brownlee@auckland.ac.nz Mon Apr 8 22:07:04 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA3121F8F4F for ; Mon, 8 Apr 2013 22:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhZkYO93jaw4 for ; Mon, 8 Apr 2013 22:07:02 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id DF13A21F8F4A for ; Mon, 8 Apr 2013 22:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1365484022; x=1397020022; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZLOV3BUjxyHi5xioSuX+JXuc5KOAD0PL2lmJynVCeQI=; b=JOSZsG1XLKxlOzCkDOPZXQNN6MrEuMuArkPQeZxEDT5WaWi2jAXo8iq2 6PL18CIFUDCqCFnNZdK8hS8+8X1K3v0IoqdUhe0OqC6Vfq+yoPU3nKtll RCIeOR7ZcZnlqklm2v8WeTbtTjMGxYEi601HwLQ+DkUPutllFRSsSfJtJ 4=; X-IronPort-AV: E=Sophos;i="4.87,436,1363086000"; d="scan'208";a="180023323" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 09 Apr 2013 17:06:58 +1200 Message-ID: <5163A1F1.4010904@auckland.ac.nz> Date: Tue, 09 Apr 2013 17:06:57 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Paul Aitken References: <51428743.3060101@auckland.ac.nz> <51595720.6020509@cisco.com> In-Reply-To: <51595720.6020509@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX list Subject: Re: [IPFIX] DRAFT minutes for IPFIX meeting in Orlando X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 05:07:04 -0000 Hi Paul: Responses inline ... On 1/04/13 10:45 PM, Paul Aitken wrote: > Nevil, > > Two points inline, everything else snipped: > > >> + Mechanisms for moving Private Enterprise IEs into the IANA >> IPFIX IE Registry, so that Collectors can recognise them >> more easily. > > My understanding is that this registry would be outside of IANA. > > I strongly oppose pushing private enterprise information into a > standards body's registry. They already maintain a perfectly good > standards-based registry. Agreed. That bullet point is from my one-para summary of the meeting. The topic it summarises was the transitioning of a PE IE to a standard IE, and how we make that work. >> These will be discussed further on the IPFIX list. > > If we're considering new work items, please don't forget > http://tools.ietf.org/html/draft-aitken-ipfix-unobserved-fields-01 > > It has expired simply because there's nothing new to be said. However, > the work is desperately needed. Due to the lack of standardisation, > cisco is already using several of these techniques to indicate > unavailable and/or unobserved fields. Again, I agree. However, the minutes record what happened in one particular meeting, I don't recall it actually being discussed. The time to raise this will be when we actually consider possible new work - once we get close to finishing the current charter items. Cheers, Nevil > Thanks, > P. -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From albrecht.schwarz@alcatel-lucent.com Tue Apr 9 02:58:04 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524A321F9355 for ; Tue, 9 Apr 2013 02:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jq--7dEgTCYS for ; Tue, 9 Apr 2013 02:58:03 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9B67221F86C1 for ; Tue, 9 Apr 2013 02:58:03 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r399w1DP027196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 9 Apr 2013 04:58:02 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r399w1Dg000734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Apr 2013 05:58:01 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 9 Apr 2013 05:58:01 -0400 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.41]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 9 Apr 2013 11:57:29 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Benoit Claise Thread-Topic: IPFIX-based identification of RTP traffic with support of RTP-specific information elements? Thread-Index: Ac41CKSYOcuk6JVRSiWutyoB+Kz83A== Date: Tue, 9 Apr 2013 09:57:28 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC02257B@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "ipfix@ietf.org" Subject: [IPFIX] IPFIX-based identification of RTP traffic with support of RTP-specific information elements? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 09:58:04 -0000 Hi Benoit, et al., just a quick question for clarification, would expect that this topic was a= lready discussed by the IPFIX community in the past: The IPFIX registry only lists the RTP SN (RFC 3550) element: http://www.iana.org/assignments/ipfix/ipfix.xml=20 =3D> rtpSequenceNumber=20 I'm wondering about support of more RTP-specific elements, which would be e= .g. required for more fine-granular identification of RTP/RTCP (sub-flows)? Such as support of a) RTP: - RTP PT (payload type)| RTCP PT (packet type) - RTP SSRC - RTP CSCR(s) b) RTCP basic reports: - RTCP SDES CNAME - etc c) RTCP extension reports (RFC 3611, XRBLOCK): - RTCP XR BT - etc Looks odd that the IANA registry just provides the RTP SN, because the SSRC= or/and CNAME might be much more interesting for traffic identification pur= poses. Hm? Regards, Albrecht PS I've noticed the " draft-scholz-ipfix-rtp-audio-quality" proposal. Prime purpose is (in my understanding) the export of LOCAL measurements, e.= g. according RTCP XR BT=3D7 or other RTP application-level performance metr= ic types according XRBLOCK. However, if such measurements would be REMOTELY generated AND reported alon= g the IP media path using RTCP XR reports (see RFC 6792), then the IPFIX en= tity could identify and export such measurements ... if there would by IPFI= X information elements available ("which is basically feasible ...") ... i.= e. another category in above list. __________________________________________________ Dr. Albrecht Schwarz Alcatel-Lucent Albrecht.Schwarz@alcatel-lucent.com=20 From michael.krueger@voipfuture.com Tue Apr 9 04:32:49 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01E421F8D00 for ; Tue, 9 Apr 2013 04:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQFC05R7x+0p for ; Tue, 9 Apr 2013 04:32:48 -0700 (PDT) Received: from mail.voipfuture.com (mail.voipfuture.com [212.126.220.242]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE9021F8A52 for ; Tue, 9 Apr 2013 04:32:47 -0700 (PDT) X-Footer: dm9pcGZ1dHVyZS5jb20= Received: from mickru-mac.voipfuture.com ([192.168.1.1]) (authenticated user mkrueger@voipfuture.com) by mail.voipfuture.com (Kerio Connect 8.0.1) (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Tue, 9 Apr 2013 13:32:41 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: =?iso-8859-1?Q?Michael_Kr=FCger?= In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC02257B@FR711WXCHMBA03.zeu.alcatel-lucent.com> Date: Tue, 9 Apr 2013 13:32:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <39EF738B-E69B-425E-8E6C-8F739BC50CEC@voipfuture.com> References: <786615F3A85DF44AA2A76164A71FE1AC02257B@FR711WXCHMBA03.zeu.alcatel-lucent.com> To: "Schwarz, Albrecht (Albrecht)" X-Mailer: Apple Mail (2.1503) Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX-based identification of RTP traffic with support of RTP-specific information elements? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 11:32:49 -0000 Hi Albrecht, et al., Am 09.04.2013 um 11:57 schrieb "Schwarz, Albrecht (Albrecht)" = : > Hi Benoit, et al., >=20 > just a quick question for clarification, would expect that this topic = was already discussed by the IPFIX community in the past: >=20 > The IPFIX registry only lists the RTP SN (RFC 3550) element: > http://www.iana.org/assignments/ipfix/ipfix.xml=20 > =3D> rtpSequenceNumber=20 >=20 > I'm wondering about support of more RTP-specific elements, which would = be e.g. required for more fine-granular identification of RTP/RTCP = (sub-flows)? > Such as support of > a) RTP: > - RTP PT (payload type)| RTCP PT (packet type) > - RTP SSRC > - RTP CSCR(s) >=20 > b) RTCP basic reports: > - RTCP SDES CNAME > - etc >=20 > c) RTCP extension reports (RFC 3611, XRBLOCK): > - RTCP XR BT > - etc >=20 > Looks odd that the IANA registry just provides the RTP SN, because the = SSRC or/and CNAME might be much more interesting for traffic = identification purposes. Hm? My understanding is that the flowId can be used to identify a RTP flow. = The parameters to define a flowId label may be the IP addresses and = ports, but I guess within your own domain you are free to hash in the = RTP PT, SSRC and CSRC values. But you are right that it could be = beneficial to be able to report those values directly. But for the = purpose of identifying a RTP flow the flowId may do the job just fine.=20= >=20 > Regards, > Albrecht >=20 > PS > I've noticed the " draft-scholz-ipfix-rtp-audio-quality" proposal. > Prime purpose is (in my understanding) the export of LOCAL = measurements, e.g. according RTCP XR BT=3D7 or other RTP = application-level performance metric types according XRBLOCK. > However, if such measurements would be REMOTELY generated AND reported = along the IP media path using RTCP XR reports (see RFC 6792), then the = IPFIX entity could identify and export such measurements ... if there = would by IPFIX information elements available ("which is basically = feasible ...") ... i.e. another category in above list. The purpose of that draft is to report quality metric from mid-point = measurements from e.g passive network monitoring tools. Therefore = mid-point injection of RTCP-XR packets is not an option for that draft = proposal. Furthermore our practical experience shows that RTCP packets = are most often blocked in the network and therefore not a perfect fit = for quality reporting in our opinion. The intention is rather to have a = common set of elements defined that can be used to report RTP quality = monitoring results, and then send via other protocols and network = connections to data collection / reporting systems or mediation devices. Regards, Michael >=20 >=20 > __________________________________________________ > Dr. Albrecht Schwarz > Alcatel-Lucent > Albrecht.Schwarz@alcatel-lucent.com=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From albrecht.schwarz@alcatel-lucent.com Tue Apr 9 06:04:36 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498F221F9138 for ; Tue, 9 Apr 2013 06:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyPx9obtzDOs for ; Tue, 9 Apr 2013 06:04:35 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 09B7621F905B for ; Tue, 9 Apr 2013 06:04:34 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r39D4Xlh018225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 9 Apr 2013 08:04:34 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r39D4TvQ026243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Apr 2013 09:04:33 -0400 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 9 Apr 2013 09:04:31 -0400 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.41]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 9 Apr 2013 15:04:17 +0200 From: "Schwarz, Albrecht (Albrecht)" To: =?iso-8859-1?Q?Michael_Kr=FCger?= Thread-Topic: [IPFIX] IPFIX-based identification of RTP traffic with support of RTP-specific information elements? Thread-Index: Ac41CKSYOcuk6JVRSiWutyoB+Kz83P//+ROA///GL9A= Date: Tue, 9 Apr 2013 13:04:16 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC02289D@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <786615F3A85DF44AA2A76164A71FE1AC02257B@FR711WXCHMBA03.zeu.alcatel-lucent.com> <39EF738B-E69B-425E-8E6C-8F739BC50CEC@voipfuture.com> In-Reply-To: <39EF738B-E69B-425E-8E6C-8F739BC50CEC@voipfuture.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-based identification of RTP traffic with support of RTP-specific information elements? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 13:04:36 -0000 Michael, I'm aware that existing IPFIX elements are sufficient for the identificatio= n of "legacy" RTP traffic, which means without any multiplexing scheme. However, "RTP multiplexing" models (at various levels), - as e.g. discussed= by RTCWEB and CLUE (also AVTCORE, RTPEXT, MMUSIC) -, require the additiona= l consideration of further, RTP specific elements, as outlined by my initia= l email. Thus, my question is still open ... Albrecht -----Original Message----- From: Michael Kr=FCger [mailto:michael.krueger@voipfuture.com]=20 Sent: Dienstag, 9. April 2013 13:33 To: Schwarz, Albrecht (Albrecht) Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX-based identification of RTP traffic with support= of RTP-specific information elements? Hi Albrecht, et al., Am 09.04.2013 um 11:57 schrieb "Schwarz, Albrecht (Albrecht)" : > Hi Benoit, et al., >=20 > just a quick question for clarification, would expect that this topic was= already discussed by the IPFIX community in the past: >=20 > The IPFIX registry only lists the RTP SN (RFC 3550) element: > http://www.iana.org/assignments/ipfix/ipfix.xml=20 > =3D> rtpSequenceNumber=20 >=20 > I'm wondering about support of more RTP-specific elements, which would be= e.g. required for more fine-granular identification of RTP/RTCP (sub-flows= )? > Such as support of > a) RTP: > - RTP PT (payload type)| RTCP PT (packet type) > - RTP SSRC > - RTP CSCR(s) >=20 > b) RTCP basic reports: > - RTCP SDES CNAME > - etc >=20 > c) RTCP extension reports (RFC 3611, XRBLOCK): > - RTCP XR BT > - etc >=20 > Looks odd that the IANA registry just provides the RTP SN, because the SS= RC or/and CNAME might be much more interesting for traffic identification p= urposes. Hm? My understanding is that the flowId can be used to identify a RTP flow. The= parameters to define a flowId label may be the IP addresses and ports, but= I guess within your own domain you are free to hash in the RTP PT, SSRC an= d CSRC values. But you are right that it could be beneficial to be able to = report those values directly. But for the purpose of identifying a RTP flow= the flowId may do the job just fine.=20 >=20 > Regards, > Albrecht >=20 > PS > I've noticed the " draft-scholz-ipfix-rtp-audio-quality" proposal. > Prime purpose is (in my understanding) the export of LOCAL measurements, = e.g. according RTCP XR BT=3D7 or other RTP application-level performance me= tric types according XRBLOCK. > However, if such measurements would be REMOTELY generated AND reported al= ong the IP media path using RTCP XR reports (see RFC 6792), then the IPFIX = entity could identify and export such measurements ... if there would by IP= FIX information elements available ("which is basically feasible ...") ... = i.e. another category in above list. The purpose of that draft is to report quality metric from mid-point measur= ements from e.g passive network monitoring tools. Therefore mid-point injec= tion of RTCP-XR packets is not an option for that draft proposal. Furthermo= re our practical experience shows that RTCP packets are most often blocked = in the network and therefore not a perfect fit for quality reporting in our= opinion. The intention is rather to have a common set of elements defined = that can be used to report RTP quality monitoring results, and then send vi= a other protocols and network connections to data collection / reporting sy= stems or mediation devices. Regards, Michael >=20 >=20 > __________________________________________________ > Dr. Albrecht Schwarz > Alcatel-Lucent > Albrecht.Schwarz@alcatel-lucent.com=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From andrewf@plixer.com Tue Apr 9 07:32:38 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AA621F91D4 for ; Tue, 9 Apr 2013 07:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 991zIQoCoCl8 for ; Tue, 9 Apr 2013 07:32:37 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [64.140.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id C8F2621F9104 for ; Tue, 9 Apr 2013 07:32:36 -0700 (PDT) Received: from [10.11.1.15] ([10.11.1.15]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Apr 2013 10:32:34 -0400 Message-ID: <51642689.3070409@plixer.com> Date: Tue, 09 Apr 2013 10:32:41 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Schwarz, Albrecht (Albrecht)" References: <786615F3A85DF44AA2A76164A71FE1AC02257B@FR711WXCHMBA03.zeu.alcatel-lucent.com> <39EF738B-E69B-425E-8E6C-8F739BC50CEC@voipfuture.com> <786615F3A85DF44AA2A76164A71FE1AC02289D@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC02289D@FR711WXCHMBA03.zeu.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------090701030908000906050108" X-OriginalArrivalTime: 09 Apr 2013 14:32:34.0317 (UTC) FILETIME=[13424BD0:01CE352F] Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-based identification of RTP traffic with support of RTP-specific information elements? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 14:32:38 -0000 This is a multi-part message in MIME format. --------------090701030908000906050108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi all, I am already seeing ssrc from several vendors each with their own IEs. I'd be in favor of proposing something like the following as a starting point. I'm not an RTP expert though so comments and/or improvements are welcome. Name: rtpSSRCId {or maybe rtpSsrcId} Type: unsigned32 Semantic: identifier Description: RTP syncronization source identifier [ RFC 3551] Name: rtpPayloadEncodingId Type: unsigned32 Semantic: identifier Description: RTP payload type identifier as defined in [RFC 3551] Name: rtpPayloadEncodingName Type: string Semantic: default Description: RTP payload type name [RFC 3551] Thoughts? -Andrew On 04/09/2013 09:04 AM, Schwarz, Albrecht (Albrecht) wrote: > Michael, > I'm aware that existing IPFIX elements are sufficient for the identification of "legacy" RTP traffic, which means without any multiplexing scheme. > > However, "RTP multiplexing" models (at various levels), - as e.g. discussed by RTCWEB and CLUE (also AVTCORE, RTPEXT, MMUSIC) -, require the additional consideration of further, RTP specific elements, as outlined by my initial email. > > Thus, my question is still open ... > > Albrecht > > -----Original Message----- > From: Michael Krger [mailto:michael.krueger@voipfuture.com] > Sent: Dienstag, 9. April 2013 13:33 > To: Schwarz, Albrecht (Albrecht) > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] IPFIX-based identification of RTP traffic with support of RTP-specific information elements? > > Hi Albrecht, et al., > > > Am 09.04.2013 um 11:57 schrieb "Schwarz, Albrecht (Albrecht)" : > >> Hi Benoit, et al., >> >> just a quick question for clarification, would expect that this topic was already discussed by the IPFIX community in the past: >> >> The IPFIX registry only lists the RTP SN (RFC 3550) element: >> http://www.iana.org/assignments/ipfix/ipfix.xml >> => rtpSequenceNumber >> >> I'm wondering about support of more RTP-specific elements, which would be e.g. required for more fine-granular identification of RTP/RTCP (sub-flows)? >> Such as support of >> a) RTP: >> - RTP PT (payload type)| RTCP PT (packet type) >> - RTP SSRC >> - RTP CSCR(s) >> >> b) RTCP basic reports: >> - RTCP SDES CNAME >> - etc >> >> c) RTCP extension reports (RFC 3611, XRBLOCK): >> - RTCP XR BT >> - etc >> >> Looks odd that the IANA registry just provides the RTP SN, because the SSRC or/and CNAME might be much more interesting for traffic identification purposes. Hm? > My understanding is that the flowId can be used to identify a RTP flow. The parameters to define a flowId label may be the IP addresses and ports, but I guess within your own domain you are free to hash in the RTP PT, SSRC and CSRC values. But you are right that it could be beneficial to be able to report those values directly. But for the purpose of identifying a RTP flow the flowId may do the job just fine. > >> Regards, >> Albrecht >> >> PS >> I've noticed the " draft-scholz-ipfix-rtp-audio-quality" proposal. >> Prime purpose is (in my understanding) the export of LOCAL measurements, e.g. according RTCP XR BT=7 or other RTP application-level performance metric types according XRBLOCK. >> However, if such measurements would be REMOTELY generated AND reported along the IP media path using RTCP XR reports (see RFC 6792), then the IPFIX entity could identify and export such measurements ... if there would by IPFIX information elements available ("which is basically feasible ...") ... i.e. another category in above list. > The purpose of that draft is to report quality metric from mid-point measurements from e.g passive network monitoring tools. Therefore mid-point injection of RTCP-XR packets is not an option for that draft proposal. Furthermore our practical experience shows that RTCP packets are most often blocked in the network and therefore not a perfect fit for quality reporting in our opinion. The intention is rather to have a common set of elements defined that can be used to report RTP quality monitoring results, and then send via other protocols and network connections to data collection / reporting systems or mediation devices. > > Regards, > Michael > >> >> __________________________________________________ >> Dr. Albrecht Schwarz >> Alcatel-Lucent >> Albrecht.Schwarz@alcatel-lucent.com >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------090701030908000906050108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi all,

I am already seeing ssrc from several vendors each with their own IEs.  I'd be in favor of proposing something like the following as a starting point.  I'm not an RTP expert though so comments and/or improvements are welcome.

Name: rtpSSRCId  {or maybe rtpSsrcId}
Type: unsigned32
Semantic: identifier
Description: RTP syncronization source identifier [ RFC 3551]


Name: rtpPayloadEncodingId
Type: unsigned32
Semantic: identifier
Description: RTP payload type identifier as defined in [RFC 3551]


Name: rtpPayloadEncodingName
Type: string
Semantic: default
Description: RTP payload type name [RFC 3551]


Thoughts?

-Andrew


On 04/09/2013 09:04 AM, Schwarz, Albrecht (Albrecht) wrote:
Michael,
I'm aware that existing IPFIX elements are sufficient for the identification of "legacy" RTP traffic, which means without any multiplexing scheme.

However, "RTP multiplexing" models (at various levels), - as e.g. discussed by RTCWEB and CLUE (also AVTCORE, RTPEXT, MMUSIC) -, require the additional consideration of further, RTP specific elements, as outlined by my initial email.

Thus, my question is still open ...

Albrecht

-----Original Message-----
From: Michael Krüger [mailto:michael.krueger@voipfuture.com] 
Sent: Dienstag, 9. April 2013 13:33
To: Schwarz, Albrecht (Albrecht)
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] IPFIX-based identification of RTP traffic with support of RTP-specific information elements?

Hi Albrecht, et al.,


Am 09.04.2013 um 11:57 schrieb "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>:


Hi Benoit, et al.,

just a quick question for clarification, would expect that this topic was already discussed by the IPFIX community in the past:

The IPFIX registry only lists the RTP SN (RFC 3550) element:
 http://www.iana.org/assignments/ipfix/ipfix.xml 
 => rtpSequenceNumber 

I'm wondering about support of more RTP-specific elements, which would be e.g. required for more fine-granular identification of RTP/RTCP (sub-flows)?
Such as support of
a) RTP:
- RTP PT (payload type)| RTCP PT (packet type)
- RTP SSRC
- RTP CSCR(s)

b) RTCP basic reports:
- RTCP SDES CNAME
- etc

c) RTCP extension reports (RFC 3611, XRBLOCK):
- RTCP XR BT
- etc

Looks odd that the IANA registry just provides the RTP SN, because the SSRC or/and CNAME might be much more interesting for traffic identification purposes. Hm?

My understanding is that the flowId can be used to identify a RTP flow. The parameters to define a flowId label may be the IP addresses and ports, but I guess within your own domain you are free to hash in the RTP PT, SSRC and CSRC values. But you are right that it could be beneficial to be able to report those values directly. But for the purpose of identifying a RTP flow the flowId may do the job just fine. 


Regards,
Albrecht

PS
I've noticed the " draft-scholz-ipfix-rtp-audio-quality" proposal.
Prime purpose is (in my understanding) the export of LOCAL measurements, e.g. according RTCP XR BT=7 or other RTP application-level performance metric types according XRBLOCK.
However, if such measurements would be REMOTELY generated AND reported along the IP media path using RTCP XR reports (see RFC 6792), then the IPFIX entity could identify and export such measurements ... if there would by IPFIX information elements available ("which is basically feasible ...") ... i.e. another category in above list.

The purpose of that draft is to report quality metric from mid-point measurements from e.g passive network monitoring tools. Therefore mid-point injection of RTCP-XR packets is not an option for that draft proposal. Furthermore our practical experience shows that RTCP packets are most often blocked in the network and therefore not a perfect fit for quality reporting in our opinion. The intention is rather to have a common set of elements defined that can be used to report RTP quality monitoring results, and then send via other protocols and network connections to data collection / reporting systems or mediation devices.

Regards,
Michael



__________________________________________________
Dr. Albrecht Schwarz
Alcatel-Lucent
Albrecht.Schwarz@alcatel-lucent.com 
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix



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

--------------090701030908000906050108-- From internet-drafts@ietf.org Tue Apr 9 07:47:23 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E54921F93DC; Tue, 9 Apr 2013 07:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndPaHAATh-pm; Tue, 9 Apr 2013 07:47:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DC521F93D2; Tue, 9 Apr 2013 07:47:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130409144722.31483.32304.idtracker@ietfa.amsl.com> Date: Tue, 09 Apr 2013 07:47:22 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-flow-selection-tech-15.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 14:47:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Group = of the IETF. Title : Flow Selection Techniques Author(s) : Salvatore D'Antonio Tanja Zseby Christian Henke Lorenzo Peluso Filename : draft-ietf-ipfix-flow-selection-tech-15.txt Pages : 32 Date : 2013-04-09 Abstract: Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IPFIX Exporter, Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-tech-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-flow-selection-tech-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From salvatore.dantonio@uniparthenope.it Tue Apr 9 08:40:37 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6407621F97A8; Tue, 9 Apr 2013 08:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.127 X-Spam-Level: ** X-Spam-Status: No, score=2.127 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEnIxUhvZSvT; Tue, 9 Apr 2013 08:40:36 -0700 (PDT) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by ietfa.amsl.com (Postfix) with ESMTP id B09E121F9798; Tue, 9 Apr 2013 08:40:32 -0700 (PDT) Received: from mail2.uniparthenope.it (unknown [10.1.2.108]) by mail.uniparthenope.it (Postfix) with SMTP id EA27A41711; Tue, 9 Apr 2013 15:40:30 +0000 (UTC) Received: from (unknown [192.168.241.108]) by mail2.uniparthenope.it with smtp id 1d43_cec0a27c_a12b_11e2_9101_001372515a5c; Tue, 09 Apr 2013 17:40:30 +0200 Received: from spamk.uniparthenope.it (localhost [127.0.0.1]) by spamk.uniparthenope.it (Postfix) with ESMTP id C174CC430A; Tue, 9 Apr 2013 17:40:29 +0200 (CEST) Received: by spamk.uniparthenope.it (Postfix, from userid 500) id BA7F1C4302; Tue, 9 Apr 2013 17:40:29 +0200 (CEST) Received: from mail.uniparthenope.it (unknown [192.168.241.109]) by spamk.uniparthenope.it (Postfix) with ESMTP id 593DCC4301; Tue, 9 Apr 2013 17:40:28 +0200 (CEST) Received: by mail.uniparthenope.it (Postfix, from userid 108) id 452064181E; Tue, 9 Apr 2013 17:40:28 +0200 (CEST) Received: from saldantoPC (unknown [192.168.162.11]) (Authenticated sender: salvatore.dantonio@uniparthenope.it) by mail.uniparthenope.it (Postfix) with ESMTPA id 803F841526; Tue, 9 Apr 2013 17:40:18 +0200 (CEST) From: "Salvatore D'Antonio" To: "'Benoit Claise'" , References: <20130401072846.32360.9502.idtracker@ietfa.amsl.com> <5162C44B.5030904@cisco.com> In-Reply-To: <5162C44B.5030904@cisco.com> Date: Tue, 9 Apr 2013 17:40:03 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac40XDRV3pT1xDzNTsGp6osHVZb3KAA1rsdA Content-Language: it Message-ID: <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it> Content-Type: multipart/alternative; boundary="----=_NextPart_000_0058_01CE3549.52940480" X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.42/RELEASE, bases: 20130409 #9883311, check: 20130409 clean Cc: 'IETF discussion list' , apps-discuss@ietf.org, 'General Area Review Team' , 'S Moonesamy' , ipfix-chairs@tools.ietf.org, ipfix@ietf.org, iesg@ietf.org, "'Joel M. Halpern'" , "'A. Jean Mahoney'" Subject: [IPFIX] R: Last Call Expired: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 15:40:37 -0000 Messaggio multipart in formato MIME. ------=_NextPart_000_0058_01CE3549.52940480 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dear all, =20 A new version of the Internet Draft on Flow Selection Techniques has = been submitted. It contains the following changes: - A new section illustrating the difference between = Intermediate Flow Selection Process and Intermediate Selection Process = has been added, - The sentence "In order to be compliant with this document, at = least the Property Match Filtering MUST be implemented." has been = removed in Section 1, - =E2=80=9CMUST=E2=80=9D has been replaced with = =E2=80=9CSHOULD=E2=80=9D in Section 5.1, - =E2=80=9CThe flowSelectorAlgorithm registry is maintained by = IANA." has been replaced with =E2=80=9CIANA is requested to create the = flowSelectorAlgorithm registry.=E2=80=9D - The sentence "The registry can be updated when specifications = of the new technique(s) and any new Information Elements are provided." = has been removed since it did not clarify how the registry will be = managed. - Section 6.1.1 =E2=80=9CProperty Match Filtering=E2=80=9D has = been changed by adding some text on how Property Match Filtering can be = used by an Intermediate Flow Selection Process in the Metering Process, = in the Exporting Process and within an IPFIX Mediator. =20 Best regards, =20 Salvatore =20 Da: Benoit Claise [mailto:bclaise@cisco.com]=20 Inviato: luned=C3=AC 8 aprile 2013 15:21 A: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org Cc: ipfix-chairs@tools.ietf.org Oggetto: Fwd: Last Call Expired: = =20 Dear authors, The IETF last call has finished. Can you please update your draft based on the feedback received. Then I will progress it. Regards, Benoit -------- Original Message --------=20 Subject:=20 Last Call Expired: Date:=20 Mon, 01 Apr 2013 00:28:46 -0700 From:=20 DraftTracker Mail System = To:=20 iesg@ietf.org, ipfix-chairs@tools.ietf.org, = draft-ietf-ipfix-flow-selection-tech@tools.ietf.org CC:=20 iesg-secretary@ietf.org =20 Please DO NOT reply to this email. =20 I-D: ID Tracker URL: = http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ =20 IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. =20 =20 =20 =20 =20 _____ =20 Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 2013.0.3272 / Database dei virus: 3162/6231 - Data di = rilascio: 07/04/2013 ******************************************************************************=09=0A IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO=0A =0A Il 5 per mille all'Universita' degli Studi di Napoli "Parthenope" incrementa le borse di studio agli studenti - codice fiscale 80018240632=0A http://www.uniparthenope.it/index.php/5xmille =0A =0A http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille=0A =0A Questa informativa e' inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente.=0A ------=_NextPart_000_0058_01CE3549.52940480 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Dear all,

 

A new version of the Internet Draft on Flow Selection = Techniques has been submitted. It contains the following = changes:

-          A new section illustrating the difference between = Intermediate Flow Selection Process and Intermediate Selection Process has been = added,

-          The sentence "In order to be compliant with this = document, at least the Property =C2=A0Match Filtering MUST be implemented." = has been removed in Section 1,

-          =E2=80=9CMUST=E2=80=9D has been replaced with = =E2=80=9CSHOULD=E2=80=9D in Section 5.1,

-          =E2=80=9CThe flowSelectorAlgorithm registry is maintained = by IANA." has been replaced with =E2=80=9CIANA is requested to create the = flowSelectorAlgorithm registry.=E2=80=9D

-          The sentence "The registry can be updated when specifications of the new=C2=A0 technique(s) and any new Information = Elements are provided." has been removed since it did not clarify how the = registry will be managed.

-          =C2=A0Section 6.1.1 =E2=80=9CProperty Match = Filtering=E2=80=9D has been changed by adding some text on how Property Match Filtering can be =C2=A0used by an Intermediate Flow Selection Process in the Metering Process, in the = =C2=A0Exporting Process and within an IPFIX Mediator.

 

Best regards,

 

Salvatore

 

Da: Benoit Claise [mailto:bclaise@cisco.com]
Inviato: luned=C3=AC 8 aprile 2013 15:21
A: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org
Cc: ipfix-chairs@tools.ietf.org
Oggetto: Fwd: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

=

 

Dear authors,

The IETF last call has finished.
Can you please update your draft based on the feedback received.
Then I will progress it.

Regards, Benoit



-------- Original Message --------

Subject:

Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

Date: =

Mon, 01 Apr 2013 00:28:46 -0700

From: =

DraftTracker Mail System <iesg-secretary@ietf.org>

To: =

iesg@ietf.org, ipfix-chairs@tools.ietf.org, draft= -ietf-ipfix-flow-selection-tech@tools.ietf.org

CC: =

iesg-secretary@ietf.org<= /o:p>

 

Please DO NOT reply to this =
email.
 
I-D: =
<draft-ietf-ipfix-flow-selection-tech-14.txt>
=
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tec=
h/
 
IETF Last Call =
has ended, and the state has been changed =
to
Waiting for AD =
Go-Ahead.
 
 
 

 

 

Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2013.0.3272 / Database dei virus: 3162/6231 - Data di = rilascio: 07/04/2013


= =0A =0A

=0A

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

=0A

IL=0A MERITO DEGLI STUDENTI VIENE RICONOSCIUTO

=0A

 

=0A

Il=0A 5 per mille all'Università degli Studi di Napoli "Parthenope"incrementa le borse di studio agli studenti=0A - codice fiscale 80018240632=0A =0A

=0A

http://www.uniparthenope.it/index.php/5xmille 

=0A

 

=0A

http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille

=0A

 
Questa=0A informativa è inserita in automatico dal sistema al fine esclusivo=0A della realizzazione dei fini istituzionali dell'ente.

=0A


=0A

=0A =0A =0A
=
= =0A =0A

=0A

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

=0A

IL=0A MERITO DEGLI STUDENTI VIENE RICONOSCIUTO

=0A

 

=0A

Il=0A 5 per mille all'Università degli Studi di Napoli "Parthenope"incrementa le borse di studio agli studenti=0A - codice fiscale 80018240632=0A =0A

=0A

http://www.uniparthenope.it/index.php/5xmille 

=0A

 

=0A

http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille

=0A

 
Questa=0A informativa è inserita in automatico dal sistema al fine esclusivo=0A della realizzazione dei fini istituzionali dell'ente.

=0A


=0A

=0A =0A =0A
= ------=_NextPart_000_0058_01CE3549.52940480-- From sm@elandsys.com Tue Apr 9 12:58:53 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D6421F9814; Tue, 9 Apr 2013 12:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXSbQPiUEsHE; Tue, 9 Apr 2013 12:58:53 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFA021F97E7; Tue, 9 Apr 2013 12:58:52 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.142.138]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r39JwZkW002050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Apr 2013 12:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1365537530; bh=XPQhi/UzwEcHf0ucKeHF9M92R7Z52WQ4bu/FZV7/BMw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=T8fEYyhh5nUm7bIAPBb71Ho7uZCpgi/bUStrRgm1XFsI84g07uY2aF6z3aC4e1Pth LSXGHai5g+2+S4AS4LmnermZ2KhdgnNCkFLlMvrin2+BJ13i+xZkeRW/ni/b81rq28 PoNRu7r9xF5cSBc0PNVvKFXSqWeN1ZzptNrSXClY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1365537530; i=@elandsys.com; bh=XPQhi/UzwEcHf0ucKeHF9M92R7Z52WQ4bu/FZV7/BMw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oSS3jGaLWIPHM0HZ8yurSgzMZMenqJiiPlfhNX9Qxfshv8J3VQSb/p+DrVNrNewHM 4K4NY6VGm+0HIMQskJIiSH476wAUQ0kqGuj5scBlKJHPAzLPo8kVqKPvPxzZJqH4jy H1q90i6aYr8CbuKicuCkyQQPtRtacyzZB7kd/fGA= Message-Id: <6.2.5.6.2.20130409084702.0c6104b8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 09 Apr 2013 09:10:18 -0700 To: "Salvatore D'Antonio" , draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org From: S Moonesamy In-Reply-To: <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it> References: <20130401072846.32360.9502.idtracker@ietfa.amsl.com> <5162C44B.5030904@cisco.com> <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Tue, 09 Apr 2013 14:35:35 -0700 Cc: ipfix@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [IPFIX] R: Last Call Expired: (APPSDIR review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 19:58:54 -0000 Hi Salvatore, At 08:40 09-04-2013, Salvatore D'Antonio wrote: >- The sentence "The registry can be updated when >specifications of the new technique(s) and any new Information >Elements are provided." has been removed since it did not clarify >how the registry will be managed. This is a follow-up to the APPSDIR review of draft-ietf-ipfix-flow-selection-tech ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09239.html ) From Section 9.1.1 of draft-ietf-ipfix-flow-selection-tech-15: "New assignments for the registry will be administered by IANA and are subject to Expert Review [RFC5226]." draft-ietf-ipfix-flow-selection-tech-15 defines a sub-registry. It does not provide any relevant details about the sub-registry. What documentation is required and which criteria will be used for assignments in the new sub-registry? Regards, S. Moonesamy From albrecht.schwarz@alcatel-lucent.com Wed Apr 10 00:05:13 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB4121F9030 for ; Wed, 10 Apr 2013 00:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4CLueK6vRwc for ; Wed, 10 Apr 2013 00:05:09 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id AC39C21F9007 for ; Wed, 10 Apr 2013 00:05:09 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r3A757dg017984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Apr 2013 02:05:08 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r3A74qpa022894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Apr 2013 03:05:06 -0400 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 10 Apr 2013 03:05:00 -0400 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.41]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 10 Apr 2013 09:04:43 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Andrew Feren Thread-Topic: [IPFIX] IPFIX-based identification of RTP traffic with support of RTP-specific information elements? Thread-Index: Ac41CKSYOcuk6JVRSiWutyoB+Kz83P//+ROA///GL9CAAGwcgP/+yqZA Date: Wed, 10 Apr 2013 07:04:43 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC022C7D@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <786615F3A85DF44AA2A76164A71FE1AC02257B@FR711WXCHMBA03.zeu.alcatel-lucent.com> <39EF738B-E69B-425E-8E6C-8F739BC50CEC@voipfuture.com> <786615F3A85DF44AA2A76164A71FE1AC02289D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <51642689.3070409@plixer.com> In-Reply-To: <51642689.3070409@plixer.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC022C7DFR711WXCHMBA03zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-based identification of RTP traffic with support of RTP-specific information elements? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 07:05:13 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC022C7DFR711WXCHMBA03zeu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andrew, that's already a step in that direction. Comments below. Regards, Albrecht From: Andrew Feren [mailto:andrewf@plixer.com] Sent: Dienstag, 9. April 2013 16:33 To: Schwarz, Albrecht (Albrecht) Cc: Michael Kr=FCger; ipfix@ietf.org Subject: Re: [IPFIX] IPFIX-based identification of RTP traffic with support= of RTP-specific information elements? Hi all, I am already seeing ssrc from several vendors each with their own IEs. I'd= be in favor of proposing something like the following as a starting point.= I'm not an RTP expert though so comments and/or improvements are welcome. Name: rtpSSRCId {or maybe rtpSsrcId} Type: unsigned32 Semantic: identifier Description: RTP syncronization source identifier [ RFC 3551] [ABS] RFC 3551 =3D RTP AVP Profile; Reference should be "basic" RTP =3D RFC= 3550 Name: rtpPayloadEncodingId Type: unsigned32 Semantic: identifier Description: RTP payload type identifier as defined in [RFC 3551] [ABS] ditto, ... =3D RFC 3550 Name: rtpPayloadEncodingName Type: string Semantic: default Description: RTP payload type name [RFC 3551] [ABS] Ref. correct, there are at least three other RTP profiles; Descripti= on might be improved, sth like: "Description: RTP payload type name according RTP AVP profile (and static c= odepoint assignments) [RFC 3551]" Thoughts? -Andrew On 04/09/2013 09:04 AM, Schwarz, Albrecht (Albrecht) wrote: Michael, I'm aware that existing IPFIX elements are sufficient for the identificatio= n of "legacy" RTP traffic, which means without any multiplexing scheme. However, "RTP multiplexing" models (at various levels), - as e.g. discussed= by RTCWEB and CLUE (also AVTCORE, RTPEXT, MMUSIC) -, require the additiona= l consideration of further, RTP specific elements, as outlined by my initia= l email. Thus, my question is still open ... Albrecht -----Original Message----- From: Michael Kr=FCger [mailto:michael.krueger@voipfuture.com] Sent: Dienstag, 9. April 2013 13:33 To: Schwarz, Albrecht (Albrecht) Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX-based identification of RTP traffic with support= of RTP-specific information elements? Hi Albrecht, et al., Am 09.04.2013 um 11:57 schrieb "Schwarz, Albrecht (Albrecht)" : Hi Benoit, et al., just a quick question for clarification, would expect that this topic was a= lready discussed by the IPFIX community in the past: The IPFIX registry only lists the RTP SN (RFC 3550) element: http://www.iana.org/assignments/ipfix/ipfix.xml =3D> rtpSequenceNumber I'm wondering about support of more RTP-specific elements, which would be e= .g. required for more fine-granular identification of RTP/RTCP (sub-flows)? Such as support of a) RTP: - RTP PT (payload type)| RTCP PT (packet type) - RTP SSRC - RTP CSCR(s) b) RTCP basic reports: - RTCP SDES CNAME - etc c) RTCP extension reports (RFC 3611, XRBLOCK): - RTCP XR BT - etc Looks odd that the IANA registry just provides the RTP SN, because the SSRC= or/and CNAME might be much more interesting for traffic identification pur= poses. Hm? My understanding is that the flowId can be used to identify a RTP flow. The= parameters to define a flowId label may be the IP addresses and ports, but= I guess within your own domain you are free to hash in the RTP PT, SSRC an= d CSRC values. But you are right that it could be beneficial to be able to = report those values directly. But for the purpose of identifying a RTP flow= the flowId may do the job just fine. Regards, Albrecht PS I've noticed the " draft-scholz-ipfix-rtp-audio-quality" proposal. Prime purpose is (in my understanding) the export of LOCAL measurements, e.= g. according RTCP XR BT=3D7 or other RTP application-level performance metr= ic types according XRBLOCK. However, if such measurements would be REMOTELY generated AND reported alon= g the IP media path using RTCP XR reports (see RFC 6792), then the IPFIX en= tity could identify and export such measurements ... if there would by IPFI= X information elements available ("which is basically feasible ...") ... i.= e. another category in above list. The purpose of that draft is to report quality metric from mid-point measur= ements from e.g passive network monitoring tools. Therefore mid-point injec= tion of RTCP-XR packets is not an option for that draft proposal. Furthermo= re our practical experience shows that RTCP packets are most often blocked = in the network and therefore not a perfect fit for quality reporting in our= opinion. The intention is rather to have a common set of elements defined = that can be used to report RTP quality monitoring results, and then send vi= a other protocols and network connections to data collection / reporting sy= stems or mediation devices. Regards, Michael __________________________________________________ Dr. Albrecht Schwarz Alcatel-Lucent Albrecht.Schwarz@alcatel-lucent.com _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --_000_786615F3A85DF44AA2A76164A71FE1AC022C7DFR711WXCHMBA03zeu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Andrew,

that’= ;s already a step in that direction.

Comments b= elow.

Regards,

Albrecht

 = ;

From:= Andrew Feren [mailt= o:andrewf@plixer.com]
Sent: Dienstag, 9. April 2013 16:33
To: Schwarz, Albrecht (Albrecht)
Cc: Michael Kr=FCger; ipfix@ietf.org
Subject: Re: [IPFIX] IPFIX-based identification of RTP traffic with = support of RTP-specific information elements?

 

Hi all,

I am already seeing ssrc from several vendors each with their own IEs. = ; I'd be in favor of proposing something like the following as a starting p= oint.  I'm not an RTP expert though so comments and/or improvements ar= e welcome.

Name: rtpSSRCId  {or maybe rtpSsrcId}
Type: unsigned32
Semantic: identifier
Description: RTP syncronization source identifier [ RFC 3551]

[ABS] RFC = 3551 =3D RTP AVP Profile; Reference should be “basic” RTP =3D R= FC 3550



Name: rtpPayloadEncodingId
Type: unsigned32
Semantic: identifier
Description: RTP payload type identifier as defined in [RFC 3551]

[ABS] &nbs= p;ditto, … =3D RFC 3550



Name: rtpPayloadEncodingName
Type: string
Semantic: default
Description: RTP payload type name [RFC 3551]

[ABS] &nbs= p;Ref. correct, there are at least three other RTP profiles; Description mi= ght be improved, sth like:

“Description: RTP payload= type name according RTP AVP profile (and sta= tic codepoint assignments) [RFC 3551]”



Thoughts?

-Andrew


On 04/09/2013 09:04 AM, Schwarz, Albrecht (Albrecht) wrote:

Michael,
I'm aware that existing IPFIX elements are sufficient for the identifi=
cation of "legacy" RTP traffic, which means without any multiplex=
ing scheme.
 
However, "RTP multiplexing" models (at various levels), - as=
 e.g. discussed by RTCWEB and CLUE (also AVTCORE, RTPEXT, MMUSIC) -, requir=
e the additional consideration of further, RTP specific elements, as outlin=
ed by my initial email.
 
Thus, my question is still open ...
 
Albrecht
 
-----Original Message-----
From: Michael Kr=FCger [mailto:michael.krueger@voipfuture.com] 
Sent: Dienstag, 9. April 2013 13:33
To: Schwarz, Albrecht (Albrecht)
Cc: ipfix@ietf.org

Subject: Re: [IPFIX] IPFIX-based identification of RTP traffic with su=
pport of RTP-specific information elements?


 


Hi Albrecht, et al.,


 


 


Am 09.04.2013 um 11:57 schrieb "Schwarz, Albrecht (Albrecht)"=
; <albrecht.schwa=
rz@alcatel-lucent.com>:


 




Hi Benoit, et al.,


 


just a quick question for clarification, would expect that this topic =
was already discussed by the IPFIX community in the past:


 


The IPFIX registry only lists the RTP SN (RFC 3550) element:


 http://ww=
w.iana.org/assignments/ipfix/ipfix.xml 


 =3D> rtpSequenceNumber 


 


I'm wondering about support of more RTP-specific elements, which would=
 be e.g. required for more fine-granular identification of RTP/RTCP (sub-fl=
ows)?


Such as support of


a) RTP:


- RTP PT (payload type)| RTCP PT (packet type)


- RTP SSRC


- RTP CSCR(s)


 


b) RTCP basic reports:


- RTCP SDES CNAME


- etc


 


c) RTCP extension reports (RFC 3611, XRBLOCK):


- RTCP XR BT


- etc


 


Looks odd that the IANA registry just provides the RTP SN, because the=
 SSRC or/and CNAME might be much more interesting for traffic identificatio=
n purposes. Hm?




 


My understanding is that the flowId can be used to identify a RTP flow=
. The parameters to define a flowId label may be the IP addresses and ports=
, but I guess within your own domain you are free to hash in the RTP PT, SS=
RC and CSRC values. But you are right that it could be beneficial to be abl=
e to report those values directly. But for the purpose of identifying a RTP=
 flow the flowId may do the job just fine. 


 




 


Regards,


Albrecht


 


PS


I've noticed the " draft-scholz-ipfix-rtp-audio-quality" pro=
posal.


Prime purpose is (in my understanding) the export of LOCAL measurement=
s, e.g. according RTCP XR BT=3D7 or other RTP application-level performance=
 metric types according XRBLOCK.


However, if such measurements would be REMOTELY generated AND reported=
 along the IP media path using RTCP XR reports (see RFC 6792), then the IPF=
IX entity could identify and export such measurements ... if there would by=
 IPFIX information elements available ("which is basically feasible ..=
.") ... i.e. another category in above list.




 


The purpose of that draft is to report quality metric from mid-point m=
easurements from e.g passive network monitoring tools. Therefore mid-point =
injection of RTCP-XR packets is not an option for that draft proposal. Furt=
hermore our practical experience shows that RTCP packets are most often blo=
cked in the network and therefore not a perfect fit for quality reporting i=
n our opinion. The intention is rather to have a common set of elements def=
ined that can be used to report RTP quality monitoring results, and then se=
nd via other protocols and network connections to data collection / reporti=
ng systems or mediation devices.


 


Regards,


Michael


 




 


 


__________________________________________________


Dr. Albrecht Schwarz


Alcatel-Lucent


Albrecht.Schwar=
z@alcatel-lucent.com 


_______________________________________________


IPFIX mailing list


IPFIX@ietf.org


https://www.ie=
tf.org/mailman/listinfo/ipfix




 


 


 


_______________________________________________


IPFIX mailing list


IPFIX@ietf.org


https://www.ie=
tf.org/mailman/listinfo/ipfix

 

--_000_786615F3A85DF44AA2A76164A71FE1AC022C7DFR711WXCHMBA03zeu_-- From salvatore.dantonio@uniparthenope.it Wed Apr 10 00:38:39 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A449D21F8967; Wed, 10 Apr 2013 00:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.034 X-Spam-Level: **** X-Spam-Status: No, score=4.034 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_QP_LONG_LINE=1.396, MSGID_MULTIPLE_AT=1.449, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MycF0rKyAD6i; Wed, 10 Apr 2013 00:38:39 -0700 (PDT) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by ietfa.amsl.com (Postfix) with ESMTP id A1AA221F884A; Wed, 10 Apr 2013 00:38:38 -0700 (PDT) Received: from mail2.uniparthenope.it (unknown [10.1.2.108]) by mail.uniparthenope.it (Postfix) with SMTP id 6CC9F4212D; Wed, 10 Apr 2013 07:38:37 +0000 (UTC) Received: from (unknown [192.168.241.108]) by mail2.uniparthenope.it with smtp id 4487_a7d795ae_a1b1_11e2_9101_001372515a5c; Wed, 10 Apr 2013 09:38:37 +0200 Received: from spamk.uniparthenope.it (localhost [127.0.0.1]) by spamk.uniparthenope.it (Postfix) with ESMTP id 16A56C4300; Wed, 10 Apr 2013 09:38:37 +0200 (CEST) Received: by spamk.uniparthenope.it (Postfix, from userid 500) id 1456BC4307; Wed, 10 Apr 2013 09:38:37 +0200 (CEST) Received: from mail.uniparthenope.it (unknown [192.168.241.109]) by spamk.uniparthenope.it (Postfix) with ESMTP id F0CA7C4305; Wed, 10 Apr 2013 09:38:35 +0200 (CEST) Received: by mail.uniparthenope.it (Postfix, from userid 108) id E1E604211A; Wed, 10 Apr 2013 09:38:35 +0200 (CEST) Received: from saldantoPC (unknown [2.237.123.176]) (Authenticated sender: salvatore.dantonio@uniparthenope.it) by mail.uniparthenope.it (Postfix) with ESMTPA id 4B33B41F83; Wed, 10 Apr 2013 09:38:35 +0200 (CEST) From: "Salvatore D'Antonio" To: "'S Moonesamy'" , References: <20130401072846.32360.9502.idtracker@ietfa.amsl.com> <5162C44B.5030904@cisco.com> <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it> <6.2.5.6.2.20130409084702.0c6104b8@elandnews.com> In-Reply-To: <6.2.5.6.2.20130409084702.0c6104b8@elandnews.com> Date: Wed, 10 Apr 2013 09:38:31 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac41YQamhJLMI8hqQ2mKGaq6vmybpgAW8Neg Content-Language: it Message-ID: <001501ce35be$68c93c00$3a5bb400$@dantonio@uniparthenope.it> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.42/RELEASE, bases: 20130410 #9875681, check: 20130410 clean Cc: ipfix@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: [IPFIX] R: R: Last Call Expired: (APPSDIR review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 07:38:39 -0000 Dear S. Moonesamy, I did not adequately addressed your comment because I thought that the guidelines specified in RFC 5226 were sufficient to deal with the issues concerning the management of the sub-registry. I would greatly appreciate if you could provide me with the reference to = a Draft where documentation and criteria for managing assignments are specified so that I may use such Draft as an example. Thanks a lot in advance. Best regards, Salvatore =20 -----Messaggio originale----- Da: S Moonesamy [mailto:sm+ietf@elandsys.com]=20 Inviato: marted=EC 9 aprile 2013 18:10 A: Salvatore D'Antonio; draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org Cc: apps-discuss@ietf.org; iesg@ietf.org; ipfix@ietf.org Oggetto: Re: R: Last Call Expired: (APPSDIR review) Hi Salvatore, At 08:40 09-04-2013, Salvatore D'Antonio wrote: >- The sentence "The registry can be updated when=20 >specifications of the new technique(s) and any new Information=20 >Elements are provided." has been removed since it did not clarify=20 >how the registry will be managed. This is a follow-up to the APPSDIR review of=20 draft-ietf-ipfix-flow-selection-tech (=20 http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09239.html = ) From Section 9.1.1 of draft-ietf-ipfix-flow-selection-tech-15: "New assignments for the registry will be administered by IANA and are subject to Expert Review [RFC5226]." draft-ietf-ipfix-flow-selection-tech-15 defines a sub-registry. It=20 does not provide any relevant details about the sub-registry. What=20 documentation is required and which criteria will be used for=20 assignments in the new sub-registry? Regards, S. Moonesamy=20 ----- Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 2013.0.3272 / Database dei virus: 3162/6234 - Data di = rilascio: 09/04/2013 ----- Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 2013.0.3272 / Database dei virus: 3162/6234 - Data di = rilascio: 09/04/2013 ****************************************************************************** IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO Il 5 per mille all'Universita' degli Studi di Napoli "Parthenope" incrementa le borse di studio agli studenti - codice fiscale 80018240632 http://www.uniparthenope.it/index.php/5xmille http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille Questa informativa e' inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente. From sm@elandsys.com Wed Apr 10 01:34:33 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB0B21F8FE8; Wed, 10 Apr 2013 01:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaTAkEgP2WfG; Wed, 10 Apr 2013 01:34:33 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BECA21F8FDF; Wed, 10 Apr 2013 01:34:32 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.212]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3A8YIVM021489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Apr 2013 01:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1365582871; bh=Nu0lSpMWgJhF0PKxIqrPZd7Tgt3yJ7jOUWJ2GIVvCLo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IyvPfLgxwOkFqCYj4/aaE4I84HObdAODF9baaG0XlBcEDs+c2Tu1+2L32EQjhw6N2 FwR2cUWkqdNAnIohh3b3T07xHAie0ZGXd3q53GpyzvOuKtkQ6hl/U97VTX4UeW6aNv RAGhsb+NKDidnitjrybwD4AiMN2ufSef0DBRpSQs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1365582871; i=@elandsys.com; bh=Nu0lSpMWgJhF0PKxIqrPZd7Tgt3yJ7jOUWJ2GIVvCLo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1Us48ceKpF22RVeRctjGJ8pJIyyPkxNyXidS10y1OZXVXAQIe6TjDBnAn7AbQlaoh Kz8ikQeiu1r4YpsR8tP2uq3+7RJyYd+7KFZG0vP6B+EUW8uxYWAFJ45yLpY/1Z4l0i 87tQmST4DQVSRizy3c3k5drqPysVAn5IVV9tugdA= Message-Id: <6.2.5.6.2.20130410010433.0ca8b920@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 10 Apr 2013 01:24:28 -0700 To: "Salvatore D'Antonio" , draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org From: S Moonesamy In-Reply-To: <001501ce35be$68c93c00$3a5bb400$@dantonio@uniparthenope.it> References: <20130401072846.32360.9502.idtracker@ietfa.amsl.com> <5162C44B.5030904@cisco.com> <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it> <6.2.5.6.2.20130409084702.0c6104b8@elandnews.com> <001501ce35be$68c93c00$3a5bb400$@dantonio@uniparthenope.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Wed, 10 Apr 2013 01:36:07 -0700 Cc: ipfix@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [IPFIX] Last Call Expired: (APPSDIR review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 08:34:34 -0000 Hi Salvatore, At 00:38 10-04-2013, Salvatore D'Antonio wrote: >I did not adequately addressed your comment because I thought that the >guidelines specified in RFC 5226 were sufficient to deal with the issues >concerning the management of the sub-registry. Ok. >I would greatly appreciate if you could provide me with the reference to a >Draft where documentation and criteria for managing assignments are >specified so that I may use such Draft as an example. Section 4.1 of RFC 5226 points to Sections 6 and 7.2 in RFC 3748 as an example about Expert Review. Section 7.1 of RFC 5102 is another example. I suggest discussing the proposed change with the document shepherd or the Area Director to see whether it is appropriate. Regards, S. Moonesamy From trammell@tik.ee.ethz.ch Wed Apr 10 18:24:37 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7B121F8A69 for ; Wed, 10 Apr 2013 18:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecCgg2eF2x3T for ; Wed, 10 Apr 2013 18:24:36 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 5614121F8A91 for ; Wed, 10 Apr 2013 18:24:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 82629D9499 for ; Thu, 11 Apr 2013 03:24:32 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hT9SbSgun0yu for ; Thu, 11 Apr 2013 03:24:32 +0200 (MEST) Received: from wifi-172-23-11-84.uoa-wifi.auckland.ac.nz (wireless-nat-3.auckland.ac.nz [130.216.30.114]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 6DD5ED9309 for ; Thu, 11 Apr 2013 03:24:31 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8E1B3C2E-2D3B-4F0E-B410-C71A26CAF0C8@tik.ee.ethz.ch> Date: Thu, 11 Apr 2013 13:24:27 +1200 To: "ipfix@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [IPFIX] Data type change for observationPointId X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 01:24:37 -0000 Greetings, all, Following discussion on the ipfix mailing list and review by the = ie-doctors, IE 138 in the IANA registry, observationPointId, has been = updated to change the data type from unsigned32 to unsigned64. Best regards, Brian (on behalf of the ie-doctors) From bclaise@cisco.com Mon Apr 15 02:44:32 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A8821F9393; Mon, 15 Apr 2013 02:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAhkDykt+3bA; Mon, 15 Apr 2013 02:44:30 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0A91921F938E; Mon, 15 Apr 2013 02:44:29 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3F9iA4R016779; Mon, 15 Apr 2013 11:44:10 +0200 (CEST) Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3F9glMg020166; Mon, 15 Apr 2013 11:43:07 +0200 (CEST) Message-ID: <516BCB97.9040404@cisco.com> Date: Mon, 15 Apr 2013 11:42:47 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Salvatore D'Antonio" References: <20130401072846.32360.9502.idtracker@ietfa.amsl.com> <5162C44B.5030904@cisco.com> <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it> In-Reply-To: <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it> Content-Type: multipart/alternative; boundary="------------040708030002030600080801" Cc: 'IETF discussion list' , draft-ietf-ipfix-flow-selection-tech@tools.ietf.org, apps-discuss@ietf.org, 'General Area Review Team' , 'S Moonesamy' , ipfix-chairs@tools.ietf.org, ipfix@ietf.org, iesg@ietf.org, "'Joel M. Halpern'" , "'A. Jean Mahoney'" Subject: Re: [IPFIX] R: Last Call Expired: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 09:44:32 -0000 This is a multi-part message in MIME format. --------------040708030002030600080801 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Salvatore > > Dear all, > > A new version of the Internet Draft on Flow Selection Techniques has > been submitted. It contains the following changes: > > -A new section illustrating the difference between Intermediate Flow > Selection Process and Intermediate Selection Process has been added, > > -The sentence "In order to be compliant with this document, at least > the Property Match Filtering MUST be implemented." has been removed > in Section 1, > > -“MUST” has been replaced with “SHOULD” in Section 5.1, > Actually, the feedback was: In Section 1: "In order to be compliant with this document, at least the Property Match Filtering MUST be implemented." The above text is repeated in Section 5.1. I suggest removing this sentence as it does not seem related to scope. My reading of the "MUST" is that it is being used for compliance instead of the reasons described in RFC 2119. I suggest reviewing the usage of RFC 2119 key words in Section 5.1. So the solution is not to change MUST to SHOULD. The question is whether "MUST" versus "must" must be used. I understand the concern. For compliance reason with the PSAMP RFC 5475 (which is closely related) ... 7 . Parameters for the Description of Selection Techniques This section gives an overview of different alternative selection schemes and their required parameters. In order to be compliant with PSAMP, at least one of proposed schemes MUST be implemented. ... I would keep the initial "MUST" from the previous draft version. > -“The flowSelectorAlgorithm registry is maintained by IANA." has been > replaced with “IANA is requested to create the flowSelectorAlgorithm > registry.” > > -The sentence "The registry can be updated when specifications of the > new technique(s) and any new Information Elements are provided." has > been removed since it did not clarify how the registry will be managed. > > - Section 6.1.1 “Property Match Filtering” has been changed by adding > some text on how Property Match Filtering can be used by an > Intermediate Flow Selection Process in the Metering Process, in the > Exporting Process and within an IPFIX Mediator. > When publishing a new version, please correct this editorial issue. " ... and Flow duration. in the An example is the selection of the largest ..." > Best regards, > > Salvatore > > *Da:*Benoit Claise [mailto:bclaise@cisco.com] > *Inviato:* lunedì 8 aprile 2013 15:21 > *A:* draft-ietf-ipfix-flow-selection-tech@tools.ietf.org > *Cc:* ipfix-chairs@tools.ietf.org > *Oggetto:* Fwd: Last Call Expired: > > > Dear authors, > > The IETF last call has finished. > Can you please update your draft based on the feedback received. > Then I will progress it. > > Regards, Benoit > > > > -------- Original Message -------- > > *Subject: * > > > > Last Call Expired: > > *Date: * > > > > Mon, 01 Apr 2013 00:28:46 -0700 > > *From: * > > > > DraftTracker Mail System > > > *To: * > > > > iesg@ietf.org , ipfix-chairs@tools.ietf.org > , > draft-ietf-ipfix-flow-selection-tech@tools.ietf.org > > > *CC: * > > > > iesg-secretary@ietf.org > > Please DO NOT reply to this email. > > I-D: > ID Tracker URL:http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ > > IETF Last Call has ended, and the state has been changed to > Waiting for AD Go-Ahead. > > > > > ------------------------------------------------------------------------ > > Nessun virus nel messaggio. > Controllato da AVG - www.avg.com > Versione: 2013.0.3272 / Database dei virus: 3162/6231 - Data di > rilascio: 07/04/2013 > > > ******************************************************************************************************* > > IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO > > Il 5 per mille all'Università degli Studi di Napoli > "Parthenope"incrementa le borse di studio agli studenti - codice > fiscale *80018240632* > > _http://www.uniparthenope.it/index.php/5xmille_ > > _http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille_ > > > Questa informativa è inserita in automatico dal sistema al fine > esclusivo della realizzazione dei fini istituzionali dell'ente. > > > > > ******************************************************************************************************* > > IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO > > Il 5 per mille all'Università degli Studi di Napoli > "Parthenope"incrementa le borse di studio agli studenti - codice > fiscale *80018240632* > > _http://www.uniparthenope.it/index.php/5xmille_ > > _http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille_ > > > Questa informativa è inserita in automatico dal sistema al fine > esclusivo della realizzazione dei fini istituzionali dell'ente. > > > --------------040708030002030600080801 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Salvatore

Dear all,

 

A new version of the Internet Draft on Flow Selection Techniques has been submitted. It contains the following changes:

-          A new section illustrating the difference between Intermediate Flow Selection Process and Intermediate Selection Process has been added,

-          The sentence "In order to be compliant with this document, at least the Property  Match Filtering MUST be implemented." has been removed in Section 1,

-          “MUST” has been replaced with “SHOULD” in Section 5.1,

Actually, the feedback was:
In Section 1:

  "In order to be compliant with this document, at least the Property
   Match Filtering MUST be implemented."

The above text is repeated in Section 5.1.  I suggest removing this sentence as it does not seem related to scope.

My reading of the "MUST" is that it is being used for compliance instead of the reasons described in RFC 2119.  I suggest reviewing the usage of RFC 2119 key words in Section 5.1.

So the solution is not to change MUST to SHOULD.
The question is whether "MUST" versus "must" must be used.
I understand the concern. For compliance reason with the PSAMP RFC 5475 (which is closely related) ...
7.  Parameters for the Description of Selection Techniques
   This section gives an overview of different alternative selection
   schemes and their required parameters.  In order to be compliant with
   PSAMP, at least one of proposed schemes MUST be implemented.
... I would keep the initial "MUST" from the previous draft version.

-          “The flowSelectorAlgorithm registry is maintained by IANA." has been replaced with “IANA is requested to create the flowSelectorAlgorithm registry.”

-          The sentence "The registry can be updated when specifications of the new  technique(s) and any new Information Elements are provided." has been removed since it did not clarify how the registry will be managed.

-           Section 6.1.1 “Property Match Filtering” has been changed by adding some text on how Property Match Filtering can be  used by an Intermediate Flow Selection Process in the Metering Process, in the  Exporting Process and within an IPFIX Mediator.

When publishing a new version, please correct this editorial issue.

 " ... and Flow duration. in
   the An example is the selection of the largest ..."

 

Best regards,

 

Salvatore

 

Da: Benoit Claise [mailto:bclaise@cisco.com]
Inviato: lunedì 8 aprile 2013 15:21
A: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org
Cc: ipfix-chairs@tools.ietf.org
Oggetto: Fwd: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

 

Dear authors,

The IETF last call has finished.
Can you please update your draft based on the feedback received.
Then I will progress it.

Regards, Benoit



-------- Original Message --------

Subject:

Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

Date:

Mon, 01 Apr 2013 00:28:46 -0700

From:

DraftTracker Mail System <iesg-secretary@ietf.org>

To:

iesg@ietf.org, ipfix-chairs@tools.ietf.org, draft-ietf-ipfix-flow-selection-tech@tools.ietf.org

CC:

iesg-secretary@ietf.org

 

Please DO NOT reply to this email.
 
I-D: <draft-ietf-ipfix-flow-selection-tech-14.txt>
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/
 
IETF Last Call has ended, and the state has been changed to
Waiting for AD Go-Ahead.
 
 
 

 

 

Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2013.0.3272 / Database dei virus: 3162/6231 - Data di rilascio: 07/04/2013


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

IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO

 

Il 5 per mille all'Università degli Studi di Napoli "Parthenope"incrementa le borse di studio agli studenti - codice fiscale 80018240632

http://www.uniparthenope.it/index.php/5xmille 

 

http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille

 
Questa informativa è inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente.




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

IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO

 

Il 5 per mille all'Università degli Studi di Napoli "Parthenope"incrementa le borse di studio agli studenti - codice fiscale 80018240632

http://www.uniparthenope.it/index.php/5xmille 

 

http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille

 
Questa informativa è inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente.




--------------040708030002030600080801-- From bclaise@cisco.com Mon Apr 15 02:47:52 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C1321F86C5 for ; Mon, 15 Apr 2013 02:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5N4-rQvcbmo for ; Mon, 15 Apr 2013 02:47:52 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8D521F86C4 for ; Mon, 15 Apr 2013 02:47:51 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3F9lp9M017188; Mon, 15 Apr 2013 11:47:51 +0200 (CEST) Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3F9lFsO025315; Mon, 15 Apr 2013 11:47:20 +0200 (CEST) Message-ID: <516BCCA3.7040102@cisco.com> Date: Mon, 15 Apr 2013 11:47:15 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Rahul Patel (rahulp)" References: <51497242.80407@cisco.com> In-Reply-To: <51497242.80407@cisco.com> Content-Type: multipart/alternative; boundary="------------040308020102010509060105" Cc: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org, "ipfix@ietf.org" Subject: Re: [IPFIX] Feedback: regarding draft-ietf-ipfix-mediation-protocol X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 09:47:53 -0000 This is a multi-part message in MIME format. --------------040308020102010509060105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Rahul, Addressing a specific point below. > Hi Rahul, > > Thanks for your review. > See in line. >> >> >> Few comments. >> >> 1. Page 8: >> 1. The difference between "Intermediate Selection Process" and >> "Intermediate Flow Selection Process" is not clear. Is the >> first one selecting record purely on matching content (value >> of the fields) in the record and the second one selecting on >> matching attributes of the fields that are not part of the >> record in *addition* to matching content in the record? An >> example would help here. >> > Granted, this is difficult to understand from the definitions only. > There is some history behind these two separate definitions. Anyway, > you get it right from your message above. > I was thinking to add to a section 2.1 "Differences between > Intermediate Selection Process and Intermediate Flow Selection > Process" in the draft-ietf-ipfix-mediation-protocol draft. However, > thinking about it some more, this section should really be done in > draft-ietf-ipfix-flow-selection-tech-14, to avoid some more confusion. > There is already section 3. "Difference between Intermediate Flow > Selection Process and Packet Selection". Some more text should be > added on the difference between Intermediate Selection Process and > Intermediate Flow Selection Process > > When created, draft-ietf-ipfix-mediation-protocol will refer to that > new section. The new section has been added. Please refer to http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-tech-15#section-4, and tell us if this is clear If it's easier, have a look at the diffs. Regards, Benoit --------------040308020102010509060105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Rahul,

Addressing a specific point below.
Hi Rahul,

Thanks for your review.
See in line.


Few comments.

  1. Page 8: 
    1. The difference between "Intermediate Selection Process" and "Intermediate Flow Selection Process" is not clear. Is the first one selecting record purely on matching content (value of the fields) in the record and the second one selecting on matching attributes of the fields that are not part of the record in *addition* to matching content in the record? An example would help here.
Granted, this is difficult to understand from the definitions only. There is some history behind these two separate definitions. Anyway, you get it right from your message above.
I was thinking to add to a section 2.1 "Differences between Intermediate Selection Process and Intermediate Flow Selection Process" in the draft-ietf-ipfix-mediation-protocol draft. However, thinking about it some more, this section should really be done in draft-ietf-ipfix-flow-selection-tech-14, to avoid some more confusion.
There is already section 3. "Difference between Intermediate Flow Selection Process and Packet Selection". Some more text should be added on the difference between Intermediate Selection Process and Intermediate Flow Selection Process

When created, draft-ietf-ipfix-mediation-protocol will refer to that new section.
The new section has been added.
Please refer to http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-tech-15#section-4, and tell us if this is clear
If it's easier, have a look at the diffs.

Regards, Benoit

--------------040308020102010509060105-- From bclaise@cisco.com Mon Apr 15 03:22:07 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF8F21F9318; Mon, 15 Apr 2013 03:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKl4HjpG7DTE; Mon, 15 Apr 2013 03:22:06 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB5D21F9305; Mon, 15 Apr 2013 03:22:06 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3FALmIR021118; Mon, 15 Apr 2013 12:21:48 +0200 (CEST) Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3FAL01o003398; Mon, 15 Apr 2013 12:21:16 +0200 (CEST) Message-ID: <516BD48C.9070204@cisco.com> Date: Mon, 15 Apr 2013 12:21:00 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: S Moonesamy References: <20130401072846.32360.9502.idtracker@ietfa.amsl.com> <5162C44B.5030904@cisco.com> <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it> <6.2.5.6.2.20130409084702.0c6104b8@elandnews.com> <001501ce35be$68c93c00$3a5bb400$@dantonio@uniparthenope.it> <6.2.5.6.2.20130410010433.0ca8b920@elandnews.com> In-Reply-To: <6.2.5.6.2.20130410010433.0ca8b920@elandnews.com> Content-Type: multipart/alternative; boundary="------------010705090806020107060306" Cc: apps-discuss@ietf.org, iesg@ietf.org, ipfix@ietf.org, draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org Subject: Re: [IPFIX] Last Call Expired: (APPSDIR review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 10:22:07 -0000 This is a multi-part message in MIME format. --------------010705090806020107060306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Salvatore, document shepherd, > Hi Salvatore, > At 00:38 10-04-2013, Salvatore D'Antonio wrote: >> I did not adequately addressed your comment because I thought that the >> guidelines specified in RFC 5226 were sufficient to deal with the issues >> concerning the management of the sub-registry. > > Ok. > >> I would greatly appreciate if you could provide me with the reference >> to a >> Draft where documentation and criteria for managing assignments are >> specified so that I may use such Draft as an example. > > Section 4.1 of RFC 5226 points to Sections 6 and 7.2 in RFC 3748 as an > example about Expert Review. Section 7.1 of RFC 5102 is another > example. I suggest discussing the proposed change with the document > shepherd or the Area Director to see whether it is appropriate. A similar example is http://tools.ietf.org/html/rfc5476#section-8.2, which refers to http://tools.ietf.org/html/rfc5477#section-8.2.1 Combining this text with your IANA considerations, this should be... Document shepherd and authors, please double-check, it's easy to make a mistake. 9.1.1 . flowSelectorAlgorithm Description: This Information Element identifies the Intermediate Flow Selection Process technique (e.g., Filtering, Sampling) that is applied by the Intermediate Flow Selection Process. Most of these techniques have parameters. Its configuration parameter(s) MUST be clearly specified. Further Information Elements are needed to fully specify packet selection with these methods and all their parameters. Further method identifiers may be added to the list below. It might be necessary to define new Information Elements to specify their parameters. The flowSelectorAlgorithm registry is maintained by IANA. New assignments for the registry will be administered by IANA, on a First Come First Served basis [RFC5226 ], subject to Expert Review [RFC5226 ]. The registry can be updated when specifications of the new method(s) and any new Information Elements are provided. The group of experts must double check the flowSelectorAlgorithm definitions and Information Elements with already defined flowSelectorAlgorithm and Information Elements for completeness, accuracy, and redundancy. Those experts will initially be drawn from the Working Group Chairs and document editors of the IPFIX and PSAMP Working Groups. The following Intermediate Flow Selection Process Techniques identifiers are defined here: +----+------------------------+--------------------------+ | ID | Technique | Parameters | +----+------------------------+--------------------------+ | 1 | Systematic count-based | flowSamplingInterval | | | Sampling | flowSamplingSpacing | +----+------------------------+--------------------------+ | 2 | Systematic time-based | flowSamplingTimeInterval | | | Sampling | flowSamplingTimeSpacing | +----+------------------------+--------------------------+ | 3 | Random n-out-of-N | samplingSize | | | Sampling | samplingPopulation | +----+------------------------+--------------------------+ | 4 | Uniform probabilistic | samplingProbability | | | Sampling | | +----+------------------------+--------------------------+ | 5 | Property Match | Information Element | | | Filtering | Value Range | +----+------------------------+--------------------------+ | Hash-based Filtering | hashInitialiserValue | +----+------------------------+ hashFlowDomain | | 6 | using BOB | hashSelectedRangeMin | +----+------------------------+ hashSelectedRangeMax | | 7 | using IPSX | hashOutputRangeMin | +----+------------------------+ hashOutputRangeMax | | 8 | using CRC | | +----+------------------------+--------------------------+ | 9 | Flow-state Dependent | No agreed Parameters | | | Intermediate Flow | | | | Selection Process | | +----+------------------------+--------------------------+ Intermediate Flow Selection Process Techniques Abstract Data Type: unsigned16 ElementId: TBD1 Data Type Semantics: identifier Status: Current Regards, Benoit. --------------010705090806020107060306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Salvatore, document shepherd,
Hi Salvatore,
At 00:38 10-04-2013, Salvatore D'Antonio wrote:
I did not adequately addressed your comment because I thought that the
guidelines specified in RFC 5226 were sufficient to deal with the issues
concerning the management of the sub-registry.

Ok.

I would greatly appreciate if you could provide me with the reference to a
Draft where documentation and criteria for managing assignments are
specified so that I may use such Draft as an example.

Section 4.1 of RFC 5226 points to Sections 6 and 7.2 in RFC 3748 as an example about Expert Review.  Section 7.1 of RFC 5102 is another example.  I suggest discussing the proposed change with the document shepherd or the Area Director to see whether it is appropriate.
A similar example is http://tools.ietf.org/html/rfc5476#section-8.2, which refers to http://tools.ietf.org/html/rfc5477#section-8.2.1

Combining this text with your IANA considerations, this should be...
Document shepherd and authors, please double-check, it's easy to make a mistake.

9.1.1.  flowSelectorAlgorithm

   Description:

      This Information Element identifies the Intermediate Flow
      Selection Process technique (e.g., Filtering, Sampling) that is
      applied by the Intermediate Flow Selection Process.  

      Most of these techniques have parameters.  Its configuration 
      parameter(s) MUST be clearly specified.  Further Information
      Elements are needed to fully specify packet selection with these
      methods and all their parameters. 

      Further method identifiers may be added to the list below.  It
      might be necessary to define new Information Elements to specify
      their parameters.

      The flowSelectorAlgorithm registry is maintained by IANA.  New
      assignments for the registry will be administered by IANA, on a 
      First Come First Served basis [RFC5226], subject to Expert Review 
      [RFC5226].

      The registry can be updated when specifications of the new
      method(s) and any new Information Elements are provided.

      The group of experts must double check the flowSelectorAlgorithm 
      definitions and Information Elements with already defined
      flowSelectorAlgorithm and Information Elements for completeness,
      accuracy, and redundancy.  Those experts will initially be drawn
      from the Working Group Chairs and document editors of the IPFIX
      and PSAMP Working Groups.

      The following Intermediate Flow Selection Process Techniques
      identifiers are defined here:
   

          +----+------------------------+--------------------------+
          | ID |        Technique       |      Parameters          |
          +----+------------------------+--------------------------+
          | 1  | Systematic count-based | flowSamplingInterval     |
          |    | Sampling               | flowSamplingSpacing      |
          +----+------------------------+--------------------------+
          | 2  | Systematic time-based  | flowSamplingTimeInterval |
          |    | Sampling               | flowSamplingTimeSpacing  |
          +----+------------------------+--------------------------+
          | 3  | Random n-out-of-N      | samplingSize             |
          |    | Sampling               | samplingPopulation       |
          +----+------------------------+--------------------------+
          | 4  | Uniform probabilistic  | samplingProbability      |
          |    | Sampling               |                          |
          +----+------------------------+--------------------------+
          | 5  | Property Match         | Information Element      |
          |    | Filtering              | Value Range              |
          +----+------------------------+--------------------------+
          |   Hash-based Filtering      | hashInitialiserValue     |
          +----+------------------------+ hashFlowDomain           |
          | 6  | using BOB              | hashSelectedRangeMin     |
          +----+------------------------+ hashSelectedRangeMax     |
          | 7  | using IPSX             | hashOutputRangeMin       |
          +----+------------------------+ hashOutputRangeMax       |
          | 8  | using CRC              |                          |
          +----+------------------------+--------------------------+
          | 9  | Flow-state Dependent   | No agreed Parameters     |
          |    | Intermediate Flow      |                          |
          |    | Selection Process      |                          |
          +----+------------------------+--------------------------+

              Intermediate Flow Selection Process Techniques

   Abstract Data Type: unsigned16

   ElementId: TBD1

   Data Type Semantics: identifier

   Status: Current

Regards, Benoit.

--------------010705090806020107060306-- From rahulp@cisco.com Mon Apr 15 10:08:56 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4139321F9628 for ; Mon, 15 Apr 2013 10:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wPPMvEn9HZT for ; Mon, 15 Apr 2013 10:08:55 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id BAC7C21F93B4 for ; Mon, 15 Apr 2013 10:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7380; q=dns/txt; s=iport; t=1366045734; x=1367255334; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=3Ebovo8W7Q9KgZ8S5G2j/E8ZIJ3lcJUXGw55QxA5fjE=; b=Ya8OdHYYGkI+9X7efvL5ikiD1NzMkAOUE/f0XtZPqW9gGvslE4aT+ESK ueBZ4s48V0OgrF2u3LndIvHOQisL8DveDz00gSIxeyuO2TWVLplBw35mg IW21FiHYr+3T8jV+6zszbKfuflLChY2JO5l/XpU1D1lX+2HdTWGLOFnrW Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFABszbFGtJV2Z/2dsb2JhbABQgkJENsEEgQcWdIIfAQEBBHkSAQgRAwECCx05FAkIAgQOBQiIDAy7cI5mIBEHBoJaYQOYJo9wgwuCKA X-IronPort-AV: E=Sophos;i="4.87,476,1363132800"; d="scan'208,217";a="198949234" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 15 Apr 2013 17:08:54 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3FH8sQw028256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Apr 2013 17:08:54 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.115]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 12:08:53 -0500 From: "Rahul Patel (rahulp)" To: "Benoit Claise (bclaise)" Thread-Topic: [IPFIX] Feedback: regarding draft-ietf-ipfix-mediation-protocol Thread-Index: AQHOGcq3m3VkIH+yRkGa/Azkao+B1piuqPAAgCjzt4CAABbMAA== Date: Mon, 15 Apr 2013 17:08:53 +0000 Message-ID: In-Reply-To: <516BCCA3.7040102@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.154.209.184] Content-Type: multipart/alternative; boundary="_000_A1EE24E3D6D8B14A92CCA1AFB88718B21848159Exmbrcdx05ciscoc_" MIME-Version: 1.0 Cc: "draft-ietf-ipfix-flow-selection-tech@tools.ietf.org" , "ipfix@ietf.org" Subject: Re: [IPFIX] Feedback: regarding draft-ietf-ipfix-mediation-protocol X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:08:56 -0000 --_000_A1EE24E3D6D8B14A92CCA1AFB88718B21848159Exmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Benoit, It is very clear, looks good. -Rahul From: "Benoit Claise (bclaise)" > Date: Monday, April 15, 2013 1:47 AM To: Cisco Employee > Cc: "ipfix@ietf.org" >, "draft-ietf-ipfix-flow-selection-tech@tools.ietf.org" > Subject: Re: [IPFIX] Feedback: regarding draft-ietf-ipfix-mediation-protoco= l Hi Rahul, Addressing a specific point below. Hi Rahul, Thanks for your review. See in line. Few comments. 1. Page 8: * The difference between "Intermediate Selection Process" and "Inter= mediate Flow Selection Process" is not clear. Is the first one selecting re= cord purely on matching content (value of the fields) in the record and the= second one selecting on matching attributes of the fields that are not par= t of the record in *addition* to matching content in the record? An example= would help here. Granted, this is difficult to understand from the definitions only. There i= s some history behind these two separate definitions. Anyway, you get it ri= ght from your message above. I was thinking to add to a section 2.1 "Differences between Intermediate Se= lection Process and Intermediate Flow Selection Process" in the draft-ietf-= ipfix-mediation-protocol draft. However, thinking about it some more, this = section should really be done in draft-ietf-ipfix-flow-selection-tech-14, t= o avoid some more confusion. There is already section 3. "Difference between Intermediate Flow Selection= Process and Packet Selection". Some more text should be added on the diffe= rence between Intermediate Selection Process and Intermediate Flow Selectio= n Process When created, draft-ietf-ipfix-mediation-protocol will refer to that new se= ction. The new section has been added. Please refer to http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-= tech-15#section-4, and tell us if this is clear If it's easier, have a look at the diffs. Regards, Benoit --_000_A1EE24E3D6D8B14A92CCA1AFB88718B21848159Exmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <371C7CD9F0B8974F8452FF182C7AE000@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Benoit,

It is very clear, looks good.

-Rahul

From: "Benoit Claise (bclaise)= " <bclaise@cisco.com> Date: Monday, April 15, 2013 1:47 A= M
To: Cisco Employee <rahulp@cisco.com>
Cc: "ipfix@ietf.org" <ipf= ix@ietf.org>, "draft-ietf-ipfix-flow-selection-tech@tools.ietf.org<= /a>" <draft-ietf-ipfix-flow-selection-tech@tools.ietf.org>
Subject: Re: [IPFIX] Feedback: rega= rding draft-ietf-ipfix-mediation-protocol

Hi Rahul,

Addressing a specific point below.
Hi Rahul,

Thanks for your review.
See in line.


Few comments.

  1. Page 8: 
    1. The difference between "Intermediate Selection Process" and &= quot;Intermediate Flow Selection Process" is not clear. Is the first o= ne selecting record purely on matching content (value of the fields) in the= record and the second one selecting on matching attributes of the fields that are not part of the record in *addition* to matching co= ntent in the record? An example would help here.
Granted, this is difficult to understand from the definitions only. There i= s some history behind these two separate definitions. Anyway, you get it ri= ght from your message above.
I was thinking to add to a section 2.1 "Differences between Intermedia= te Selection Process and Intermediate Flow Selection Process" in the d= raft-ietf-ipfix-mediation-protocol draft. However, thinking about it some m= ore, this section should really be done in draft-ietf-ipfix-flow-selection-tech-14, to avoid some more confusion.
There is already section 3. "Difference between Intermediate Flow Sele= ction Process and Packet Selection". Some more text should be added on= the difference between Intermediate Selection Process and Intermediate Flo= w Selection Process

When created, draft-ietf-ipfix-mediation-protocol will refer to that new se= ction.
The new section has been added.
Please refer to http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-tech-15#section-= 4, and tell us if this is clear
If it's easier, have a look at the diffs.

Regards, Benoit

 --_000_A1EE24E3D6D8B14A92CCA1AFB88718B21848159Exmbrcdx05ciscoc_-- From iesg-secretary@ietf.org Wed Apr 17 09:36:14 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974DC21F8D46; Wed, 17 Apr 2013 09:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3G0XxR-nqlXd; Wed, 17 Apr 2013 09:36:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 303CA21F8AE6; Wed, 17 Apr 2013 09:36:14 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130417163614.26677.13103.idtracker@ietfa.amsl.com> Date: Wed, 17 Apr 2013 09:36:14 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] Last Call: (Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 16:36:14 -0000 The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-05-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1927/ From iesg-secretary@ietf.org Wed Apr 17 09:36:14 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB71A21F8D46 for ; Wed, 17 Apr 2013 09:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+XtteEegKjo; Wed, 17 Apr 2013 09:36:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 460BD21F8C9B; Wed, 17 Apr 2013 09:36:14 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 X-IETF-Draft-string: draft-ietf-ipfix-protocol-rfc5101bis X-IETF-Draft-revision: 06 Message-ID: <20130417163614.26677.74492.idtracker@ietfa.amsl.com> Date: Wed, 17 Apr 2013 09:36:14 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] Last Call: (Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 16:36:14 -0000 The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-05-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1927/ From internet-drafts@ietf.org Sat Apr 20 16:41:38 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6839121F91C9; Sat, 20 Apr 2013 16:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98RyRL02aAe7; Sat, 20 Apr 2013 16:41:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CEB21F888F; Sat, 20 Apr 2013 16:41:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p3 Message-ID: <20130420234137.19662.72472.idtracker@ietfa.amsl.com> Date: Sat, 20 Apr 2013 16:41:37 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-flow-selection-tech-16.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 23:41:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Group = of the IETF. Title : Flow Selection Techniques Author(s) : Salvatore D'Antonio Tanja Zseby Christian Henke Lorenzo Peluso Filename : draft-ietf-ipfix-flow-selection-tech-16.txt Pages : 32 Date : 2013-04-20 Abstract: Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IPFIX Exporter, Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-tech-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-flow-selection-tech-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From salvatore.dantonio@uniparthenope.it Sat Apr 20 17:06:26 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DB221F8A00; Sat, 20 Apr 2013 17:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.035 X-Spam-Level: **** X-Spam-Status: No, score=4.035 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, MSGID_MULTIPLE_AT=1.449, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUw3hRp9HRmG; Sat, 20 Apr 2013 17:06:24 -0700 (PDT) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by ietfa.amsl.com (Postfix) with ESMTP id B657E21F888F; Sat, 20 Apr 2013 17:06:23 -0700 (PDT) Received: from mail2.uniparthenope.it (unknown [10.1.2.108]) by mail.uniparthenope.it (Postfix) with SMTP id D0D4F42536; Sun, 21 Apr 2013 00:06:22 +0000 (UTC) Received: from (unknown [192.168.241.108]) by mail2.uniparthenope.it with smtp id 1da8_4bd40ed6_aa17_11e2_9101_001372515a5c; Sun, 21 Apr 2013 02:06:21 +0200 Received: from spamk.uniparthenope.it (localhost [127.0.0.1]) by spamk.uniparthenope.it (Postfix) with ESMTP id 781BFC432C; Sun, 21 Apr 2013 02:06:20 +0200 (CEST) Received: by spamk.uniparthenope.it (Postfix, from userid 500) id 5D40EC4351; Sun, 21 Apr 2013 02:06:20 +0200 (CEST) Received: from mail.uniparthenope.it (unknown [192.168.241.109]) by spamk.uniparthenope.it (Postfix) with ESMTP id B34CAC4377; Sun, 21 Apr 2013 02:06:13 +0200 (CEST) Received: by mail.uniparthenope.it (Postfix, from userid 108) id 9DFC0421AD; Sun, 21 Apr 2013 02:06:13 +0200 (CEST) Received: from saldantoPC (unknown [2.237.123.176]) (Authenticated sender: salvatore.dantonio@uniparthenope.it) by mail.uniparthenope.it (Postfix) with ESMTPA id ABE80421AD; Sun, 21 Apr 2013 02:06:11 +0200 (CEST) From: "Salvatore D'Antonio" To: "'Benoit Claise'" References: <20130401072846.32360.9502.idtracker@ietfa.amsl.com> <5162C44B.5030904@cisco.com> <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it> <516BCB97.9040404@cisco.com> In-Reply-To: <516BCB97.9040404@cisco.com> Date: Sun, 21 Apr 2013 02:06:14 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac45veJiRHrdfH9cTm69S7sEnZNliAEY1GBQ Content-Language: it Message-ID: <001001ce3e24$0a931840$1fb948c0$@dantonio@uniparthenope.it> Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01CE3E34.CE1BE840" X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.42/RELEASE, bases: 20130420 #9915320, check: 20130421 clean Cc: 'IETF discussion list' , draft-ietf-ipfix-flow-selection-tech@tools.ietf.org, apps-discuss@ietf.org, 'General Area Review Team' , 'S Moonesamy' , ipfix-chairs@tools.ietf.org, ipfix@ietf.org, iesg@ietf.org, "'Joel M. Halpern'" , "'A. Jean Mahoney'" Subject: [IPFIX] R: R: Last Call Expired: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2013 00:06:26 -0000 Messaggio multipart in formato MIME. ------=_NextPart_000_0011_01CE3E34.CE1BE840 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dear Benoit, all =20 I submitted v16 of the Internet Draft. =20 I modified section 9.1.1 on the maintenance of the flowSelectorAlgorithm = registry and fixed the editorial issue in section 6.1.1 =20 I have also used MUST in section 6.1 =20 Best regards, =20 Salvatore =20 =20 Da: Benoit Claise [mailto:bclaise@cisco.com]=20 Inviato: luned=C3=AC 15 aprile 2013 11:43 A: Salvatore D'Antonio Cc: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org; = ipfix-chairs@tools.ietf.org; 'S Moonesamy'; apps-discuss@ietf.org; = iesg@ietf.org; 'Joel M. Halpern'; 'A. Jean Mahoney'; 'General Area = Review Team'; 'IETF discussion list'; rahulp@cisco.com; ipfix@ietf.org Oggetto: Re: R: Last Call Expired: = =20 Salvatore Dear all, =20 A new version of the Internet Draft on Flow Selection Techniques has = been submitted. It contains the following changes: - A new section illustrating the difference between = Intermediate Flow Selection Process and Intermediate Selection Process = has been added, - The sentence "In order to be compliant with this document, at = least the Property Match Filtering MUST be implemented." has been = removed in Section 1, - =E2=80=9CMUST=E2=80=9D has been replaced with = =E2=80=9CSHOULD=E2=80=9D in Section 5.1, Actually, the feedback was: In Section 1:=20 "In order to be compliant with this document, at least the Property=20 Match Filtering MUST be implemented."=20 The above text is repeated in Section 5.1. I suggest removing this = sentence as it does not seem related to scope.=20 My reading of the "MUST" is that it is being used for compliance instead = of the reasons described in RFC 2119. I suggest reviewing the usage of = RFC 2119 key words in Section 5.1.=20 So the solution is not to change MUST to SHOULD. The question is whether "MUST" versus "must" must be used. I understand the concern. For compliance reason with the PSAMP RFC 5475 = (which is closely related) ... 7. Parameters for the = Description of Selection Techniques This section gives an overview of different alternative selection schemes and their required parameters. In order to be compliant with PSAMP, at least one of proposed schemes MUST be implemented. =20 ... I would keep the initial "MUST" from the previous draft version.=20 - =E2=80=9CThe flowSelectorAlgorithm registry is maintained by = IANA." has been replaced with =E2=80=9CIANA is requested to create the = flowSelectorAlgorithm registry.=E2=80=9D - The sentence "The registry can be updated when specifications = of the new technique(s) and any new Information Elements are provided." = has been removed since it did not clarify how the registry will be = managed. - Section 6.1.1 =E2=80=9CProperty Match Filtering=E2=80=9D has = been changed by adding some text on how Property Match Filtering can be = used by an Intermediate Flow Selection Process in the Metering Process, = in the Exporting Process and within an IPFIX Mediator. When publishing a new version, please correct this editorial issue. " ... and Flow duration. in the An example is the selection of the largest ..." =20 Best regards, =20 Salvatore =20 Da: Benoit Claise [mailto:bclaise@cisco.com]=20 Inviato: luned=C3=AC 8 aprile 2013 15:21 A: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org Cc: ipfix-chairs@tools.ietf.org Oggetto: Fwd: Last Call Expired: = =20 Dear authors, The IETF last call has finished. Can you please update your draft based on the feedback received. Then I will progress it. Regards, Benoit -------- Original Message --------=20 Subject:=20 Last Call Expired: Date:=20 Mon, 01 Apr 2013 00:28:46 -0700 From:=20 DraftTracker Mail System = To:=20 iesg@ietf.org, ipfix-chairs@tools.ietf.org, = draft-ietf-ipfix-flow-selection-tech@tools.ietf.org CC:=20 iesg-secretary@ietf.org =20 Please DO NOT reply to this email. =20 I-D: ID Tracker URL: = http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ =20 IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. =20 =20 =20 =20 =20 _____ =20 Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 2013.0.3272 / Database dei virus: 3162/6231 - Data di = rilascio: 07/04/2013 *************************************************************************= ****************************** IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO =20 Il 5 per mille all'Universit=C3=A0 degli Studi di Napoli = "Parthenope"incrementa le borse di studio agli studenti - codice fiscale = 80018240632=20 = http://www.uniparthenope.it/index.php/5xmille=20 =20 = = http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-pa= rthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-de= l-5-per-mille =20 Questa informativa =C3=A8 inserita in automatico dal sistema al fine = esclusivo della realizzazione dei fini istituzionali dell'ente. =20 *************************************************************************= ****************************** IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO =20 Il 5 per mille all'Universit=C3=A0 degli Studi di Napoli = "Parthenope"incrementa le borse di studio agli studenti - codice fiscale = 80018240632=20 = http://www.uniparthenope.it/index.php/5xmille=20 =20 = = http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-pa= rthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-de= l-5-per-mille =20 Questa informativa =C3=A8 inserita in automatico dal sistema al fine = esclusivo della realizzazione dei fini istituzionali dell'ente. =20 =20 =20 ******************************************************************************=09=0A IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO=0A =0A Il 5 per mille all'Universita' degli Studi di Napoli "Parthenope" incrementa le borse di studio agli studenti - codice fiscale 80018240632=0A http://www.uniparthenope.it/index.php/5xmille =0A =0A http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille=0A =0A Questa informativa e' inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente.=0A ------=_NextPart_000_0011_01CE3E34.CE1BE840 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Dear Benoit, all

 

I submitted v16 of the Internet = Draft.

 

I modified section 9.1.1 on the maintenance of the = flowSelectorAlgorithm registry and fixed the editorial issue in section = =C2=A06.1.1

 

I have also used MUST in section = 6.1

 

Best regards,

 

Salvatore

 

 

Da: Benoit Claise [mailto:bclaise@cisco.com]
Inviato: luned=C3=AC 15 aprile 2013 11:43
A: Salvatore D'Antonio
Cc: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org; ipfix-chairs@tools.ietf.org; 'S Moonesamy'; apps-discuss@ietf.org; iesg@ietf.org; 'Joel M. Halpern'; 'A. Jean Mahoney'; 'General Area = Review Team'; 'IETF discussion list'; rahulp@cisco.com; ipfix@ietf.org
Oggetto: Re: R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

=

 

Salvatore

Dear all,

 

A new version of the Internet Draft on Flow Selection = Techniques has been submitted. It contains the following = changes:

-          A new section illustrating the difference between = Intermediate Flow Selection Process and Intermediate Selection Process has been = added,

-          The sentence "In order to be compliant with this = document, at least the Property  Match Filtering MUST be implemented." = has been removed in Section 1,

-          =E2=80=9CMUST=E2=80=9D has been replaced with = =E2=80=9CSHOULD=E2=80=9D in Section 5.1,

Actually, the feedback was:

In Section 1:

  "In order to be compliant with this document, at least the = Property
   Match Filtering MUST be implemented."

The above text is repeated in Section 5.1.  I suggest removing this = sentence as it does not seem related to scope.

My reading of the "MUST" is that it is being used for = compliance instead of the reasons described in RFC 2119.  I suggest reviewing = the usage of RFC 2119 key words in Section 5.1.

So the solution is not to change MUST to = SHOULD.
The question is whether "MUST" versus "must" must be = used.
I understand the concern. For compliance reason with the PSAMP RFC 5475 = (which is closely related) ...

7.=C2=A0 Parameters for the Description of Selection = Techniques

=C2=A0=C2=A0 This section gives an overview of different =
alternative selection
=C2=A0=C2=A0 schemes and =
their required parameters.=C2=A0 In order to be compliant =
with
=C2=A0=C2=A0 PSAMP, at least one of proposed =
schemes MUST be =
implemented.
 

... I would keep the initial "MUST" from = the previous draft version.

-          =E2=80=9CThe flowSelectorAlgorithm registry is maintained = by IANA." has been replaced with =E2=80=9CIANA is requested to create the = flowSelectorAlgorithm registry.=E2=80=9D

-          The sentence "The registry can be updated when specifications of the new  technique(s) and any new Information = Elements are provided." has been removed since it did not clarify how the = registry will be managed.

-           Section 6.1.1 =E2=80=9CProperty Match = Filtering=E2=80=9D has been changed by adding some text on how Property Match Filtering can be  used by = an Intermediate Flow Selection Process in the Metering Process, in the  Exporting Process and within an IPFIX = Mediator.

When publishing a = new version, please correct this editorial issue.

=C2=A0" ... and Flow duration. =
in
=C2=A0=C2=A0 the An example is the selection of =
the largest ..."



 

Best regards,

 

Salvatore

 

 

Dear authors,

The IETF last call has finished.
Can you please update your draft based on the feedback received.
Then I will progress it.

Regards, Benoit

 

Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2013.0.3272 / Database dei virus: 3162/6231 - Data di = rilascio: 07/04/2013



******************************= *************************************************************************=

IL MERITO DEGLI = STUDENTI VIENE RICONOSCIUTO

 

Il 5 per mille = all'Universit=C3=A0 degli Studi di Napoli "Parthenope"incrementa le borse di studio agli studenti - codice fiscale 80018240632

http://www.uniparthenope.it/index.php/5xmille 

 

http://www.uniparthenope.it/in= dex.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di= -diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille<= /o:p>

 
Questa informativa =C3=A8 inserita in automatico dal sistema al fine = esclusivo della realizzazione dei fini istituzionali dell'ente.

 




******************************= *************************************************************************=

IL MERITO DEGLI = STUDENTI VIENE RICONOSCIUTO

 

Il 5 per mille = all'Universit=C3=A0 degli Studi di Napoli "Parthenope"incrementa le borse di studio agli studenti - codice fiscale 80018240632

http://www.uniparthenope.it/index.php/5xmille 

 

http://www.uniparthenope.it/in= dex.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di= -diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille<= /o:p>

 
Questa informativa =C3=A8 inserita in automatico dal sistema al fine = esclusivo della realizzazione dei fini istituzionali dell'ente.

 

 

 


= =0A =0A

=0A

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

=0A

IL=0A MERITO DEGLI STUDENTI VIENE RICONOSCIUTO

=0A

 

=0A

Il=0A 5 per mille all'Università degli Studi di Napoli "Parthenope"incrementa le borse di studio agli studenti=0A - codice fiscale 80018240632=0A =0A

=0A

http://www.uniparthenope.it/index.php/5xmille 

=0A

 

=0A

http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille

=0A

 
Questa=0A informativa è inserita in automatico dal sistema al fine esclusivo=0A della realizzazione dei fini istituzionali dell'ente.

=0A


=0A

=0A =0A =0A
=
= =0A =0A

=0A

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

=0A

IL=0A MERITO DEGLI STUDENTI VIENE RICONOSCIUTO

=0A

 

=0A

Il=0A 5 per mille all'Università degli Studi di Napoli "Parthenope"incrementa le borse di studio agli studenti=0A - codice fiscale 80018240632=0A =0A

=0A

http://www.uniparthenope.it/index.php/5xmille 

=0A

 

=0A

http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille

=0A

 
Questa=0A informativa è inserita in automatico dal sistema al fine esclusivo=0A della realizzazione dei fini istituzionali dell'ente.

=0A


=0A

=0A =0A =0A
= ------=_NextPart_000_0011_01CE3E34.CE1BE840-- From ramk@Brocade.com Wed Apr 24 08:13:29 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8F221F9413 for ; Wed, 24 Apr 2013 08:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr4iLir5mqGm for ; Wed, 24 Apr 2013 08:13:27 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id C94FF21F89DB for ; Wed, 24 Apr 2013 08:13:23 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r3OFCxdV023700; Wed, 24 Apr 2013 08:13:21 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1bx1898frs-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 24 Apr 2013 08:13:21 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 24 Apr 2013 08:13:19 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::8c73:93bf:41b4:1443]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 24 Apr 2013 08:13:17 -0700 From: ramki Krishnan To: "Salvatore D'Antonio" , "tanja@caida.org" , "lorenzo.peluso@unina.it" Date: Wed, 24 Apr 2013 08:13:11 -0700 Thread-Topic: [IPFIX] R: R: Last Call Expired: Thread-Index: Ac45veJiRHrdfH9cTm69S7sEnZNliAEY1GBQALVtivA= Message-ID: References: <20130401072846.32360.9502.idtracker@ietfa.amsl.com> <5162C44B.5030904@cisco.com> <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it> <516BCB97.9040404@cisco.com> <001001ce3e24$0a931840$1fb948c0$@dantonio@uniparthenope.it> In-Reply-To: <001001ce3e24$0a931840$1fb948c0$@dantonio@uniparthenope.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2BFD824ED8FHQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-24_06:2013-04-24, 2013-04-24, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1304240122 Cc: IPFIX Working Group Subject: Re: [IPFIX] R: R: Last Call Expired: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 15:13:29 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2BFD824ED8FHQ1EXCH01corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBBdXRob3JzLA0KDQpJIGhhZCBhIGdvb2QgZGlzY3Vzc2lvbiB3aXRoIEp1ZXJnZW4gb24g dGhpcyB0b3BpYy4gSGUgc3VnZ2VzdGVkIHRoYXQgSSByZWFjaCBvdXQgdG8geW91IGZvbGtzLg0K DQpTdWdnZXN0ZWQgY2hhbmdlcyB0byBTZWN0aW9uIDYuNA0KQW4gZXhhbXBsZSBpcyB0aGUgICJT YW1wbGUgYW5kIEhvbGQiIGFsZ29yaXRobSBbRXNWYTAxXSwgb3Igc2ltaWxhciB0ZWNobmlxdWVz LCB0aGF0IHRyeSB0byBwcmVmZXIgbG9uZy1saXZlZCBsYXJnZSB2b2x1bWUgZmxvd3MgaW4gdGhl IHNlbGVjdGlvbi4gV2hlbiBhIHBhY2tldCBhcnJpdmVzLCB0aGVzZSBwYWNrZXQgc2VsZWN0aW9u IHRlY2huaXF1ZXMgYXJlIGFwcGxpZWQgb25seSBpZiBhIGZsb3cgcmVjb3JkIGZvciB0aGUgcGFj a2V0IGRvZXMgbm90IGV4aXN0LiBUaGVzZSBwYWNrZXQgc2VsZWN0aW9uIHRlY2huaXF1ZXMgY291 bGQgaGF2ZSBmYWxzZSBwb3NpdGl2ZXMgYnV0IG5vIGZhbHNlIG5lZ2F0aXZlczsgaS5lLiBmbG93 cyB3aGljaCBhcmUgbm90IGxvbmctbGl2ZWQgbGFyZ2UgZmxvd3MgbWF5IGJlIHNlbGVjdGVkIGFu ZCBsZWFybnQgaW4gdGhlIGZsb3cgY2FjaGUuIFRoZSBmbG93cyB3aGljaCBhcmUgbm90IGxvbmct bGl2ZWQgbGFyZ2UgZmxvd3MgYXJlIGxhdGVyIHB1cmdlZCBmcm9tIHRoZSBmbG93IGNhY2hlLg0K DQpTdWdnZXN0ZWQgY2hhbmdlcyB0byBTZWN0aW9uIDcuMg0KRm9yIHRlY2huaXF1ZXMgc2ltaWxh ciB0byDigJxTYW1wbGUgYW5kIEhvbGTigJ0sIHRoZSB0d28gcGFyYW1ldGVycyAtLSB0aGUgb2Jz ZXJ2YXRpb24gaW50ZXJ2YWwsIGFuZCB0aGUgbWluaW11bSBiYW5kd2lkdGggdGhyZXNob2xkIG92 ZXIgdGhhdCBvYnNlcnZhdGlvbiBpbnRlcnZhbCAtLSBzaG91bGQgYmUgcHJvZ3JhbW1hYmxlIGlu IGEgbmV0d29ya2luZyBkZXZpY2UgdG8gZmFjaWxpdGF0ZSBoYW5kbGluZyBvZiBkaWZmZXJlbnQg dXNlIGNhc2VzIGFuZCB0cmFmZmljIGNoYXJhY3RlcmlzdGljcy4NCg0KRnJvbSBhIGJhbmR3aWR0 aCBhbmQgdGltZSBkdXJhdGlvbiBwZXJzcGVjdGl2ZSwgaW4gb3JkZXIgdG8gaWRlbnRpZnkgbG9u Zy1saXZlZCBsYXJnZSBmbG93cywgd2UgZGVmaW5lIGFuIG9ic2VydmF0aW9uIGludGVydmFsIGFu ZCBvYnNlcnZlIHRoZSBiYW5kd2lkdGggb2YgdGhlIGZsb3cgb3ZlciB0aGF0IG9ic2VydmF0aW9u IGludGVydmFsLiBBIGZsb3cgdGhhdCBleGNlZWRzIGEgY2VydGFpbiBtaW5pbXVtIGJhbmR3aWR0 aCB0aHJlc2hvbGQgb3ZlciB0aGF0IG9ic2VydmF0aW9uIGludGVydmFsDQp3b3VsZCBiZSBjb25z aWRlcmVkIGEgbG9uZy1saXZlZCBsYXJnZSBmbG93Lg0KDQpGb3IgZXhhbXBsZSwgYSBmbG93IHdo aWNoIGlzIGF0IG9yIGFib3ZlIDEwIE1icHMgZm9yIGEgdGltZSBwZXJpb2Qgb2YgYXQgbGVhc3Qg MzAgc2Vjb25kcyBjb3VsZCBiZSBkZWNsYXJlZCBhIGxvbmctbGl2ZWQgbGFyZ2UgZmxvdy4NCg0K U3VnZ2VzdGVkIGNoYW5nZXMgdG8gU2VjdGlvbiA4IGFuZCBTZWN0aW9uIDkNClRoZSBwYXJhbWV0 ZXJzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDcuMi4NCg0KVGhlIHBhcmFtZXRlcnMgSSBkZXNjcmli ZWQgYWJvdmUgYXJlIGNhcHR1cmVkIGluIHNlY3Rpb24gMi4xLjIgb2YgdGhlIGRyYWZ0IGJlbG93 LiBPdGhlciBkZXRhaWxzIGFyZSBhbHNvIGNhcHR1cmVkIGluIHRoZSBkcmFmdCBiZWxvdy4NCmh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta3Jpc2huYW4taXBmaXgtZmxvdy1h d2FyZS1wYWNrZXQtc2FtcGxpbmcvP2luY2x1ZGVfdGV4dD0xDQoNClRoYW5rcywNClJhbSAoYWth IFJhbWtpKQ0KRnJvbTogaXBmaXgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmlwZml4LWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTYWx2YXRvcmUgRCdBbnRvbmlvDQpTZW50OiBTYXR1 cmRheSwgQXByaWwgMjAsIDIwMTMgNTowNiBQTQ0KVG86ICdCZW5vaXQgQ2xhaXNlJw0KQ2M6ICdJ RVRGIGRpc2N1c3Npb24gbGlzdCc7IGRyYWZ0LWlldGYtaXBmaXgtZmxvdy1zZWxlY3Rpb24tdGVj aEB0b29scy5pZXRmLm9yZzsgYXBwcy1kaXNjdXNzQGlldGYub3JnOyAnR2VuZXJhbCBBcmVhIFJl dmlldyBUZWFtJzsgJ1MgTW9vbmVzYW15JzsgaXBmaXgtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBp cGZpeEBpZXRmLm9yZzsgaWVzZ0BpZXRmLm9yZzsgJ0pvZWwgTS4gSGFscGVybic7ICdBLiBKZWFu IE1haG9uZXknDQpTdWJqZWN0OiBbSVBGSVhdIFI6IFI6IExhc3QgQ2FsbCBFeHBpcmVkOiA8ZHJh ZnQtaWV0Zi1pcGZpeC1mbG93LXNlbGVjdGlvbi10ZWNoLTE0LnR4dD4NCg0KRGVhciBCZW5vaXQs IGFsbA0KDQpJIHN1Ym1pdHRlZCB2MTYgb2YgdGhlIEludGVybmV0IERyYWZ0Lg0KDQpJIG1vZGlm aWVkIHNlY3Rpb24gOS4xLjEgb24gdGhlIG1haW50ZW5hbmNlIG9mIHRoZSBmbG93U2VsZWN0b3JB bGdvcml0aG0gcmVnaXN0cnkgYW5kIGZpeGVkIHRoZSBlZGl0b3JpYWwgaXNzdWUgaW4gc2VjdGlv biAgNi4xLjENCg0KSSBoYXZlIGFsc28gdXNlZCBNVVNUIGluIHNlY3Rpb24gNi4xDQoNCkJlc3Qg cmVnYXJkcywNCg0KU2FsdmF0b3JlDQoNCg0KRGE6IEJlbm9pdCBDbGFpc2UgW21haWx0bzpiY2xh aXNlQGNpc2NvLmNvbV0NCkludmlhdG86IGx1bmVkw6wgMTUgYXByaWxlIDIwMTMgMTE6NDMNCkE6 IFNhbHZhdG9yZSBEJ0FudG9uaW8NCkNjOiBkcmFmdC1pZXRmLWlwZml4LWZsb3ctc2VsZWN0aW9u LXRlY2hAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtaXBmaXgtZmxvdy1zZWxlY3Rp b24tdGVjaEB0b29scy5pZXRmLm9yZz47IGlwZml4LWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWls dG86aXBmaXgtY2hhaXJzQHRvb2xzLmlldGYub3JnPjsgJ1MgTW9vbmVzYW15JzsgYXBwcy1kaXNj dXNzQGlldGYub3JnPG1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmc+OyBpZXNnQGlldGYub3Jn PG1haWx0bzppZXNnQGlldGYub3JnPjsgJ0pvZWwgTS4gSGFscGVybic7ICdBLiBKZWFuIE1haG9u ZXknOyAnR2VuZXJhbCBBcmVhIFJldmlldyBUZWFtJzsgJ0lFVEYgZGlzY3Vzc2lvbiBsaXN0Jzsg cmFodWxwQGNpc2NvLmNvbTxtYWlsdG86cmFodWxwQGNpc2NvLmNvbT47IGlwZml4QGlldGYub3Jn PG1haWx0bzppcGZpeEBpZXRmLm9yZz4NCk9nZ2V0dG86IFJlOiBSOiBMYXN0IENhbGwgRXhwaXJl ZDogPGRyYWZ0LWlldGYtaXBmaXgtZmxvdy1zZWxlY3Rpb24tdGVjaC0xNC50eHQ+DQoNClNhbHZh dG9yZQ0KRGVhciBhbGwsDQoNCkEgbmV3IHZlcnNpb24gb2YgdGhlIEludGVybmV0IERyYWZ0IG9u IEZsb3cgU2VsZWN0aW9uIFRlY2huaXF1ZXMgaGFzIGJlZW4gc3VibWl0dGVkLiBJdCBjb250YWlu cyB0aGUgZm9sbG93aW5nIGNoYW5nZXM6DQoNCi0gICAgICAgICAgQSBuZXcgc2VjdGlvbiBpbGx1 c3RyYXRpbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBJbnRlcm1lZGlhdGUgRmxvdyBTZWxlY3Rp b24gUHJvY2VzcyBhbmQgSW50ZXJtZWRpYXRlIFNlbGVjdGlvbiBQcm9jZXNzIGhhcyBiZWVuIGFk ZGVkLA0KDQotICAgICAgICAgIFRoZSBzZW50ZW5jZSAiSW4gb3JkZXIgdG8gYmUgY29tcGxpYW50 IHdpdGggdGhpcyBkb2N1bWVudCwgYXQgbGVhc3QgdGhlIFByb3BlcnR5ICBNYXRjaCBGaWx0ZXJp bmcgTVVTVCBiZSBpbXBsZW1lbnRlZC4iIGhhcyBiZWVuIHJlbW92ZWQgaW4gU2VjdGlvbiAxLA0K DQotICAgICAgICAgIOKAnE1VU1TigJ0gaGFzIGJlZW4gcmVwbGFjZWQgd2l0aCDigJxTSE9VTETi gJ0gaW4gU2VjdGlvbiA1LjEsDQpBY3R1YWxseSwgdGhlIGZlZWRiYWNrIHdhczoNCkluIFNlY3Rp b24gMToNCg0KICAiSW4gb3JkZXIgdG8gYmUgY29tcGxpYW50IHdpdGggdGhpcyBkb2N1bWVudCwg YXQgbGVhc3QgdGhlIFByb3BlcnR5DQogICBNYXRjaCBGaWx0ZXJpbmcgTVVTVCBiZSBpbXBsZW1l bnRlZC4iDQoNClRoZSBhYm92ZSB0ZXh0IGlzIHJlcGVhdGVkIGluIFNlY3Rpb24gNS4xLiAgSSBz dWdnZXN0IHJlbW92aW5nIHRoaXMgc2VudGVuY2UgYXMgaXQgZG9lcyBub3Qgc2VlbSByZWxhdGVk IHRvIHNjb3BlLg0KDQpNeSByZWFkaW5nIG9mIHRoZSAiTVVTVCIgaXMgdGhhdCBpdCBpcyBiZWlu ZyB1c2VkIGZvciBjb21wbGlhbmNlIGluc3RlYWQgb2YgdGhlIHJlYXNvbnMgZGVzY3JpYmVkIGlu IFJGQyAyMTE5LiAgSSBzdWdnZXN0IHJldmlld2luZyB0aGUgdXNhZ2Ugb2YgUkZDIDIxMTkga2V5 IHdvcmRzIGluIFNlY3Rpb24gNS4xLg0KU28gdGhlIHNvbHV0aW9uIGlzIG5vdCB0byBjaGFuZ2Ug TVVTVCB0byBTSE9VTEQuDQpUaGUgcXVlc3Rpb24gaXMgd2hldGhlciAiTVVTVCIgdmVyc3VzICJt dXN0IiBtdXN0IGJlIHVzZWQuDQpJIHVuZGVyc3RhbmQgdGhlIGNvbmNlcm4uIEZvciBjb21wbGlh bmNlIHJlYXNvbiB3aXRoIHRoZSBQU0FNUCBSRkMgNTQ3NSAod2hpY2ggaXMgY2xvc2VseSByZWxh dGVkKSAuLi4NCjc8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTQ3NSNzZWN0aW9uLTc+ LiAgUGFyYW1ldGVycyBmb3IgdGhlIERlc2NyaXB0aW9uIG9mIFNlbGVjdGlvbiBUZWNobmlxdWVz DQoNCiAgIFRoaXMgc2VjdGlvbiBnaXZlcyBhbiBvdmVydmlldyBvZiBkaWZmZXJlbnQgYWx0ZXJu YXRpdmUgc2VsZWN0aW9uDQoNCiAgIHNjaGVtZXMgYW5kIHRoZWlyIHJlcXVpcmVkIHBhcmFtZXRl cnMuICBJbiBvcmRlciB0byBiZSBjb21wbGlhbnQgd2l0aA0KDQogICBQU0FNUCwgYXQgbGVhc3Qg b25lIG9mIHByb3Bvc2VkIHNjaGVtZXMgTVVTVCBiZSBpbXBsZW1lbnRlZC4NCg0KDQouLi4gSSB3 b3VsZCBrZWVwIHRoZSBpbml0aWFsICJNVVNUIiBmcm9tIHRoZSBwcmV2aW91cyBkcmFmdCB2ZXJz aW9uLg0KDQotICAgICAgICAgIOKAnFRoZSBmbG93U2VsZWN0b3JBbGdvcml0aG0gcmVnaXN0cnkg aXMgbWFpbnRhaW5lZCBieSBJQU5BLiIgaGFzIGJlZW4gcmVwbGFjZWQgd2l0aCDigJxJQU5BIGlz IHJlcXVlc3RlZCB0byBjcmVhdGUgdGhlIGZsb3dTZWxlY3RvckFsZ29yaXRobSByZWdpc3RyeS7i gJ0NCg0KLSAgICAgICAgICBUaGUgc2VudGVuY2UgIlRoZSByZWdpc3RyeSBjYW4gYmUgdXBkYXRl ZCB3aGVuIHNwZWNpZmljYXRpb25zIG9mIHRoZSBuZXcgIHRlY2huaXF1ZShzKSBhbmQgYW55IG5l dyBJbmZvcm1hdGlvbiBFbGVtZW50cyBhcmUgcHJvdmlkZWQuIiBoYXMgYmVlbiByZW1vdmVkIHNp bmNlIGl0IGRpZCBub3QgY2xhcmlmeSBob3cgdGhlIHJlZ2lzdHJ5IHdpbGwgYmUgbWFuYWdlZC4N Cg0KLSAgICAgICAgICAgU2VjdGlvbiA2LjEuMSDigJxQcm9wZXJ0eSBNYXRjaCBGaWx0ZXJpbmfi gJ0gaGFzIGJlZW4gY2hhbmdlZCBieSBhZGRpbmcgc29tZSB0ZXh0IG9uIGhvdyBQcm9wZXJ0eSBN YXRjaCBGaWx0ZXJpbmcgY2FuIGJlICB1c2VkIGJ5IGFuIEludGVybWVkaWF0ZSBGbG93IFNlbGVj dGlvbiBQcm9jZXNzIGluIHRoZSBNZXRlcmluZyBQcm9jZXNzLCBpbiB0aGUgIEV4cG9ydGluZyBQ cm9jZXNzIGFuZCB3aXRoaW4gYW4gSVBGSVggTWVkaWF0b3IuDQpXaGVuIHB1Ymxpc2hpbmcgYSBu ZXcgdmVyc2lvbiwgcGxlYXNlIGNvcnJlY3QgdGhpcyBlZGl0b3JpYWwgaXNzdWUuDQoNCiAiIC4u LiBhbmQgRmxvdyBkdXJhdGlvbi4gaW4NCg0KICAgdGhlIEFuIGV4YW1wbGUgaXMgdGhlIHNlbGVj dGlvbiBvZiB0aGUgbGFyZ2VzdCAuLi4iDQoNCg0KQmVzdCByZWdhcmRzLA0KDQpTYWx2YXRvcmUN Cg0KRGE6IEJlbm9pdCBDbGFpc2UgW21haWx0bzpiY2xhaXNlQGNpc2NvLmNvbV0NCkludmlhdG86 IGx1bmVkw6wgOCBhcHJpbGUgMjAxMyAxNToyMQ0KQTogZHJhZnQtaWV0Zi1pcGZpeC1mbG93LXNl bGVjdGlvbi10ZWNoQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWlwZml4LWZsb3ct c2VsZWN0aW9uLXRlY2hAdG9vbHMuaWV0Zi5vcmc+DQpDYzogaXBmaXgtY2hhaXJzQHRvb2xzLmll dGYub3JnPG1haWx0bzppcGZpeC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQpPZ2dldHRvOiBGd2Q6 IExhc3QgQ2FsbCBFeHBpcmVkOiA8ZHJhZnQtaWV0Zi1pcGZpeC1mbG93LXNlbGVjdGlvbi10ZWNo LTE0LnR4dD4NCg0KRGVhciBhdXRob3JzLA0KDQpUaGUgSUVURiBsYXN0IGNhbGwgaGFzIGZpbmlz aGVkLg0KQ2FuIHlvdSBwbGVhc2UgdXBkYXRlIHlvdXIgZHJhZnQgYmFzZWQgb24gdGhlIGZlZWRi YWNrIHJlY2VpdmVkLg0KVGhlbiBJIHdpbGwgcHJvZ3Jlc3MgaXQuDQoNClJlZ2FyZHMsIEJlbm9p dA0KDQoNCi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6DQoNCkxh c3QgQ2FsbCBFeHBpcmVkOiA8ZHJhZnQtaWV0Zi1pcGZpeC1mbG93LXNlbGVjdGlvbi10ZWNoLTE0 LnR4dD4NCg0KRGF0ZToNCg0KTW9uLCAwMSBBcHIgMjAxMyAwMDoyODo0NiAtMDcwMA0KDQpGcm9t Og0KDQpEcmFmdFRyYWNrZXIgTWFpbCBTeXN0ZW0gPGllc2ctc2VjcmV0YXJ5QGlldGYub3JnPjxt YWlsdG86aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc+DQoNClRvOg0KDQppZXNnQGlldGYub3JnPG1h aWx0bzppZXNnQGlldGYub3JnPiwgaXBmaXgtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzpp cGZpeC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+LCBkcmFmdC1pZXRmLWlwZml4LWZsb3ctc2VsZWN0 aW9uLXRlY2hAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtaXBmaXgtZmxvdy1zZWxl Y3Rpb24tdGVjaEB0b29scy5pZXRmLm9yZz4NCg0KQ0M6DQoNCmllc2ctc2VjcmV0YXJ5QGlldGYu b3JnPG1haWx0bzppZXNnLXNlY3JldGFyeUBpZXRmLm9yZz4NCg0KDQoNClBsZWFzZSBETyBOT1Qg cmVwbHkgdG8gdGhpcyBlbWFpbC4NCg0KDQoNCkktRDogPGRyYWZ0LWlldGYtaXBmaXgtZmxvdy1z ZWxlY3Rpb24tdGVjaC0xNC50eHQ+DQoNCklEIFRyYWNrZXIgVVJMOiBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaXBmaXgtZmxvdy1zZWxlY3Rpb24tdGVjaC8NCg0K DQoNCklFVEYgTGFzdCBDYWxsIGhhcyBlbmRlZCwgYW5kIHRoZSBzdGF0ZSBoYXMgYmVlbiBjaGFu Z2VkIHRvDQoNCldhaXRpbmcgZm9yIEFEIEdvLUFoZWFkLg0KDQoNCg0KDQoNCg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpOZXNzdW4gdmlydXMgbmVsIG1lc3NhZ2dpby4N CkNvbnRyb2xsYXRvIGRhIEFWRyAtIHd3dy5hdmcuY29tPGh0dHA6Ly93d3cuYXZnLmNvbT4NClZl cnNpb25lOiAyMDEzLjAuMzI3MiAvIERhdGFiYXNlIGRlaSB2aXJ1czogMzE2Mi82MjMxIC0gRGF0 YSBkaSByaWxhc2NpbzogMDcvMDQvMjAxMw0KDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioNCg0KSUwgTUVSSVRPIERFR0xJIFNUVURFTlRJIFZJRU5FIFJJ Q09OT1NDSVVUTw0KDQoNCg0KSWwgNSBwZXIgbWlsbGUgYWxsJ1VuaXZlcnNpdMOgIGRlZ2xpIFN0 dWRpIGRpIE5hcG9saSAiUGFydGhlbm9wZSJpbmNyZW1lbnRhIGxlIGJvcnNlIGRpIHN0dWRpbyBh Z2xpIHN0dWRlbnRpIC0gY29kaWNlIGZpc2NhbGUgODAwMTgyNDA2MzINCg0KaHR0cDovL3d3dy51 bmlwYXJ0aGVub3BlLml0L2luZGV4LnBocC81eG1pbGxlDQoNCg0KDQpodHRwOi8vd3d3LnVuaXBh cnRoZW5vcGUuaXQvaW5kZXgucGhwL2l0L2F2dmlzaS1zaXRvLWRpLWF0ZW5lby8yOTQzLWxhLXBh cnRoZW5vcGUtcHJlbWlhLWlsLXR1by12b3RvLWRpLWRpcGxvbWEtZWQtaWwtdHVvLWltZWduby1j b24taS1wcm92ZW50aS1kZWwtNS1wZXItbWlsbGUNCg0KDQpRdWVzdGEgaW5mb3JtYXRpdmEgw6gg aW5zZXJpdGEgaW4gYXV0b21hdGljbyBkYWwgc2lzdGVtYSBhbCBmaW5lIGVzY2x1c2l2byBkZWxs YSByZWFsaXp6YXppb25lIGRlaSBmaW5pIGlzdGl0dXppb25hbGkgZGVsbCdlbnRlLg0KDQoNCg0K DQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KSUwg TUVSSVRPIERFR0xJIFNUVURFTlRJIFZJRU5FIFJJQ09OT1NDSVVUTw0KDQoNCg0KSWwgNSBwZXIg bWlsbGUgYWxsJ1VuaXZlcnNpdMOgIGRlZ2xpIFN0dWRpIGRpIE5hcG9saSAiUGFydGhlbm9wZSJp bmNyZW1lbnRhIGxlIGJvcnNlIGRpIHN0dWRpbyBhZ2xpIHN0dWRlbnRpIC0gY29kaWNlIGZpc2Nh bGUgODAwMTgyNDA2MzINCg0KaHR0cDovL3d3dy51bmlwYXJ0aGVub3BlLml0L2luZGV4LnBocC81 eG1pbGxlDQoNCg0KDQpodHRwOi8vd3d3LnVuaXBhcnRoZW5vcGUuaXQvaW5kZXgucGhwL2l0L2F2 dmlzaS1zaXRvLWRpLWF0ZW5lby8yOTQzLWxhLXBhcnRoZW5vcGUtcHJlbWlhLWlsLXR1by12b3Rv LWRpLWRpcGxvbWEtZWQtaWwtdHVvLWltZWduby1jb24taS1wcm92ZW50aS1kZWwtNS1wZXItbWls bGUNCg0KDQpRdWVzdGEgaW5mb3JtYXRpdmEgw6ggaW5zZXJpdGEgaW4gYXV0b21hdGljbyBkYWwg c2lzdGVtYSBhbCBmaW5lIGVzY2x1c2l2byBkZWxsYSByZWFsaXp6YXppb25lIGRlaSBmaW5pIGlz dGl0dXppb25hbGkgZGVsbCdlbnRlLg0KDQoNCg0KDQoNCg0KDQoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCklMIE1FUklUTyBERUdMSSBTVFVERU5USSBW SUVORSBSSUNPTk9TQ0lVVE8NCg0KDQoNCklsIDUgcGVyIG1pbGxlIGFsbCdVbml2ZXJzaXTDoCBk ZWdsaSBTdHVkaSBkaSBOYXBvbGkgIlBhcnRoZW5vcGUiaW5jcmVtZW50YSBsZSBib3JzZSBkaSBz dHVkaW8gYWdsaSBzdHVkZW50aSAtIGNvZGljZSBmaXNjYWxlIDgwMDE4MjQwNjMyDQoNCmh0dHA6 Ly93d3cudW5pcGFydGhlbm9wZS5pdC9pbmRleC5waHAvNXhtaWxsZQ0KDQoNCg0KaHR0cDovL3d3 dy51bmlwYXJ0aGVub3BlLml0L2luZGV4LnBocC9pdC9hdnZpc2ktc2l0by1kaS1hdGVuZW8vMjk0 My1sYS1wYXJ0aGVub3BlLXByZW1pYS1pbC10dW8tdm90by1kaS1kaXBsb21hLWVkLWlsLXR1by1p bWVnbm8tY29uLWktcHJvdmVudGktZGVsLTUtcGVyLW1pbGxlDQoNCg0KUXVlc3RhIGluZm9ybWF0 aXZhIMOoIGluc2VyaXRhIGluIGF1dG9tYXRpY28gZGFsIHNpc3RlbWEgYWwgZmluZSBlc2NsdXNp dm8gZGVsbGEgcmVhbGl6emF6aW9uZSBkZWkgZmluaSBpc3RpdHV6aW9uYWxpIGRlbGwnZW50ZS4N Cg0KDQoNCg0KDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioNCg0KSUwgTUVSSVRPIERFR0xJIFNUVURFTlRJIFZJRU5FIFJJQ09OT1NDSVVUTw0KDQoNCg0K SWwgNSBwZXIgbWlsbGUgYWxsJ1VuaXZlcnNpdMOgIGRlZ2xpIFN0dWRpIGRpIE5hcG9saSAiUGFy dGhlbm9wZSJpbmNyZW1lbnRhIGxlIGJvcnNlIGRpIHN0dWRpbyBhZ2xpIHN0dWRlbnRpIC0gY29k aWNlIGZpc2NhbGUgODAwMTgyNDA2MzINCg0KaHR0cDovL3d3dy51bmlwYXJ0aGVub3BlLml0L2lu ZGV4LnBocC81eG1pbGxlDQoNCg0KDQpodHRwOi8vd3d3LnVuaXBhcnRoZW5vcGUuaXQvaW5kZXgu cGhwL2l0L2F2dmlzaS1zaXRvLWRpLWF0ZW5lby8yOTQzLWxhLXBhcnRoZW5vcGUtcHJlbWlhLWls LXR1by12b3RvLWRpLWRpcGxvbWEtZWQtaWwtdHVvLWltZWduby1jb24taS1wcm92ZW50aS1kZWwt NS1wZXItbWlsbGUNCg0KDQpRdWVzdGEgaW5mb3JtYXRpdmEgw6ggaW5zZXJpdGEgaW4gYXV0b21h dGljbyBkYWwgc2lzdGVtYSBhbCBmaW5lIGVzY2x1c2l2byBkZWxsYSByZWFsaXp6YXppb25lIGRl aSBmaW5pIGlzdGl0dXppb25hbGkgZGVsbCdlbnRlLg0KDQoNCg0K --_000_C7634EB63EFD984A978DFB46EA5174F2BFD824ED8FHQ1EXCH01corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYW1icmlhOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIg MiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm IjsNCgljb2xvcjpibGFjazt9DQpoMg0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5 bGUtbGluazoiSGVhZGluZyAyIENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxOC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpib2xkO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJv dHRvbTo1Ljk1cHQ7DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7 fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSGVhZGluZzJDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDIgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7 DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMiI7DQoJZm9udC1mYW1pbHk6IkNhbWJyaWEiLCJz ZXJpZiI7DQoJY29sb3I6IzRGODFCRDsNCglmb250LXdlaWdodDpib2xkO30NCnNwYW4uSFRNTFBy ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnAud2VzdGVy biwgbGkud2VzdGVybiwgZGl2Lndlc3Rlcm4NCgl7bXNvLXN0eWxlLW5hbWU6d2VzdGVybjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjUuOTVwdDsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7 DQoJY29sb3I6YmxhY2s7fQ0KcC5jamssIGxpLmNqaywgZGl2LmNqaw0KCXttc28tc3R5bGUtbmFt ZTpjams7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTo1Ljk1cHQ7DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuY3RsLCBsaS5jdGwsIGRpdi5jdGwNCgl7bXNv LXN0eWxlLW5hbWU6Y3RsOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206NS45NXB0Ow0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLlByZWZvcm1hdHRhdG9IVE1M LCBsaS5QcmVmb3JtYXR0YXRvSFRNTCwgZGl2LlByZWZvcm1hdHRhdG9IVE1MDQoJe21zby1zdHls ZS1uYW1lOiJQcmVmb3JtYXR0YXRvIEhUTUwiOw0KCW1zby1zdHlsZS1saW5rOiJQcmVmb3JtYXR0 YXRvIEhUTUwgQ2FyYXR0ZXJlIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5QcmVmb3JtYXR0YXRvSFRNTENhcmF0dGVyZQ0K CXttc28tc3R5bGUtbmFtZToiUHJlZm9ybWF0dGF0byBIVE1MIENhcmF0dGVyZSI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcmVmb3JtYXR0YXRvIEhUTUwiOw0K CWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTI3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLmgyDQoJe21zby1zdHlsZS1uYW1lOmgy O30NCnAuVGl0b2xvMiwgbGkuVGl0b2xvMiwgZGl2LlRpdG9sbzINCgl7bXNvLXN0eWxlLW5hbWU6 IlRpdG9sbyAyIjsNCgltc28tc3R5bGUtbGluazoiVGl0b2xvIDIgQ2FyYXR0ZXJlIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bh bi5UaXRvbG8yQ2FyYXR0ZXJlDQoJe21zby1zdHlsZS1uYW1lOiJUaXRvbG8gMiBDYXJhdHRlcmUi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJUaXRvbG8gMiI7DQoJ Zm9udC1mYW1pbHk6IkNhbWJyaWEiLCJzZXJpZiI7DQoJY29sb3I6IzRGODFCRDsNCglmb250LXdl aWdodDpib2xkO30NCnNwYW4uRW1haWxTdHlsZTMxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUzMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u QmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 NzAuODVwdCA1Ni43cHQgNTYuN3B0IDU2LjdwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjIxNzIxMjA5MDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6MzA4MDU3MTU4IC0xNTEzNDM5Mjc0IDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3 NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTc7fQ0K QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFz dC1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtdGFi LXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10 YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48 Ym9keSBiZ2NvbG9yPXdoaXRlIGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2 IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5k b3d0ZXh0Jz5EZWFyIEF1dGhvcnMsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5JIGhhZCBhIGdv b2QgZGlzY3Vzc2lvbiB3aXRoIEp1ZXJnZW4gb24gdGhpcyB0b3BpYy4gSGUgc3VnZ2VzdGVkIHRo YXQgSSByZWFjaCBvdXQgdG8geW91IGZvbGtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjx1PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+ U3VnZ2VzdGVkIGNoYW5nZXMgdG8gU2VjdGlvbiA2LjQ8bzpwPjwvbzpwPjwvc3Bhbj48L3U+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPkFuIGV4YW1wbGUg aXMgdGhlIMKgJnF1b3Q7U2FtcGxlIGFuZCBIb2xkJnF1b3Q7IGFsZ29yaXRobSBbRXNWYTAxXSwg b3Igc2ltaWxhciB0ZWNobmlxdWVzLCB0aGF0IHRyeSB0byBwcmVmZXIgbG9uZy1saXZlZCBsYXJn ZSB2b2x1bWUgZmxvd3MgaW4gdGhlIHNlbGVjdGlvbi4gV2hlbiBhIHBhY2tldCBhcnJpdmVzLCB0 aGVzZSBwYWNrZXQgc2VsZWN0aW9uIHRlY2huaXF1ZXMgYXJlIGFwcGxpZWQgb25seSBpZiBhIGZs b3cgcmVjb3JkIGZvciB0aGUgcGFja2V0IGRvZXMgbm90IGV4aXN0LiBUaGVzZSBwYWNrZXQgc2Vs ZWN0aW9uIHRlY2huaXF1ZXMgY291bGQgaGF2ZSBmYWxzZSBwb3NpdGl2ZXMgYnV0IG5vIGZhbHNl IG5lZ2F0aXZlczsgaS5lLiBmbG93cyB3aGljaCBhcmUgbm90IGxvbmctbGl2ZWQgbGFyZ2UgZmxv d3MgbWF5IGJlIHNlbGVjdGVkIGFuZCBsZWFybnQgaW4gdGhlIGZsb3cgY2FjaGUuIFRoZSBmbG93 cyB3aGljaCBhcmUgbm90IGxvbmctbGl2ZWQgbGFyZ2UgZmxvd3MgYXJlIGxhdGVyIHB1cmdlZCBm cm9tIHRoZSBmbG93IGNhY2hlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjx1PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+U3VnZ2VzdGVk IGNoYW5nZXMgdG8gU2VjdGlvbiA3LjI8bzpwPjwvbzpwPjwvc3Bhbj48L3U+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPkZvciB0ZWNobmlxdWVzIHNpbWls YXIgdG8g4oCcU2FtcGxlIGFuZCBIb2xk4oCdLCB0aGUgdHdvIHBhcmFtZXRlcnMgLS0gdGhlIG9i c2VydmF0aW9uIGludGVydmFsLCBhbmQgdGhlIG1pbmltdW0gYmFuZHdpZHRoIHRocmVzaG9sZCBv dmVyIHRoYXQgb2JzZXJ2YXRpb24gaW50ZXJ2YWwgLS0gc2hvdWxkIGJlIHByb2dyYW1tYWJsZSBp biBhIG5ldHdvcmtpbmcgZGV2aWNlIHRvIGZhY2lsaXRhdGUgaGFuZGxpbmcgb2YgZGlmZmVyZW50 IHVzZSBjYXNlcyBhbmQgdHJhZmZpYyBjaGFyYWN0ZXJpc3RpY3MuIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6d2lu ZG93dGV4dCc+RnJvbSBhIGJhbmR3aWR0aCBhbmQgdGltZSBkdXJhdGlvbiBwZXJzcGVjdGl2ZSwg aW4gb3JkZXIgdG8gaWRlbnRpZnkgbG9uZy1saXZlZCBsYXJnZSBmbG93cywgd2UgZGVmaW5lIGFu IG9ic2VydmF0aW9uIGludGVydmFsIGFuZCBvYnNlcnZlIHRoZSBiYW5kd2lkdGggb2YgdGhlIGZs b3cgb3ZlciB0aGF0IG9ic2VydmF0aW9uIGludGVydmFsLiBBIGZsb3cgdGhhdCBleGNlZWRzIGEg Y2VydGFpbiBtaW5pbXVtIGJhbmR3aWR0aCB0aHJlc2hvbGQgb3ZlciB0aGF0IG9ic2VydmF0aW9u IGludGVydmFsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOndpbmRvd3RleHQnPndvdWxkIGJlIGNvbnNpZGVyZWQgYSBsb25nLWxpdmVkIGxhcmdl IGZsb3cuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOndpbmRvd3RleHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5Gb3IgZXhhbXBsZSwgYSBmbG93IHdoaWNo IGlzIGF0IG9yIGFib3ZlIDEwIE1icHMgZm9yIGEgdGltZSBwZXJpb2Qgb2YgYXQgbGVhc3QgMzAg c2Vjb25kcyBjb3VsZCBiZSBkZWNsYXJlZCBhIGxvbmctbGl2ZWQgbGFyZ2UgZmxvdy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4 dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48dT48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOndpbmRvd3RleHQnPlN1Z2dlc3RlZCBjaGFuZ2VzIHRvIFNlY3Rpb24gOCBhbmQg U2VjdGlvbiA5PG86cD48L286cD48L3NwYW4+PC91PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5UaGUgcGFyYW1ldGVycyBkZXNjcmliZWQgaW4gc2VjdGlv biA3LjIuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+VGhlIHBhcmFtZXRlcnMgSSBkZXNjcmli ZWQgYWJvdmUgYXJlIGNhcHR1cmVkIGluIHNlY3Rpb24gMi4xLjIgb2YgdGhlIGRyYWZ0IGJlbG93 LiBPdGhlciBkZXRhaWxzIGFyZSBhbHNvIGNhcHR1cmVkIGluIHRoZSBkcmFmdCBiZWxvdy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93 dGV4dCc+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rcmlz aG5hbi1pcGZpeC1mbG93LWF3YXJlLXBhY2tldC1zYW1wbGluZy8/aW5jbHVkZV90ZXh0PTEiPjxz cGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0Jz5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWtyaXNobmFuLWlwZml4LWZsb3ctYXdhcmUtcGFja2V0LXNhbXBsaW5nLz9pbmNs dWRlX3RleHQ9MTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5UaGFua3MsPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRv d3RleHQnPlJhbSAoYWthIFJhbWtpKTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFz cz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+IGlwZml4LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpp cGZpeC1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPlNhbHZhdG9yZSBEJ0Fu dG9uaW88YnI+PGI+U2VudDo8L2I+IFNhdHVyZGF5LCBBcHJpbCAyMCwgMjAxMyA1OjA2IFBNPGJy PjxiPlRvOjwvYj4gJ0Jlbm9pdCBDbGFpc2UnPGJyPjxiPkNjOjwvYj4gJ0lFVEYgZGlzY3Vzc2lv biBsaXN0JzsgZHJhZnQtaWV0Zi1pcGZpeC1mbG93LXNlbGVjdGlvbi10ZWNoQHRvb2xzLmlldGYu b3JnOyBhcHBzLWRpc2N1c3NAaWV0Zi5vcmc7ICdHZW5lcmFsIEFyZWEgUmV2aWV3IFRlYW0nOyAn UyBNb29uZXNhbXknOyBpcGZpeC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGlwZml4QGlldGYub3Jn OyBpZXNnQGlldGYub3JnOyAnSm9lbCBNLiBIYWxwZXJuJzsgJ0EuIEplYW4gTWFob25leSc8YnI+ PGI+U3ViamVjdDo8L2I+IFtJUEZJWF0gUjogUjogTGFzdCBDYWxsIEV4cGlyZWQ6ICZsdDtkcmFm dC1pZXRmLWlwZml4LWZsb3ctc2VsZWN0aW9uLXRlY2gtMTQudHh0Jmd0OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5E ZWFyIEJlbm9pdCwgYWxsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ SSBzdWJtaXR0ZWQgdjE2IG9mIHRoZSBJbnRlcm5ldCBEcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIG1vZGlmaWVkIHNlY3Rpb24gOS4xLjEgb24gdGhlIG1h aW50ZW5hbmNlIG9mIHRoZSBmbG93U2VsZWN0b3JBbGdvcml0aG0gcmVnaXN0cnkgYW5kIGZpeGVk IHRoZSBlZGl0b3JpYWwgaXNzdWUgaW4gc2VjdGlvbiAmbmJzcDs2LjEuMTxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgaGF2ZSBhbHNvIHVzZWQgTVVTVCBpbiBzZWN0 aW9uIDYuMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkJlc3QgcmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5TYWx2YXRvcmU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Ig c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9y bWFsPjxiPjxzcGFuIGxhbmc9SVQgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlNlZ29lIFVJIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+RGE6PC9zcGFuPjwvYj48 c3BhbiBsYW5nPUlUIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJTZWdvZSBV SSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPiBCZW5vaXQgQ2xhaXNlIFs8YSBocmVm PSJtYWlsdG86YmNsYWlzZUBjaXNjby5jb20iPm1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbTwvYT5d IDxicj48Yj5JbnZpYXRvOjwvYj4gbHVuZWTDrCAxNSBhcHJpbGUgMjAxMyAxMTo0Mzxicj48Yj5B OjwvYj4gU2FsdmF0b3JlIEQnQW50b25pbzxicj48Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpk cmFmdC1pZXRmLWlwZml4LWZsb3ctc2VsZWN0aW9uLXRlY2hAdG9vbHMuaWV0Zi5vcmciPmRyYWZ0 LWlldGYtaXBmaXgtZmxvdy1zZWxlY3Rpb24tdGVjaEB0b29scy5pZXRmLm9yZzwvYT47IDxhIGhy ZWY9Im1haWx0bzppcGZpeC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPmlwZml4LWNoYWlyc0B0b29s cy5pZXRmLm9yZzwvYT47ICdTIE1vb25lc2FteSc7IDxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1 c3NAaWV0Zi5vcmciPmFwcHMtZGlzY3Vzc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpp ZXNnQGlldGYub3JnIj5pZXNnQGlldGYub3JnPC9hPjsgJ0pvZWwgTS4gSGFscGVybic7ICdBLiBK ZWFuIE1haG9uZXknOyAnR2VuZXJhbCBBcmVhIFJldmlldyBUZWFtJzsgJ0lFVEYgZGlzY3Vzc2lv biBsaXN0JzsgPGEgaHJlZj0ibWFpbHRvOnJhaHVscEBjaXNjby5jb20iPnJhaHVscEBjaXNjby5j b208L2E+OyA8YSBocmVmPSJtYWlsdG86aXBmaXhAaWV0Zi5vcmciPmlwZml4QGlldGYub3JnPC9h Pjxicj48Yj5PZ2dldHRvOjwvYj4gUmU6IFI6IExhc3QgQ2FsbCBFeHBpcmVkOiAmbHQ7ZHJhZnQt aWV0Zi1pcGZpeC1mbG93LXNlbGVjdGlvbi10ZWNoLTE0LnR4dCZndDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0I+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RU4tR0I+U2FsdmF0b3JlPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1b3Rl IHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RGVhciBhbGwsPC9zcGFu PjxzcGFuIGxhbmc9RU4tR0I+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9RU4tR0I+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QSBuZXcgdmVyc2lvbiBvZiB0aGUgSW50ZXJuZXQg RHJhZnQgb24gRmxvdyBTZWxlY3Rpb24gVGVjaG5pcXVlcyBoYXMgYmVlbiBzdWJtaXR0ZWQuIEl0 IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgY2hhbmdlczo8L3NwYW4+PHNwYW4gbGFuZz1FTi1HQj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4tPHNwYW4gc3R5bGU9J2ZvbnQ6 Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkEgbmV3IHNlY3Rpb24gaWxsdXN0cmF0aW5n IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gSW50ZXJtZWRpYXRlIEZsb3cgU2VsZWN0aW9uIFByb2Nl c3MgYW5kIEludGVybWVkaWF0ZSBTZWxlY3Rpb24gUHJvY2VzcyBoYXMgYmVlbiBhZGRlZCw8L3Nw YW4+PHNwYW4gbGFuZz1FTi1HQj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlz dFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBs Zm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3Jl Jz4tPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBz ZW50ZW5jZSAmcXVvdDtJbiBvcmRlciB0byBiZSBjb21wbGlhbnQgd2l0aCB0aGlzIGRvY3VtZW50 LCBhdCBsZWFzdCB0aGUgUHJvcGVydHkgJm5ic3A7TWF0Y2ggRmlsdGVyaW5nIE1VU1QgYmUgaW1w bGVtZW50ZWQuJnF1b3Q7IGhhcyBiZWVuIHJlbW92ZWQgaW4gU2VjdGlvbiAxLDwvc3Bhbj48c3Bh biBsYW5nPUVOLUdCPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdy YXBoIHN0eWxlPSd0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzInPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiInPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3Bh biBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+4oCcTVVTVOKAnSBo YXMgYmVlbiByZXBsYWNlZCB3aXRoIOKAnFNIT1VMROKAnSBpbiBTZWN0aW9uIDUuMSw8L3NwYW4+ PHNwYW4gbGFuZz1FTi1HQj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9ibG9ja3F1b3RlPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCPkFjdHVhbGx5LCB0aGUgZmVlZGJhY2sgd2Fz OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1i b3R0b206MTIuMHB0Jz48c3BhbiBsYW5nPUVOLUdCPkluIFNlY3Rpb24gMTogPGJyPjxicj4mbmJz cDsgJnF1b3Q7SW4gb3JkZXIgdG8gYmUgY29tcGxpYW50IHdpdGggdGhpcyBkb2N1bWVudCwgYXQg bGVhc3QgdGhlIFByb3BlcnR5IDxicj4mbmJzcDsmbmJzcDsgTWF0Y2ggRmlsdGVyaW5nIE1VU1Qg YmUgaW1wbGVtZW50ZWQuJnF1b3Q7IDxicj48YnI+VGhlIGFib3ZlIHRleHQgaXMgcmVwZWF0ZWQg aW4gU2VjdGlvbiA1LjEuJm5ic3A7IEkgc3VnZ2VzdCByZW1vdmluZyB0aGlzIHNlbnRlbmNlIGFz IGl0IGRvZXMgbm90IHNlZW0gcmVsYXRlZCB0byBzY29wZS4gPGJyPjxicj5NeSByZWFkaW5nIG9m IHRoZSAmcXVvdDtNVVNUJnF1b3Q7IGlzIHRoYXQgaXQgaXMgYmVpbmcgdXNlZCBmb3IgY29tcGxp YW5jZSBpbnN0ZWFkIG9mIHRoZSByZWFzb25zIGRlc2NyaWJlZCBpbiBSRkMgMjExOS4mbmJzcDsg SSBzdWdnZXN0IHJldmlld2luZyB0aGUgdXNhZ2Ugb2YgUkZDIDIxMTkga2V5IHdvcmRzIGluIFNl Y3Rpb24gNS4xLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGxhbmc9RU4tR0I+U28gdGhlIHNvbHV0aW9uIGlzIG5vdCB0byBjaGFuZ2UgTVVTVCB0byBTSE9V TEQuPGJyPlRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyICZxdW90O01VU1QmcXVvdDsgdmVyc3VzICZx dW90O211c3QmcXVvdDsgbXVzdCBiZSB1c2VkLjxicj5JIHVuZGVyc3RhbmQgdGhlIGNvbmNlcm4u IEZvciBjb21wbGlhbmNlIHJlYXNvbiB3aXRoIHRoZSBQU0FNUCBSRkMgNTQ3NSAod2hpY2ggaXMg Y2xvc2VseSByZWxhdGVkKSAuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGgyPjxhIG5hbWU9c2Vj dGlvbi03PjwvYT48c3BhbiBsYW5nPUVOLUdCPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzU0NzUjc2VjdGlvbi03Ij48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+Nzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPi4mbmJzcDsgUGFyYW1ldGVycyBmb3IgdGhlIERlc2NyaXB0 aW9uIG9mIFNlbGVjdGlvbiBUZWNobmlxdWVzPG86cD48L286cD48L3NwYW4+PC9oMj48cHJlPjxz cGFuIGxhbmc9RU4tR0I+Jm5ic3A7Jm5ic3A7IFRoaXMgc2VjdGlvbiBnaXZlcyBhbiBvdmVydmll dyBvZiBkaWZmZXJlbnQgYWx0ZXJuYXRpdmUgc2VsZWN0aW9uPG86cD48L286cD48L3NwYW4+PC9w cmU+PHByZT48c3BhbiBsYW5nPUVOLUdCPiZuYnNwOyZuYnNwOyBzY2hlbWVzIGFuZCB0aGVpciBy ZXF1aXJlZCBwYXJhbWV0ZXJzLiZuYnNwOyBJbiBvcmRlciB0byBiZSBjb21wbGlhbnQgd2l0aDxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz1FTi1HQj4mbmJzcDsmbmJzcDsg UFNBTVAsIGF0IGxlYXN0IG9uZSBvZiBwcm9wb3NlZCBzY2hlbWVzIE1VU1QgYmUgaW1wbGVtZW50 ZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBsYW5nPUVOLUdCPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcHJlPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdC Pi4uLiBJIHdvdWxkIGtlZXAgdGhlIGluaXRpYWwgJnF1b3Q7TVVTVCZxdW90OyBmcm9tIHRoZSBw cmV2aW91cyBkcmFmdCB2ZXJzaW9uLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGJsb2NrcXVvdGUg c3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PHAgY2xhc3M9TXNv TGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVs MSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdu b3JlJz4tPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPuKA nFRoZSBmbG93U2VsZWN0b3JBbGdvcml0aG0gcmVnaXN0cnkgaXMgbWFpbnRhaW5lZCBieSBJQU5B LiZxdW90OyBoYXMgYmVlbiByZXBsYWNlZCB3aXRoIOKAnElBTkEgaXMgcmVxdWVzdGVkIHRvIGNy ZWF0ZSB0aGUgZmxvd1NlbGVjdG9yQWxnb3JpdGhtIHJlZ2lzdHJ5LuKAnTwvc3Bhbj48c3BhbiBs YW5nPUVOLUdCPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBo IHN0eWxlPSd0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzInPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiInPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3BhbiBz dHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIHNlbnRlbmNlICZx dW90O1RoZSByZWdpc3RyeSBjYW4gYmUgdXBkYXRlZCB3aGVuIHNwZWNpZmljYXRpb25zIG9mIHRo ZSBuZXcmbmJzcDsgdGVjaG5pcXVlKHMpIGFuZCBhbnkgbmV3IEluZm9ybWF0aW9uIEVsZW1lbnRz IGFyZSBwcm92aWRlZC4mcXVvdDsgaGFzIGJlZW4gcmVtb3ZlZCBzaW5jZSBpdCBkaWQgbm90IGNs YXJpZnkgaG93IHRoZSByZWdpc3RyeSB3aWxsIGJlIG1hbmFnZWQuPC9zcGFuPjxzcGFuIGxhbmc9 RU4tR0I+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5 bGU9J3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMic+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIic+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+LTxzcGFuIHN0eWxl PSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDtTZWN0aW9uIDYuMS4x IOKAnFByb3BlcnR5IE1hdGNoIEZpbHRlcmluZ+KAnSBoYXMgYmVlbiBjaGFuZ2VkIGJ5IGFkZGlu ZyBzb21lIHRleHQgb24gaG93IFByb3BlcnR5IE1hdGNoIEZpbHRlcmluZyBjYW4gYmUgJm5ic3A7 dXNlZCBieSBhbiBJbnRlcm1lZGlhdGUgRmxvdyBTZWxlY3Rpb24gUHJvY2VzcyBpbiB0aGUgTWV0 ZXJpbmcgUHJvY2VzcywgaW4gdGhlICZuYnNwO0V4cG9ydGluZyBQcm9jZXNzIGFuZCB3aXRoaW4g YW4gSVBGSVggTWVkaWF0b3IuPC9zcGFuPjxzcGFuIGxhbmc9RU4tR0I+PG86cD48L286cD48L3Nw YW4+PC9wPjwvYmxvY2txdW90ZT48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0 b206MTIuMHB0Jz48c3BhbiBsYW5nPUVOLUdCPldoZW4gcHVibGlzaGluZyBhIG5ldyB2ZXJzaW9u LCBwbGVhc2UgY29ycmVjdCB0aGlzIGVkaXRvcmlhbCBpc3N1ZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHByZT48c3BhbiBsYW5nPUVOLUdCPiZuYnNwOyZxdW90OyAuLi4gYW5kIEZsb3cgZHVyYXRp b24uIGluPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBsYW5nPUVOLUdCPiZuYnNw OyZuYnNwOyB0aGUgQW4gZXhhbXBsZSBpcyB0aGUgc2VsZWN0aW9uIG9mIHRoZSBsYXJnZXN0IC4u LiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIGxhbmc9RU4tR0I+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9RU4tR0I+PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QmVz dCByZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNhbHZhdG9yZTwvc3Bh bj48c3BhbiBsYW5nPUVOLUdCPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPUVOLUdCPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1JVCBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdCc+RGE6PC9zcGFuPjwvYj48c3BhbiBsYW5nPUlUIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Jz4gQmVub2l0IENsYWlzZSBbPGEgaHJlZj0ibWFpbHRvOmJjbGFpc2VAY2lzY28uY29tIj5t YWlsdG86YmNsYWlzZUBjaXNjby5jb208L2E+XSA8YnI+PGI+SW52aWF0bzo8L2I+IGx1bmVkw6wg OCBhcHJpbGUgMjAxMyAxNToyMTxicj48Yj5BOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWll dGYtaXBmaXgtZmxvdy1zZWxlY3Rpb24tdGVjaEB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1p cGZpeC1mbG93LXNlbGVjdGlvbi10ZWNoQHRvb2xzLmlldGYub3JnPC9hPjxicj48Yj5DYzo8L2I+ IDxhIGhyZWY9Im1haWx0bzppcGZpeC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPmlwZml4LWNoYWly c0B0b29scy5pZXRmLm9yZzwvYT48YnI+PGI+T2dnZXR0bzo8L2I+IEZ3ZDogTGFzdCBDYWxsIEV4 cGlyZWQ6ICZsdDtkcmFmdC1pZXRmLWlwZml4LWZsb3ctc2VsZWN0aW9uLXRlY2gtMTQudHh0Jmd0 Ozwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0I+RGVhciBhdXRob3Jz LDxicj48YnI+VGhlIElFVEYgbGFzdCBjYWxsIGhhcyBmaW5pc2hlZC48YnI+Q2FuIHlvdSBwbGVh c2UgdXBkYXRlIHlvdXIgZHJhZnQgYmFzZWQgb24gdGhlIGZlZWRiYWNrIHJlY2VpdmVkLjxicj5U aGVuIEkgd2lsbCBwcm9ncmVzcyBpdC48YnI+PGJyPlJlZ2FyZHMsIEJlbm9pdDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCPjxicj48 YnI+LS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLSA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHRhYmxlIGNsYXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2Vs bHBhZGRpbmc9MD48dHI+PHRkIG5vd3JhcCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOjBpbiAw aW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPXJpZ2h0IHN0eWxlPSd0ZXh0LWFs aWduOnJpZ2h0Jz48Yj5TdWJqZWN0OiA8L2I+PG86cD48L286cD48L3A+PC90ZD48dGQgc3R5bGU9 J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+TGFzdCBDYWxsIEV4 cGlyZWQ6ICZsdDtkcmFmdC1pZXRmLWlwZml4LWZsb3ctc2VsZWN0aW9uLXRlY2gtMTQudHh0Jmd0 OzxvOnA+PC9vOnA+PC9wPjwvdGQ+PC90cj48dHI+PHRkIG5vd3JhcCB2YWxpZ249dG9wIHN0eWxl PSdwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPXJpZ2h0 IHN0eWxlPSd0ZXh0LWFsaWduOnJpZ2h0Jz48Yj5EYXRlOiA8L2I+PG86cD48L286cD48L3A+PC90 ZD48dGQgc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+ TW9uLCAwMSBBcHIgMjAxMyAwMDoyODo0NiAtMDcwMDxvOnA+PC9vOnA+PC9wPjwvdGQ+PC90cj48 dHI+PHRkIG5vd3JhcCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+ PHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPXJpZ2h0IHN0eWxlPSd0ZXh0LWFsaWduOnJpZ2h0Jz48 Yj5Gcm9tOiA8L2I+PG86cD48L286cD48L3A+PC90ZD48dGQgc3R5bGU9J3BhZGRpbmc6MGluIDBp biAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+RHJhZnRUcmFja2VyIE1haWwgU3lzdGVtIDxh IGhyZWY9Im1haWx0bzppZXNnLXNlY3JldGFyeUBpZXRmLm9yZyI+Jmx0O2llc2ctc2VjcmV0YXJ5 QGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcD48L3RkPjwvdHI+PHRyPjx0ZCBub3dyYXAg dmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05v cm1hbCBhbGlnbj1yaWdodCBzdHlsZT0ndGV4dC1hbGlnbjpyaWdodCc+PGI+VG86IDwvYj48bzpw PjwvbzpwPjwvcD48L3RkPjx0ZCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBpbiAwaW4nPjxwIGNs YXNzPU1zb05vcm1hbD48YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyI+aWVzZ0BpZXRmLm9y ZzwvYT4sIDxhIGhyZWY9Im1haWx0bzppcGZpeC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPmlwZml4 LWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT4sIDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWlw Zml4LWZsb3ctc2VsZWN0aW9uLXRlY2hAdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtaXBmaXgt Zmxvdy1zZWxlY3Rpb24tdGVjaEB0b29scy5pZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD48L3Rk PjwvdHI+PHRyPjx0ZCBub3dyYXAgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBp biAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1yaWdodCBzdHlsZT0ndGV4dC1hbGlnbjpy aWdodCc+PGI+Q0M6IDwvYj48bzpwPjwvbzpwPjwvcD48L3RkPjx0ZCBzdHlsZT0ncGFkZGluZzow aW4gMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48YSBocmVmPSJtYWlsdG86aWVzZy1z ZWNyZXRhcnlAaWV0Zi5vcmciPmllc2ctc2VjcmV0YXJ5QGlldGYub3JnPC9hPjxvOnA+PC9vOnA+ PC9wPjwvdGQ+PC90cj48L3RhYmxlPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJv dHRvbToxMi4wcHQnPjxzcGFuIGxhbmc9RU4tR0I+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w PjxwcmU+PHNwYW4gbGFuZz1FTi1HQj5QbGVhc2UgRE8gTk9UIHJlcGx5IHRvIHRoaXMgZW1haWwu PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBsYW5nPUVOLUdCPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz1FTi1HQj5JLUQ6ICZsdDtkcmFmdC1p ZXRmLWlwZml4LWZsb3ctc2VsZWN0aW9uLXRlY2gtMTQudHh0Jmd0OzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPjxwcmU+PHNwYW4gbGFuZz1FTi1HQj5JRCBUcmFja2VyIFVSTDogPGEgaHJlZj0iaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlwZml4LWZsb3ctc2VsZWN0 aW9uLXRlY2gvIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaXBm aXgtZmxvdy1zZWxlY3Rpb24tdGVjaC88L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48 c3BhbiBsYW5nPUVOLUdCPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4g bGFuZz1FTi1HQj5JRVRGIExhc3QgQ2FsbCBoYXMgZW5kZWQsIGFuZCB0aGUgc3RhdGUgaGFzIGJl ZW4gY2hhbmdlZCB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz1FTi1H Qj5XYWl0aW5nIGZvciBBRCBHby1BaGVhZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxz cGFuIGxhbmc9RU4tR0I+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBs YW5nPUVOLUdCPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz1F Ti1HQj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1HQj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0I+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxk aXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXIn PjxzcGFuIGxhbmc9RU4tR0I+PGhyIHNpemU9MSB3aWR0aD0iMTAwJSIgbm9zaGFkZSBzdHlsZT0n Y29sb3I6I0EwQTBBMCcgYWxpZ249Y2VudGVyPjwvc3Bhbj48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvJz48c3BhbiBsYW5nPUVOLUdCPk5lc3N1biB2aXJ1cyBuZWwgbWVzc2FnZ2lvLjxicj5Db250 cm9sbGF0byBkYSBBVkcgLSA8YSBocmVmPSJodHRwOi8vd3d3LmF2Zy5jb20iPnd3dy5hdmcuY29t PC9hPjxicj5WZXJzaW9uZTogMjAxMy4wLjMyNzIgLyBEYXRhYmFzZSBkZWkgdmlydXM6IDMxNjIv NjIzMSAtIERhdGEgZGkgcmlsYXNjaW86IDA3LzA0LzIwMTM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gbGFu Zz1FTi1HQj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9d2VzdGVybiBzdHls ZT0nbWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBsYW5nPUVO LUdCIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+KioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvc3Bhbj48c3BhbiBsYW5nPUVOLUdC PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz13ZXN0ZXJuIHN0eWxlPSdtYXJnaW4tYm90 dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5JTCBNRVJJVE8gREVHTEkgU1RVREVOVEkm bmJzcDtWSUVORSBSSUNPTk9TQ0lVVE88L3NwYW4+PHNwYW4gbGFuZz1FTi1HQj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9d2VzdGVybiBzdHlsZT0nbWFyZ2luLWJvdHRvbTowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBsYW5nPUVOLUdCPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz13ZXN0ZXJuIHN0eWxlPSdtYXJnaW4tYm90dG9tOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQnPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiJz5JbCA1IHBlciBtaWxsZSBhbGwnVW5pdmVyc2l0w6AgZGVnbGkgU3R1 ZGkgZGkgTmFwb2xpICZxdW90O1BhcnRoZW5vcGUmcXVvdDtpbmNyZW1lbnRhIGxlIGJvcnNlIGRp IHN0dWRpbyBhZ2xpIHN0dWRlbnRpIC0gY29kaWNlIGZpc2NhbGUgPGI+ODAwMTgyNDA2MzI8L2I+ IDwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz13 ZXN0ZXJuIHN0eWxlPSdtYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxz cGFuIGxhbmc9RU4tR0I+PGEgaHJlZj0iaHR0cDovL3d3dy51bmlwYXJ0aGVub3BlLml0L2luZGV4 LnBocC81eG1pbGxlIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiInPmh0dHA6Ly93d3cudW5pcGFydGhlbm9wZS5pdC9pbmRleC5waHAvNXhtaWxsZTwvc3Bhbj48 L2E+PC9zcGFuPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1FTi1HQj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9d2VzdGVybiBzdHlsZT0nbWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJv dHRvbTouMDAwMXB0Jz48c3BhbiBsYW5nPUVOLUdCPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz13ZXN0ZXJuIHN0eWxlPSdtYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQnPjxzcGFuIGxhbmc9RU4tR0I+PGEgaHJlZj0iaHR0cDovL3d3dy51bmlwYXJ0aGVu b3BlLml0L2luZGV4LnBocC9pdC9hdnZpc2ktc2l0by1kaS1hdGVuZW8vMjk0My1sYS1wYXJ0aGVu b3BlLXByZW1pYS1pbC10dW8tdm90by1kaS1kaXBsb21hLWVkLWlsLXR1by1pbWVnbm8tY29uLWkt cHJvdmVudGktZGVsLTUtcGVyLW1pbGxlIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiInPmh0dHA6Ly93d3cudW5pcGFydGhlbm9wZS5pdC9pbmRleC5waHAvaXQv YXZ2aXNpLXNpdG8tZGktYXRlbmVvLzI5NDMtbGEtcGFydGhlbm9wZS1wcmVtaWEtaWwtdHVvLXZv dG8tZGktZGlwbG9tYS1lZC1pbC10dW8taW1lZ25vLWNvbi1pLXByb3ZlbnRpLWRlbC01LXBlci1t aWxsZTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPXdlc3Rlcm4gc3R5 bGU9J21hcmdpbi1ib3R0b206MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gbGFuZz1F Ti1HQj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiInPjxicj5RdWVzdGEgaW5mb3JtYXRpdmEgw6ggaW5zZXJpdGEgaW4g YXV0b21hdGljbyBkYWwgc2lzdGVtYSBhbCBmaW5lIGVzY2x1c2l2byBkZWxsYSByZWFsaXp6YXpp b25lIGRlaSBmaW5pIGlzdGl0dXppb25hbGkgZGVsbCdlbnRlLjwvc3Bhbj48c3BhbiBsYW5nPUVO LUdCPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz13ZXN0ZXJuIHN0eWxlPSdtYXJnaW4t Ym90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIGxhbmc9RU4tR0I+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJv dHRvbToxMi4wcHQnPjxzcGFuIGxhbmc9RU4tR0I+PGJyPjxicj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9d2VzdGVybiBzdHlsZT0nbWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0Jz48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIic+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kjwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz13 ZXN0ZXJuIHN0eWxlPSdtYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxz cGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5J TCBNRVJJVE8gREVHTEkgU1RVREVOVEkmbmJzcDtWSUVORSBSSUNPTk9TQ0lVVE88L3NwYW4+PHNw YW4gbGFuZz1FTi1HQj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9d2VzdGVybiBzdHls ZT0nbWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBsYW5nPUVO LUdCPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz13ZXN0ZXJuIHN0eWxlPSdt YXJnaW4tYm90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIGxhbmc9RU4tR0Ig c3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5JbCA1IHBlciBtaWxsZSBh bGwnVW5pdmVyc2l0w6AgZGVnbGkgU3R1ZGkgZGkgTmFwb2xpICZxdW90O1BhcnRoZW5vcGUmcXVv dDtpbmNyZW1lbnRhIGxlIGJvcnNlIGRpIHN0dWRpbyBhZ2xpIHN0dWRlbnRpIC0gY29kaWNlIGZp c2NhbGUgPGI+ODAwMTgyNDA2MzI8L2I+IDwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz13ZXN0ZXJuIHN0eWxlPSdtYXJnaW4tYm90dG9tOjBpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIGxhbmc9RU4tR0I+PGEgaHJlZj0iaHR0cDovL3d3 dy51bmlwYXJ0aGVub3BlLml0L2luZGV4LnBocC81eG1pbGxlIj48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPmh0dHA6Ly93d3cudW5pcGFydGhlbm9wZS5pdC9p bmRleC5waHAvNXhtaWxsZTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9 J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz1FTi1HQj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9d2VzdGVybiBzdHlsZT0nbWFy Z2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBsYW5nPUVOLUdCPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz13ZXN0ZXJuIHN0eWxlPSdtYXJnaW4t Ym90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIGxhbmc9RU4tR0I+PGEgaHJl Zj0iaHR0cDovL3d3dy51bmlwYXJ0aGVub3BlLml0L2luZGV4LnBocC9pdC9hdnZpc2ktc2l0by1k aS1hdGVuZW8vMjk0My1sYS1wYXJ0aGVub3BlLXByZW1pYS1pbC10dW8tdm90by1kaS1kaXBsb21h LWVkLWlsLXR1by1pbWVnbm8tY29uLWktcHJvdmVudGktZGVsLTUtcGVyLW1pbGxlIj48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPmh0dHA6Ly93d3cudW5pcGFy dGhlbm9wZS5pdC9pbmRleC5waHAvaXQvYXZ2aXNpLXNpdG8tZGktYXRlbmVvLzI5NDMtbGEtcGFy dGhlbm9wZS1wcmVtaWEtaWwtdHVvLXZvdG8tZGktZGlwbG9tYS1lZC1pbC10dW8taW1lZ25vLWNv bi1pLXByb3ZlbnRpLWRlbC01LXBlci1taWxsZTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPXdlc3Rlcm4gc3R5bGU9J21hcmdpbi1ib3R0b206MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCc+PHNwYW4gbGFuZz1FTi1HQj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1FTi1H QiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxicj5RdWVzdGEgaW5m b3JtYXRpdmEgw6ggaW5zZXJpdGEgaW4gYXV0b21hdGljbyBkYWwgc2lzdGVtYSBhbCBmaW5lIGVz Y2x1c2l2byBkZWxsYSByZWFsaXp6YXppb25lIGRlaSBmaW5pIGlzdGl0dXppb25hbGkgZGVsbCdl bnRlLjwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz13ZXN0ZXJuIHN0eWxlPSdtYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQn PjxzcGFuIGxhbmc9RU4tR0I+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLUdCPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2NvbG9yOndpbmRv d3RleHQnPjxicj48YnI+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPXdlc3Rlcm4gc3R5 bGU9J21hcmdpbi1ib3R0b206MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gbGFuZz1F Ti1HQiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L3NwYW4+PHNwYW4gbGFuZz1FTi1H Qj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9d2VzdGVybiBzdHlsZT0nbWFyZ2luLWJv dHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+SUwgTUVSSVRPIERFR0xJIFNUVURFTlRJ Jm5ic3A7VklFTkUgUklDT05PU0NJVVRPPC9zcGFuPjxzcGFuIGxhbmc9RU4tR0I+PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPXdlc3Rlcm4gc3R5bGU9J21hcmdpbi1ib3R0b206MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gbGFuZz1FTi1HQj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9d2VzdGVybiBzdHlsZT0nbWFyZ2luLWJvdHRvbTowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Jz48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIic+SWwgNSBwZXIgbWlsbGUgYWxsJ1VuaXZlcnNpdMOgIGRlZ2xpIFN0 dWRpIGRpIE5hcG9saSAmcXVvdDtQYXJ0aGVub3BlJnF1b3Q7aW5jcmVtZW50YSBsZSBib3JzZSBk aSBzdHVkaW8gYWdsaSBzdHVkZW50aSAtIGNvZGljZSBmaXNjYWxlIDxiPjgwMDE4MjQwNjMyPC9i PiA8L3NwYW4+PHNwYW4gbGFuZz1FTi1HQj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 d2VzdGVybiBzdHlsZT0nbWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48 c3BhbiBsYW5nPUVOLUdCPjxhIGhyZWY9Imh0dHA6Ly93d3cudW5pcGFydGhlbm9wZS5pdC9pbmRl eC5waHAvNXhtaWxsZSI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiJz5odHRwOi8vd3d3LnVuaXBhcnRoZW5vcGUuaXQvaW5kZXgucGhwLzV4bWlsbGU8L3NwYW4+ PC9hPjwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9RU4tR0I+PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPXdlc3Rlcm4gc3R5bGU9J21hcmdpbi1ib3R0b206MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCc+PHNwYW4gbGFuZz1FTi1HQj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9d2VzdGVybiBzdHlsZT0nbWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0Jz48c3BhbiBsYW5nPUVOLUdCPjxhIGhyZWY9Imh0dHA6Ly93d3cudW5pcGFydGhl bm9wZS5pdC9pbmRleC5waHAvaXQvYXZ2aXNpLXNpdG8tZGktYXRlbmVvLzI5NDMtbGEtcGFydGhl bm9wZS1wcmVtaWEtaWwtdHVvLXZvdG8tZGktZGlwbG9tYS1lZC1pbC10dW8taW1lZ25vLWNvbi1p LXByb3ZlbnRpLWRlbC01LXBlci1taWxsZSI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiJz5odHRwOi8vd3d3LnVuaXBhcnRoZW5vcGUuaXQvaW5kZXgucGhwL2l0 L2F2dmlzaS1zaXRvLWRpLWF0ZW5lby8yOTQzLWxhLXBhcnRoZW5vcGUtcHJlbWlhLWlsLXR1by12 b3RvLWRpLWRpcGxvbWEtZWQtaWwtdHVvLWltZWduby1jb24taS1wcm92ZW50aS1kZWwtNS1wZXIt bWlsbGU8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz13ZXN0ZXJuIHN0 eWxlPSdtYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIGxhbmc9 RU4tR0I+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiJz48YnI+UXVlc3RhIGluZm9ybWF0aXZhIMOoIGluc2VyaXRhIGlu IGF1dG9tYXRpY28gZGFsIHNpc3RlbWEgYWwgZmluZSBlc2NsdXNpdm8gZGVsbGEgcmVhbGl6emF6 aW9uZSBkZWkgZmluaSBpc3RpdHV6aW9uYWxpIGRlbGwnZW50ZS48L3NwYW4+PHNwYW4gbGFuZz1F Ti1HQj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9d2VzdGVybiBzdHlsZT0nbWFyZ2lu LWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBsYW5nPUVOLUdCPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1H QiBzdHlsZT0nY29sb3I6d2luZG93dGV4dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4dCc+PGJyPjxicj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9d2VzdGVybiBzdHlsZT0nbWFyZ2luLWJvdHRv bTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiInPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKio8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9d2VzdGVybiBzdHlsZT0nbWFy Z2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPklMIE1FUklUTyBERUdMSSBTVFVERU5USSZuYnNw O1ZJRU5FIFJJQ09OT1NDSVVUTzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz13ZXN0ZXJu IHN0eWxlPSdtYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPiZuYnNwOzxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPXdlc3Rlcm4gc3R5bGU9J21hcmdpbi1ib3R0b206MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiJz5JbCA1IHBlciBtaWxsZSBhbGwnVW5pdmVyc2l0w6AgZGVnbGkgU3R1ZGkgZGkg TmFwb2xpICZxdW90O1BhcnRoZW5vcGUmcXVvdDtpbmNyZW1lbnRhIGxlIGJvcnNlIGRpIHN0dWRp byBhZ2xpIHN0dWRlbnRpIC0gY29kaWNlIGZpc2NhbGUgPGI+ODAwMTgyNDA2MzI8L2I+IDwvc3Bh bj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz13ZXN0ZXJuIHN0eWxlPSdtYXJnaW4tYm90dG9tOjBp bjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxhIGhyZWY9Imh0dHA6Ly93d3cudW5pcGFydGhlbm9w ZS5pdC9pbmRleC5waHAvNXhtaWxsZSI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiJz5odHRwOi8vd3d3LnVuaXBhcnRoZW5vcGUuaXQvaW5kZXgucGhwLzV4bWls bGU8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Iic+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXdlc3Rlcm4gc3R5bGU9J21h cmdpbi1ib3R0b206MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+Jm5ic3A7PG86cD48L286cD48 L3A+PHAgY2xhc3M9d2VzdGVybiBzdHlsZT0nbWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0Jz48YSBocmVmPSJodHRwOi8vd3d3LnVuaXBhcnRoZW5vcGUuaXQvaW5kZXgucGhw L2l0L2F2dmlzaS1zaXRvLWRpLWF0ZW5lby8yOTQzLWxhLXBhcnRoZW5vcGUtcHJlbWlhLWlsLXR1 by12b3RvLWRpLWRpcGxvbWEtZWQtaWwtdHVvLWltZWduby1jb24taS1wcm92ZW50aS1kZWwtNS1w ZXItbWlsbGUiPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+ aHR0cDovL3d3dy51bmlwYXJ0aGVub3BlLml0L2luZGV4LnBocC9pdC9hdnZpc2ktc2l0by1kaS1h dGVuZW8vMjk0My1sYS1wYXJ0aGVub3BlLXByZW1pYS1pbC10dW8tdm90by1kaS1kaXBsb21hLWVk LWlsLXR1by1pbWVnbm8tY29uLWktcHJvdmVudGktZGVsLTUtcGVyLW1pbGxlPC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz13ZXN0ZXJuIHN0eWxlPSdtYXJnaW4tYm90dG9tOjBpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQnPiZuYnNwOzxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIic+PGJyPlF1ZXN0YSBpbmZvcm1hdGl2YSDDqCBpbnNlcml0YSBpbiBh dXRvbWF0aWNvIGRhbCBzaXN0ZW1hIGFsIGZpbmUgZXNjbHVzaXZvIGRlbGxhIHJlYWxpenphemlv bmUgZGVpIGZpbmkgaXN0aXR1emlvbmFsaSBkZWxsJ2VudGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPXdlc3Rlcm4gc3R5bGU9J21hcmdpbi1ib3R0b206MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCc+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PC9ib2R5PjwvaHRtbD4= --_000_C7634EB63EFD984A978DFB46EA5174F2BFD824ED8FHQ1EXCH01corp_-- From ramk@Brocade.com Wed Apr 24 19:02:49 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28C321F90AF for ; Wed, 24 Apr 2013 19:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xw7BOhGQBxuy for ; Wed, 24 Apr 2013 19:02:47 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 69EFC21F909A for ; Wed, 24 Apr 2013 19:02:47 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r3P22jA7008133; Wed, 24 Apr 2013 19:02:45 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1bxna986k5-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 24 Apr 2013 19:02:44 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 24 Apr 2013 19:02:42 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::8c73:93bf:41b4:1443]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 24 Apr 2013 19:02:42 -0700 From: ramki Krishnan To: "Salvatore D'Antonio" , "tanja@caida.org" , "lorenzo.peluso@unina.it" Date: Wed, 24 Apr 2013 19:02:35 -0700 Thread-Topic: [IPFIX] R: R: Last Call Expired: Thread-Index: Ac45veJiRHrdfH9cTm69S7sEnZNliAEY1GBQALVtivAAFy3XgA== Message-ID: References: <20130401072846.32360.9502.idtracker@ietfa.amsl.com> <5162C44B.5030904@cisco.com> <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it> <516BCB97.9040404@cisco.com> <001001ce3e24$0a931840$1fb948c0$@dantonio@uniparthenope.it> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2BFD824EFD2HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-24_08:2013-04-24, 2013-04-24, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1304240270 Cc: IPFIX Working Group Subject: Re: [IPFIX] R: R: Last Call Expired: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 02:02:50 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2BFD824EFD2HQ1EXCH01corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBBdXRob3JzLA0KDQpUaGUgdGVjaG5pcXVlIEkgYW0gc3VnZ2VzdGluZyBpcyDigJxNdWx0 aXN0YWdlIEZpbHRlcnPigJ0gaW4gW0VzVmEwMV0gYW5kIG5vdCDigJxTYW1wbGUgYW5kIEhvbGTi gJ0uIEFwb2xvZ2llcyBmb3IgdGhlIGVycm9yLiBJIGhhdmUgZml4ZWQgdGhlIHRleHQg4oCTIG15 IHN1Z2dlc3RlZCBjaGFuZ2VzIHdpbGwgYmUgaW4gYW4gYWRkaXRpb24gdG8gd2hhdCBpcyB0aGVy ZSBjdXJyZW50bHkuDQoNCkkgaGFkIGEgZ29vZCBkaXNjdXNzaW9uIHdpdGggSnVlcmdlbiBvbiB0 aGlzIHRvcGljLiBIZSBzdWdnZXN0ZWQgdGhhdCBJIHJlYWNoIG91dCB0byB5b3UgZm9sa3MgYXQg dGhlIGVhcmxpZXN0Lg0KDQpQcm9iYWJseSBhIHNlcGFyYXRlIHN1Yi1zZWN0aW9uIGluIHNlY3Rp b24gNiA/Pz8NCkFuIGV4YW1wbGUgaXMg4oCcTXVsdGlzdGFnZSBGaWx0ZXJz4oCdIFtFc1ZhMDFd LCBvciBzaW1pbGFyIHRlY2huaXF1ZXMsIHRoYXQgdHJ5IHRvIHByZWZlciBsb25nLWxpdmVkIGxh cmdlIHZvbHVtZSBmbG93cyBpbiB0aGUgc2VsZWN0aW9uLiBXaGVuIGEgcGFja2V0IGFycml2ZXMs IHRoZXNlIHBhY2tldCBzZWxlY3Rpb24gdGVjaG5pcXVlcyBhcmUgYXBwbGllZCBvbmx5IGlmIGEg ZmxvdyByZWNvcmQgZm9yIHRoZSBwYWNrZXQgZG9lcyBub3QgZXhpc3QuIFRoZXNlIHBhY2tldCBz ZWxlY3Rpb24gdGVjaG5pcXVlcyBjb3VsZCBoYXZlIGZhbHNlIHBvc2l0aXZlcyBidXQgbm8gZmFs c2UgbmVnYXRpdmVzOyBpLmUuIGZsb3dzIHdoaWNoIGFyZSBub3QgbG9uZy1saXZlZCBsYXJnZSBm bG93cyBtYXkgYmUgc2VsZWN0ZWQgYW5kIGxlYXJudCBpbiB0aGUgZmxvdyBjYWNoZS4gVGhlIGZs b3dzIHdoaWNoIGFyZSBub3QgbG9uZy1saXZlZCBsYXJnZSBmbG93cyBhcmUgbGF0ZXIgcHVyZ2Vk IGZyb20gdGhlIGZsb3cgY2FjaGUuDQoNClN1Z2dlc3RlZCBjaGFuZ2VzIHRvIFNlY3Rpb24gNw0K Rm9yIHRlY2huaXF1ZXMgc2ltaWxhciB0byDigJxNdWx0aXN0YWdlIEZpbHRlcnPigJ0sIHRoZSB0 d28gcGFyYW1ldGVycyAtLSB0aGUgb2JzZXJ2YXRpb24gaW50ZXJ2YWwsIGFuZCB0aGUgbWluaW11 bSBiYW5kd2lkdGggdGhyZXNob2xkIG92ZXIgdGhhdCBvYnNlcnZhdGlvbiBpbnRlcnZhbCAtLSBz aG91bGQgYmUgcHJvZ3JhbW1hYmxlIGluIGEgbmV0d29ya2luZyBkZXZpY2UgdG8gZmFjaWxpdGF0 ZSBoYW5kbGluZyBvZiBkaWZmZXJlbnQgdXNlIGNhc2VzIGFuZCB0cmFmZmljIGNoYXJhY3Rlcmlz dGljcy4NCg0KRnJvbSBhIGJhbmR3aWR0aCBhbmQgdGltZSBkdXJhdGlvbiBwZXJzcGVjdGl2ZSwg aW4gb3JkZXIgdG8gaWRlbnRpZnkgbG9uZy1saXZlZCBsYXJnZSBmbG93cywgd2UgZGVmaW5lIGFu IG9ic2VydmF0aW9uIGludGVydmFsIGFuZCBvYnNlcnZlIHRoZSBiYW5kd2lkdGggb2YgdGhlIGZs b3cgb3ZlciB0aGF0IG9ic2VydmF0aW9uIGludGVydmFsLiBBIGZsb3cgdGhhdCBleGNlZWRzIGEg Y2VydGFpbiBtaW5pbXVtIGJhbmR3aWR0aCB0aHJlc2hvbGQgb3ZlciB0aGF0IG9ic2VydmF0aW9u IGludGVydmFsDQp3b3VsZCBiZSBjb25zaWRlcmVkIGEgbG9uZy1saXZlZCBsYXJnZSBmbG93Lg0K DQpGb3IgZXhhbXBsZSwgYSBmbG93IHdoaWNoIGlzIGF0IG9yIGFib3ZlIDEwIE1icHMgZm9yIGEg dGltZSBwZXJpb2Qgb2YgYXQgbGVhc3QgMzAgc2Vjb25kcyBjb3VsZCBiZSBkZWNsYXJlZCBhIGxv bmctbGl2ZWQgbGFyZ2UgZmxvdy4NCg0KU3VnZ2VzdGVkIGNoYW5nZXMgdG8gU2VjdGlvbiA4IGFu ZCBTZWN0aW9uIDkNClRoZSBwYXJhbWV0ZXJzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDcNCg0KVGhl IHBhcmFtZXRlcnMgSSBkZXNjcmliZWQgYWJvdmUgYXJlIGNhcHR1cmVkIGluIHNlY3Rpb25zIDIu MS4yLzYuMSBvZiB0aGUgZHJhZnQgYmVsb3cuIE90aGVyIGRldGFpbHMgYXJlIGFsc28gY2FwdHVy ZWQgaW4gdGhlIGRyYWZ0IGJlbG93Lg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1rcmlzaG5hbi1pcGZpeC1mbG93LWF3YXJlLXBhY2tldC1zYW1wbGluZy8/aW5jbHVkZV90 ZXh0PTENCg0KVGhhbmtzLA0KUmFta2kNCg0KRnJvbTogaXBmaXgtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86aXBmaXgtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzppcGZpeC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgcmFta2kgS3Jpc2huYW4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwg MjQsIDIwMTMgODoxMyBBTQ0KVG86IFNhbHZhdG9yZSBEJ0FudG9uaW87IHRhbmphQGNhaWRhLm9y ZzxtYWlsdG86dGFuamFAY2FpZGEub3JnPjsgbG9yZW56by5wZWx1c29AdW5pbmEuaXQ8bWFpbHRv OmxvcmVuem8ucGVsdXNvQHVuaW5hLml0Pg0KQ2M6IElQRklYIFdvcmtpbmcgR3JvdXANClN1Ympl Y3Q6IFJlOiBbSVBGSVhdIFI6IFI6IExhc3QgQ2FsbCBFeHBpcmVkOiA8ZHJhZnQtaWV0Zi1pcGZp eC1mbG93LXNlbGVjdGlvbi10ZWNoLTE0LnR4dD4NCg0KRGVhciBBdXRob3JzLA0KDQpJIGhhZCBh IGdvb2QgZGlzY3Vzc2lvbiB3aXRoIEp1ZXJnZW4gb24gdGhpcyB0b3BpYy4gSGUgc3VnZ2VzdGVk IHRoYXQgSSByZWFjaCBvdXQgdG8geW91IGZvbGtzLg0KDQpTdWdnZXN0ZWQgY2hhbmdlcyB0byBT ZWN0aW9uIDYuNA0KQW4gZXhhbXBsZSBpcyB0aGUgICJTYW1wbGUgYW5kIEhvbGQiIGFsZ29yaXRo bSBbRXNWYTAxXSwgb3Igc2ltaWxhciB0ZWNobmlxdWVzLCB0aGF0IHRyeSB0byBwcmVmZXIgbG9u Zy1saXZlZCBsYXJnZSB2b2x1bWUgZmxvd3MgaW4gdGhlIHNlbGVjdGlvbi4gV2hlbiBhIHBhY2tl dCBhcnJpdmVzLCB0aGVzZSBwYWNrZXQgc2VsZWN0aW9uIHRlY2huaXF1ZXMgYXJlIGFwcGxpZWQg b25seSBpZiBhIGZsb3cgcmVjb3JkIGZvciB0aGUgcGFja2V0IGRvZXMgbm90IGV4aXN0LiBUaGVz ZSBwYWNrZXQgc2VsZWN0aW9uIHRlY2huaXF1ZXMgY291bGQgaGF2ZSBmYWxzZSBwb3NpdGl2ZXMg YnV0IG5vIGZhbHNlIG5lZ2F0aXZlczsgaS5lLiBmbG93cyB3aGljaCBhcmUgbm90IGxvbmctbGl2 ZWQgbGFyZ2UgZmxvd3MgbWF5IGJlIHNlbGVjdGVkIGFuZCBsZWFybnQgaW4gdGhlIGZsb3cgY2Fj aGUuIFRoZSBmbG93cyB3aGljaCBhcmUgbm90IGxvbmctbGl2ZWQgbGFyZ2UgZmxvd3MgYXJlIGxh dGVyIHB1cmdlZCBmcm9tIHRoZSBmbG93IGNhY2hlLg0KDQpTdWdnZXN0ZWQgY2hhbmdlcyB0byBT ZWN0aW9uIDcuMg0KRm9yIHRlY2huaXF1ZXMgc2ltaWxhciB0byDigJxTYW1wbGUgYW5kIEhvbGTi gJ0sIHRoZSB0d28gcGFyYW1ldGVycyAtLSB0aGUgb2JzZXJ2YXRpb24gaW50ZXJ2YWwsIGFuZCB0 aGUgbWluaW11bSBiYW5kd2lkdGggdGhyZXNob2xkIG92ZXIgdGhhdCBvYnNlcnZhdGlvbiBpbnRl cnZhbCAtLSBzaG91bGQgYmUgcHJvZ3JhbW1hYmxlIGluIGEgbmV0d29ya2luZyBkZXZpY2UgdG8g ZmFjaWxpdGF0ZSBoYW5kbGluZyBvZiBkaWZmZXJlbnQgdXNlIGNhc2VzIGFuZCB0cmFmZmljIGNo YXJhY3RlcmlzdGljcy4NCg0KRnJvbSBhIGJhbmR3aWR0aCBhbmQgdGltZSBkdXJhdGlvbiBwZXJz cGVjdGl2ZSwgaW4gb3JkZXIgdG8gaWRlbnRpZnkgbG9uZy1saXZlZCBsYXJnZSBmbG93cywgd2Ug ZGVmaW5lIGFuIG9ic2VydmF0aW9uIGludGVydmFsIGFuZCBvYnNlcnZlIHRoZSBiYW5kd2lkdGgg b2YgdGhlIGZsb3cgb3ZlciB0aGF0IG9ic2VydmF0aW9uIGludGVydmFsLiBBIGZsb3cgdGhhdCBl eGNlZWRzIGEgY2VydGFpbiBtaW5pbXVtIGJhbmR3aWR0aCB0aHJlc2hvbGQgb3ZlciB0aGF0IG9i c2VydmF0aW9uIGludGVydmFsDQp3b3VsZCBiZSBjb25zaWRlcmVkIGEgbG9uZy1saXZlZCBsYXJn ZSBmbG93Lg0KDQpGb3IgZXhhbXBsZSwgYSBmbG93IHdoaWNoIGlzIGF0IG9yIGFib3ZlIDEwIE1i cHMgZm9yIGEgdGltZSBwZXJpb2Qgb2YgYXQgbGVhc3QgMzAgc2Vjb25kcyBjb3VsZCBiZSBkZWNs YXJlZCBhIGxvbmctbGl2ZWQgbGFyZ2UgZmxvdy4NCg0KU3VnZ2VzdGVkIGNoYW5nZXMgdG8gU2Vj dGlvbiA4IGFuZCBTZWN0aW9uIDkNClRoZSBwYXJhbWV0ZXJzIGRlc2NyaWJlZCBpbiBzZWN0aW9u IDcuMi4NCg0KVGhlIHBhcmFtZXRlcnMgSSBkZXNjcmliZWQgYWJvdmUgYXJlIGNhcHR1cmVkIGlu IHNlY3Rpb24gMi4xLjIgb2YgdGhlIGRyYWZ0IGJlbG93LiBPdGhlciBkZXRhaWxzIGFyZSBhbHNv IGNhcHR1cmVkIGluIHRoZSBkcmFmdCBiZWxvdy4NCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQta3Jpc2huYW4taXBmaXgtZmxvdy1hd2FyZS1wYWNrZXQtc2FtcGxpbmcvP2lu Y2x1ZGVfdGV4dD0xDQoNClRoYW5rcywNClJhbSAoYWthIFJhbWtpKQ0KRnJvbTogaXBmaXgtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86aXBmaXgtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzppcGZp eC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2FsdmF0b3JlIEQnQW50b25pbw0KU2Vu dDogU2F0dXJkYXksIEFwcmlsIDIwLCAyMDEzIDU6MDYgUE0NClRvOiAnQmVub2l0IENsYWlzZScN CkNjOiAnSUVURiBkaXNjdXNzaW9uIGxpc3QnOyBkcmFmdC1pZXRmLWlwZml4LWZsb3ctc2VsZWN0 aW9uLXRlY2hAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtaXBmaXgtZmxvdy1zZWxl Y3Rpb24tdGVjaEB0b29scy5pZXRmLm9yZz47IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZzxtYWlsdG86 YXBwcy1kaXNjdXNzQGlldGYub3JnPjsgJ0dlbmVyYWwgQXJlYSBSZXZpZXcgVGVhbSc7ICdTIE1v b25lc2FteSc7IGlwZml4LWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86aXBmaXgtY2hhaXJz QHRvb2xzLmlldGYub3JnPjsgaXBmaXhAaWV0Zi5vcmc8bWFpbHRvOmlwZml4QGlldGYub3JnPjsg aWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz47ICdKb2VsIE0uIEhhbHBlcm4nOyAn QS4gSmVhbiBNYWhvbmV5Jw0KU3ViamVjdDogW0lQRklYXSBSOiBSOiBMYXN0IENhbGwgRXhwaXJl ZDogPGRyYWZ0LWlldGYtaXBmaXgtZmxvdy1zZWxlY3Rpb24tdGVjaC0xNC50eHQ+DQoNCkRlYXIg QmVub2l0LCBhbGwNCg0KSSBzdWJtaXR0ZWQgdjE2IG9mIHRoZSBJbnRlcm5ldCBEcmFmdC4NCg0K SSBtb2RpZmllZCBzZWN0aW9uIDkuMS4xIG9uIHRoZSBtYWludGVuYW5jZSBvZiB0aGUgZmxvd1Nl bGVjdG9yQWxnb3JpdGhtIHJlZ2lzdHJ5IGFuZCBmaXhlZCB0aGUgZWRpdG9yaWFsIGlzc3VlIGlu IHNlY3Rpb24gIDYuMS4xDQoNCkkgaGF2ZSBhbHNvIHVzZWQgTVVTVCBpbiBzZWN0aW9uIDYuMQ0K DQpCZXN0IHJlZ2FyZHMsDQoNClNhbHZhdG9yZQ0KDQoNCkRhOiBCZW5vaXQgQ2xhaXNlIFttYWls dG86YmNsYWlzZUBjaXNjby5jb21dDQpJbnZpYXRvOiBsdW5lZMOsIDE1IGFwcmlsZSAyMDEzIDEx OjQzDQpBOiBTYWx2YXRvcmUgRCdBbnRvbmlvDQpDYzogZHJhZnQtaWV0Zi1pcGZpeC1mbG93LXNl bGVjdGlvbi10ZWNoQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWlwZml4LWZsb3ct c2VsZWN0aW9uLXRlY2hAdG9vbHMuaWV0Zi5vcmc+OyBpcGZpeC1jaGFpcnNAdG9vbHMuaWV0Zi5v cmc8bWFpbHRvOmlwZml4LWNoYWlyc0B0b29scy5pZXRmLm9yZz47ICdTIE1vb25lc2FteSc7IGFw cHMtZGlzY3Vzc0BpZXRmLm9yZzxtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnPjsgaWVzZ0Bp ZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz47ICdKb2VsIE0uIEhhbHBlcm4nOyAnQS4gSmVh biBNYWhvbmV5JzsgJ0dlbmVyYWwgQXJlYSBSZXZpZXcgVGVhbSc7ICdJRVRGIGRpc2N1c3Npb24g bGlzdCc7IHJhaHVscEBjaXNjby5jb208bWFpbHRvOnJhaHVscEBjaXNjby5jb20+OyBpcGZpeEBp ZXRmLm9yZzxtYWlsdG86aXBmaXhAaWV0Zi5vcmc+DQpPZ2dldHRvOiBSZTogUjogTGFzdCBDYWxs IEV4cGlyZWQ6IDxkcmFmdC1pZXRmLWlwZml4LWZsb3ctc2VsZWN0aW9uLXRlY2gtMTQudHh0Pg0K DQpTYWx2YXRvcmUNCkRlYXIgYWxsLA0KDQpBIG5ldyB2ZXJzaW9uIG9mIHRoZSBJbnRlcm5ldCBE cmFmdCBvbiBGbG93IFNlbGVjdGlvbiBUZWNobmlxdWVzIGhhcyBiZWVuIHN1Ym1pdHRlZC4gSXQg Y29udGFpbnMgdGhlIGZvbGxvd2luZyBjaGFuZ2VzOg0KDQotICAgICAgICAgIEEgbmV3IHNlY3Rp b24gaWxsdXN0cmF0aW5nIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gSW50ZXJtZWRpYXRlIEZsb3cg U2VsZWN0aW9uIFByb2Nlc3MgYW5kIEludGVybWVkaWF0ZSBTZWxlY3Rpb24gUHJvY2VzcyBoYXMg YmVlbiBhZGRlZCwNCg0KLSAgICAgICAgICBUaGUgc2VudGVuY2UgIkluIG9yZGVyIHRvIGJlIGNv bXBsaWFudCB3aXRoIHRoaXMgZG9jdW1lbnQsIGF0IGxlYXN0IHRoZSBQcm9wZXJ0eSAgTWF0Y2gg RmlsdGVyaW5nIE1VU1QgYmUgaW1wbGVtZW50ZWQuIiBoYXMgYmVlbiByZW1vdmVkIGluIFNlY3Rp b24gMSwNCg0KLSAgICAgICAgICDigJxNVVNU4oCdIGhhcyBiZWVuIHJlcGxhY2VkIHdpdGgg4oCc U0hPVUxE4oCdIGluIFNlY3Rpb24gNS4xLA0KQWN0dWFsbHksIHRoZSBmZWVkYmFjayB3YXM6DQpJ biBTZWN0aW9uIDE6DQoNCiAgIkluIG9yZGVyIHRvIGJlIGNvbXBsaWFudCB3aXRoIHRoaXMgZG9j dW1lbnQsIGF0IGxlYXN0IHRoZSBQcm9wZXJ0eQ0KICAgTWF0Y2ggRmlsdGVyaW5nIE1VU1QgYmUg aW1wbGVtZW50ZWQuIg0KDQpUaGUgYWJvdmUgdGV4dCBpcyByZXBlYXRlZCBpbiBTZWN0aW9uIDUu MS4gIEkgc3VnZ2VzdCByZW1vdmluZyB0aGlzIHNlbnRlbmNlIGFzIGl0IGRvZXMgbm90IHNlZW0g cmVsYXRlZCB0byBzY29wZS4NCg0KTXkgcmVhZGluZyBvZiB0aGUgIk1VU1QiIGlzIHRoYXQgaXQg aXMgYmVpbmcgdXNlZCBmb3IgY29tcGxpYW5jZSBpbnN0ZWFkIG9mIHRoZSByZWFzb25zIGRlc2Ny aWJlZCBpbiBSRkMgMjExOS4gIEkgc3VnZ2VzdCByZXZpZXdpbmcgdGhlIHVzYWdlIG9mIFJGQyAy MTE5IGtleSB3b3JkcyBpbiBTZWN0aW9uIDUuMS4NClNvIHRoZSBzb2x1dGlvbiBpcyBub3QgdG8g Y2hhbmdlIE1VU1QgdG8gU0hPVUxELg0KVGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgIk1VU1QiIHZl cnN1cyAibXVzdCIgbXVzdCBiZSB1c2VkLg0KSSB1bmRlcnN0YW5kIHRoZSBjb25jZXJuLiBGb3Ig Y29tcGxpYW5jZSByZWFzb24gd2l0aCB0aGUgUFNBTVAgUkZDIDU0NzUgKHdoaWNoIGlzIGNsb3Nl bHkgcmVsYXRlZCkgLi4uDQo3PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU0NzUjc2Vj dGlvbi03Pi4gIFBhcmFtZXRlcnMgZm9yIHRoZSBEZXNjcmlwdGlvbiBvZiBTZWxlY3Rpb24gVGVj aG5pcXVlcw0KDQogICBUaGlzIHNlY3Rpb24gZ2l2ZXMgYW4gb3ZlcnZpZXcgb2YgZGlmZmVyZW50 IGFsdGVybmF0aXZlIHNlbGVjdGlvbg0KDQogICBzY2hlbWVzIGFuZCB0aGVpciByZXF1aXJlZCBw YXJhbWV0ZXJzLiAgSW4gb3JkZXIgdG8gYmUgY29tcGxpYW50IHdpdGgNCg0KICAgUFNBTVAsIGF0 IGxlYXN0IG9uZSBvZiBwcm9wb3NlZCBzY2hlbWVzIE1VU1QgYmUgaW1wbGVtZW50ZWQuDQoNCg0K Li4uIEkgd291bGQga2VlcCB0aGUgaW5pdGlhbCAiTVVTVCIgZnJvbSB0aGUgcHJldmlvdXMgZHJh ZnQgdmVyc2lvbi4NCg0KLSAgICAgICAgICDigJxUaGUgZmxvd1NlbGVjdG9yQWxnb3JpdGhtIHJl Z2lzdHJ5IGlzIG1haW50YWluZWQgYnkgSUFOQS4iIGhhcyBiZWVuIHJlcGxhY2VkIHdpdGgg4oCc SUFOQSBpcyByZXF1ZXN0ZWQgdG8gY3JlYXRlIHRoZSBmbG93U2VsZWN0b3JBbGdvcml0aG0gcmVn aXN0cnku4oCdDQoNCi0gICAgICAgICAgVGhlIHNlbnRlbmNlICJUaGUgcmVnaXN0cnkgY2FuIGJl IHVwZGF0ZWQgd2hlbiBzcGVjaWZpY2F0aW9ucyBvZiB0aGUgbmV3ICB0ZWNobmlxdWUocykgYW5k IGFueSBuZXcgSW5mb3JtYXRpb24gRWxlbWVudHMgYXJlIHByb3ZpZGVkLiIgaGFzIGJlZW4gcmVt b3ZlZCBzaW5jZSBpdCBkaWQgbm90IGNsYXJpZnkgaG93IHRoZSByZWdpc3RyeSB3aWxsIGJlIG1h bmFnZWQuDQoNCi0gICAgICAgICAgIFNlY3Rpb24gNi4xLjEg4oCcUHJvcGVydHkgTWF0Y2ggRmls dGVyaW5n4oCdIGhhcyBiZWVuIGNoYW5nZWQgYnkgYWRkaW5nIHNvbWUgdGV4dCBvbiBob3cgUHJv cGVydHkgTWF0Y2ggRmlsdGVyaW5nIGNhbiBiZSAgdXNlZCBieSBhbiBJbnRlcm1lZGlhdGUgRmxv dyBTZWxlY3Rpb24gUHJvY2VzcyBpbiB0aGUgTWV0ZXJpbmcgUHJvY2VzcywgaW4gdGhlICBFeHBv cnRpbmcgUHJvY2VzcyBhbmQgd2l0aGluIGFuIElQRklYIE1lZGlhdG9yLg0KV2hlbiBwdWJsaXNo aW5nIGEgbmV3IHZlcnNpb24sIHBsZWFzZSBjb3JyZWN0IHRoaXMgZWRpdG9yaWFsIGlzc3VlLg0K DQogIiAuLi4gYW5kIEZsb3cgZHVyYXRpb24uIGluDQoNCiAgIHRoZSBBbiBleGFtcGxlIGlzIHRo ZSBzZWxlY3Rpb24gb2YgdGhlIGxhcmdlc3QgLi4uIg0KDQoNCkJlc3QgcmVnYXJkcywNCg0KU2Fs dmF0b3JlDQoNCkRhOiBCZW5vaXQgQ2xhaXNlIFttYWlsdG86YmNsYWlzZUBjaXNjby5jb21dDQpJ bnZpYXRvOiBsdW5lZMOsIDggYXByaWxlIDIwMTMgMTU6MjENCkE6IGRyYWZ0LWlldGYtaXBmaXgt Zmxvdy1zZWxlY3Rpb24tdGVjaEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1pcGZp eC1mbG93LXNlbGVjdGlvbi10ZWNoQHRvb2xzLmlldGYub3JnPg0KQ2M6IGlwZml4LWNoYWlyc0B0 b29scy5pZXRmLm9yZzxtYWlsdG86aXBmaXgtY2hhaXJzQHRvb2xzLmlldGYub3JnPg0KT2dnZXR0 bzogRndkOiBMYXN0IENhbGwgRXhwaXJlZDogPGRyYWZ0LWlldGYtaXBmaXgtZmxvdy1zZWxlY3Rp b24tdGVjaC0xNC50eHQ+DQoNCkRlYXIgYXV0aG9ycywNCg0KVGhlIElFVEYgbGFzdCBjYWxsIGhh cyBmaW5pc2hlZC4NCkNhbiB5b3UgcGxlYXNlIHVwZGF0ZSB5b3VyIGRyYWZ0IGJhc2VkIG9uIHRo ZSBmZWVkYmFjayByZWNlaXZlZC4NClRoZW4gSSB3aWxsIHByb2dyZXNzIGl0Lg0KDQpSZWdhcmRz LCBCZW5vaXQNCg0KDQotLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0 Og0KDQpMYXN0IENhbGwgRXhwaXJlZDogPGRyYWZ0LWlldGYtaXBmaXgtZmxvdy1zZWxlY3Rpb24t dGVjaC0xNC50eHQ+DQoNCkRhdGU6DQoNCk1vbiwgMDEgQXByIDIwMTMgMDA6Mjg6NDYgLTA3MDAN Cg0KRnJvbToNCg0KRHJhZnRUcmFja2VyIE1haWwgU3lzdGVtIDxpZXNnLXNlY3JldGFyeUBpZXRm Lm9yZz48bWFpbHRvOmllc2ctc2VjcmV0YXJ5QGlldGYub3JnPg0KDQpUbzoNCg0KaWVzZ0BpZXRm Lm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4sIGlwZml4LWNoYWlyc0B0b29scy5pZXRmLm9yZzxt YWlsdG86aXBmaXgtY2hhaXJzQHRvb2xzLmlldGYub3JnPiwgZHJhZnQtaWV0Zi1pcGZpeC1mbG93 LXNlbGVjdGlvbi10ZWNoQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWlwZml4LWZs b3ctc2VsZWN0aW9uLXRlY2hAdG9vbHMuaWV0Zi5vcmc+DQoNCkNDOg0KDQppZXNnLXNlY3JldGFy eUBpZXRmLm9yZzxtYWlsdG86aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc+DQoNCg0KDQpQbGVhc2Ug RE8gTk9UIHJlcGx5IHRvIHRoaXMgZW1haWwuDQoNCg0KDQpJLUQ6IDxkcmFmdC1pZXRmLWlwZml4 LWZsb3ctc2VsZWN0aW9uLXRlY2gtMTQudHh0Pg0KDQpJRCBUcmFja2VyIFVSTDogaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlwZml4LWZsb3ctc2VsZWN0aW9uLXRl Y2gvDQoNCg0KDQpJRVRGIExhc3QgQ2FsbCBoYXMgZW5kZWQsIGFuZCB0aGUgc3RhdGUgaGFzIGJl ZW4gY2hhbmdlZCB0bw0KDQpXYWl0aW5nIGZvciBBRCBHby1BaGVhZC4NCg0KDQoNCg0KDQoNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTmVzc3VuIHZpcnVzIG5lbCBtZXNz YWdnaW8uDQpDb250cm9sbGF0byBkYSBBVkcgLSB3d3cuYXZnLmNvbTxodHRwOi8vd3d3LmF2Zy5j b20+DQpWZXJzaW9uZTogMjAxMy4wLjMyNzIgLyBEYXRhYmFzZSBkZWkgdmlydXM6IDMxNjIvNjIz MSAtIERhdGEgZGkgcmlsYXNjaW86IDA3LzA0LzIwMTMNCg0KDQoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCklMIE1FUklUTyBERUdMSSBTVFVERU5USSBW SUVORSBSSUNPTk9TQ0lVVE8NCg0KDQoNCklsIDUgcGVyIG1pbGxlIGFsbCdVbml2ZXJzaXTDoCBk ZWdsaSBTdHVkaSBkaSBOYXBvbGkgIlBhcnRoZW5vcGUiaW5jcmVtZW50YSBsZSBib3JzZSBkaSBz dHVkaW8gYWdsaSBzdHVkZW50aSAtIGNvZGljZSBmaXNjYWxlIDgwMDE4MjQwNjMyDQoNCmh0dHA6 Ly93d3cudW5pcGFydGhlbm9wZS5pdC9pbmRleC5waHAvNXhtaWxsZQ0KDQoNCg0KaHR0cDovL3d3 dy51bmlwYXJ0aGVub3BlLml0L2luZGV4LnBocC9pdC9hdnZpc2ktc2l0by1kaS1hdGVuZW8vMjk0 My1sYS1wYXJ0aGVub3BlLXByZW1pYS1pbC10dW8tdm90by1kaS1kaXBsb21hLWVkLWlsLXR1by1p bWVnbm8tY29uLWktcHJvdmVudGktZGVsLTUtcGVyLW1pbGxlDQoNCg0KUXVlc3RhIGluZm9ybWF0 aXZhIMOoIGluc2VyaXRhIGluIGF1dG9tYXRpY28gZGFsIHNpc3RlbWEgYWwgZmluZSBlc2NsdXNp dm8gZGVsbGEgcmVhbGl6emF6aW9uZSBkZWkgZmluaSBpc3RpdHV6aW9uYWxpIGRlbGwnZW50ZS4N Cg0KDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K DQpJTCBNRVJJVE8gREVHTEkgU1RVREVOVEkgVklFTkUgUklDT05PU0NJVVRPDQoNCg0KDQpJbCA1 IHBlciBtaWxsZSBhbGwnVW5pdmVyc2l0w6AgZGVnbGkgU3R1ZGkgZGkgTmFwb2xpICJQYXJ0aGVu b3BlImluY3JlbWVudGEgbGUgYm9yc2UgZGkgc3R1ZGlvIGFnbGkgc3R1ZGVudGkgLSBjb2RpY2Ug ZmlzY2FsZSA4MDAxODI0MDYzMg0KDQpodHRwOi8vd3d3LnVuaXBhcnRoZW5vcGUuaXQvaW5kZXgu cGhwLzV4bWlsbGUNCg0KDQoNCmh0dHA6Ly93d3cudW5pcGFydGhlbm9wZS5pdC9pbmRleC5waHAv aXQvYXZ2aXNpLXNpdG8tZGktYXRlbmVvLzI5NDMtbGEtcGFydGhlbm9wZS1wcmVtaWEtaWwtdHVv LXZvdG8tZGktZGlwbG9tYS1lZC1pbC10dW8taW1lZ25vLWNvbi1pLXByb3ZlbnRpLWRlbC01LXBl ci1taWxsZQ0KDQoNClF1ZXN0YSBpbmZvcm1hdGl2YSDDqCBpbnNlcml0YSBpbiBhdXRvbWF0aWNv IGRhbCBzaXN0ZW1hIGFsIGZpbmUgZXNjbHVzaXZvIGRlbGxhIHJlYWxpenphemlvbmUgZGVpIGZp bmkgaXN0aXR1emlvbmFsaSBkZWxsJ2VudGUuDQoNCg0KDQoNCg0KDQoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCklMIE1FUklUTyBERUdMSSBTVFVERU5U SSBWSUVORSBSSUNPTk9TQ0lVVE8NCg0KDQoNCklsIDUgcGVyIG1pbGxlIGFsbCdVbml2ZXJzaXTD oCBkZWdsaSBTdHVkaSBkaSBOYXBvbGkgIlBhcnRoZW5vcGUiaW5jcmVtZW50YSBsZSBib3JzZSBk aSBzdHVkaW8gYWdsaSBzdHVkZW50aSAtIGNvZGljZSBmaXNjYWxlIDgwMDE4MjQwNjMyDQoNCmh0 dHA6Ly93d3cudW5pcGFydGhlbm9wZS5pdC9pbmRleC5waHAvNXhtaWxsZQ0KDQoNCg0KaHR0cDov L3d3dy51bmlwYXJ0aGVub3BlLml0L2luZGV4LnBocC9pdC9hdnZpc2ktc2l0by1kaS1hdGVuZW8v Mjk0My1sYS1wYXJ0aGVub3BlLXByZW1pYS1pbC10dW8tdm90by1kaS1kaXBsb21hLWVkLWlsLXR1 by1pbWVnbm8tY29uLWktcHJvdmVudGktZGVsLTUtcGVyLW1pbGxlDQoNCg0KUXVlc3RhIGluZm9y bWF0aXZhIMOoIGluc2VyaXRhIGluIGF1dG9tYXRpY28gZGFsIHNpc3RlbWEgYWwgZmluZSBlc2Ns dXNpdm8gZGVsbGEgcmVhbGl6emF6aW9uZSBkZWkgZmluaSBpc3RpdHV6aW9uYWxpIGRlbGwnZW50 ZS4NCg0KDQoNCg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqDQoNCklMIE1FUklUTyBERUdMSSBTVFVERU5USSBWSUVORSBSSUNPTk9TQ0lVVE8NCg0KDQoN CklsIDUgcGVyIG1pbGxlIGFsbCdVbml2ZXJzaXTDoCBkZWdsaSBTdHVkaSBkaSBOYXBvbGkgIlBh cnRoZW5vcGUiaW5jcmVtZW50YSBsZSBib3JzZSBkaSBzdHVkaW8gYWdsaSBzdHVkZW50aSAtIGNv ZGljZSBmaXNjYWxlIDgwMDE4MjQwNjMyDQoNCmh0dHA6Ly93d3cudW5pcGFydGhlbm9wZS5pdC9p bmRleC5waHAvNXhtaWxsZQ0KDQoNCg0KaHR0cDovL3d3dy51bmlwYXJ0aGVub3BlLml0L2luZGV4 LnBocC9pdC9hdnZpc2ktc2l0by1kaS1hdGVuZW8vMjk0My1sYS1wYXJ0aGVub3BlLXByZW1pYS1p bC10dW8tdm90by1kaS1kaXBsb21hLWVkLWlsLXR1by1pbWVnbm8tY29uLWktcHJvdmVudGktZGVs LTUtcGVyLW1pbGxlDQoNCg0KUXVlc3RhIGluZm9ybWF0aXZhIMOoIGluc2VyaXRhIGluIGF1dG9t YXRpY28gZGFsIHNpc3RlbWEgYWwgZmluZSBlc2NsdXNpdm8gZGVsbGEgcmVhbGl6emF6aW9uZSBk ZWkgZmluaSBpc3RpdHV6aW9uYWxpIGRlbGwnZW50ZS4NCg0KDQoNCg== --_000_C7634EB63EFD984A978DFB46EA5174F2BFD824EFD2HQ1EXCH01corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYW1icmlhOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIg MiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm IjsNCgljb2xvcjpibGFjazt9DQpoMg0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5 bGUtbGluazoiSGVhZGluZyAyIENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxOC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpib2xkO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJv dHRvbTo1Ljk1cHQ7DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7 fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSGVhZGluZzJDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDIgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7 DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMiI7DQoJZm9udC1mYW1pbHk6IkNhbWJyaWEiLCJz ZXJpZiI7DQoJY29sb3I6IzRGODFCRDsNCglmb250LXdlaWdodDpib2xkO30NCnNwYW4uSFRNTFBy ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFs bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLndlc3Rl cm4sIGxpLndlc3Rlcm4sIGRpdi53ZXN0ZXJuDQoJe21zby1zdHlsZS1uYW1lOndlc3Rlcm47DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTo1Ljk1cHQ7DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi Ow0KCWNvbG9yOmJsYWNrO30NCnAuY2prLCBsaS5jamssIGRpdi5jamsNCgl7bXNvLXN0eWxlLW5h bWU6Y2prOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206NS45NXB0Ow0KCW1hcmdpbi1s ZWZ0OjBpbjsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLmN0bCwgbGkuY3RsLCBkaXYuY3RsDQoJe21z by1zdHlsZS1uYW1lOmN0bDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjUuOTVwdDsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5QcmVmb3JtYXR0YXRv SFRNTENhcmF0dGVyZQ0KCXttc28tc3R5bGUtbmFtZToiUHJlZm9ybWF0dGF0byBIVE1MIENhcmF0 dGVyZSI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcmVmb3Jt YXR0YXRvIEhUTUwiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnAu UHJlZm9ybWF0dGF0b0hUTUwsIGxpLlByZWZvcm1hdHRhdG9IVE1MLCBkaXYuUHJlZm9ybWF0dGF0 b0hUTUwNCgl7bXNvLXN0eWxlLW5hbWU6IlByZWZvcm1hdHRhdG8gSFRNTCI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcmVmb3JtYXR0YXRvIEhUTUwgQ2FyYXR0 ZXJlIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6 YmxhY2s7fQ0Kc3Bhbi5UaXRvbG8yQ2FyYXR0ZXJlDQoJe21zby1zdHlsZS1uYW1lOiJUaXRvbG8g MiBDYXJhdHRlcmUiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJU aXRvbG8gMiI7DQoJZm9udC1mYW1pbHk6IkNhbWJyaWEiLCJzZXJpZiI7DQoJY29sb3I6IzRGODFC RDsNCglmb250LXdlaWdodDpib2xkO30NCnAuVGl0b2xvMiwgbGkuVGl0b2xvMiwgZGl2LlRpdG9s bzINCgl7bXNvLXN0eWxlLW5hbWU6IlRpdG9sbyAyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlRpdG9sbyAyIENhcmF0dGVyZSI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHls ZTMxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLmgyDQoJe21zby1zdHlsZS1uYW1l OmgyO30NCnNwYW4uRW1haWxTdHlsZTMzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkVtYWlsU3R5bGUzNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTM1 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjcwLjg1cHQgNTYuN3B0IDU2Ljdw dCA1Ni43cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMTcyMTIwOTA7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjMwODA1NzE1OCAt MTUxMzQzOTI3NCAxMzQ4MDc1NTUgMTM0ODA3NTU3IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3 NTU3IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3O30NCkBsaXN0IGwwOmxldmVsMQ0KCXtt c28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJy aTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDA6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNA0K CXttc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDoz LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5 DQoJe21zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgYmdjb2xvcj13aGl0ZSBs YW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+RGVhciBBdXRob3Jz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3 aW5kb3d0ZXh0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+VGhlIHRlY2huaXF1ZSBJIGFtIHN1Z2dlc3Rpbmcg aXMg4oCcTXVsdGlzdGFnZSBGaWx0ZXJz4oCdIGluIFtFc1ZhMDFdIGFuZCBub3Qg4oCcU2FtcGxl IGFuZCBIb2xk4oCdLiBBcG9sb2dpZXMgZm9yIHRoZSBlcnJvci4gSSBoYXZlIGZpeGVkIHRoZSB0 ZXh0IOKAkyBteSBzdWdnZXN0ZWQgY2hhbmdlcyB3aWxsIGJlIGluIGFuIGFkZGl0aW9uIHRvIHdo YXQgaXMgdGhlcmUgY3VycmVudGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+SSBoYWQgYSBn b29kIGRpc2N1c3Npb24gd2l0aCBKdWVyZ2VuIG9uIHRoaXMgdG9waWMuIEhlIHN1Z2dlc3RlZCB0 aGF0IEkgcmVhY2ggb3V0IHRvIHlvdSBmb2xrcyBhdCB0aGUgZWFybGllc3QuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHU+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjp3aW5kb3d0ZXh0Jz5Qcm9iYWJseSBhIHNlcGFyYXRlIHN1Yi1zZWN0aW9uIGluIHNlY3Rp b24gNiA/Pz88bzpwPjwvbzpwPjwvc3Bhbj48L3U+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOndpbmRvd3RleHQnPkFuIGV4YW1wbGUgaXMg4oCcTXVsdGlzdGFnZSBGaWx0ZXJz 4oCdIFtFc1ZhMDFdLCBvciBzaW1pbGFyIHRlY2huaXF1ZXMsIHRoYXQgdHJ5IHRvIHByZWZlciBs b25nLWxpdmVkIGxhcmdlIHZvbHVtZSBmbG93cyBpbiB0aGUgc2VsZWN0aW9uLiBXaGVuIGEgcGFj a2V0IGFycml2ZXMsIHRoZXNlIHBhY2tldCBzZWxlY3Rpb24gdGVjaG5pcXVlcyBhcmUgYXBwbGll ZCBvbmx5IGlmIGEgZmxvdyByZWNvcmQgZm9yIHRoZSBwYWNrZXQgZG9lcyBub3QgZXhpc3QuIFRo ZXNlIHBhY2tldCBzZWxlY3Rpb24gdGVjaG5pcXVlcyBjb3VsZCBoYXZlIGZhbHNlIHBvc2l0aXZl cyBidXQgbm8gZmFsc2UgbmVnYXRpdmVzOyBpLmUuIGZsb3dzIHdoaWNoIGFyZSBub3QgbG9uZy1s aXZlZCBsYXJnZSBmbG93cyBtYXkgYmUgc2VsZWN0ZWQgYW5kIGxlYXJudCBpbiB0aGUgZmxvdyBj YWNoZS4gVGhlIGZsb3dzIHdoaWNoIGFyZSBub3QgbG9uZy1saXZlZCBsYXJnZSBmbG93cyBhcmUg bGF0ZXIgcHVyZ2VkIGZyb20gdGhlIGZsb3cgY2FjaGUuPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHU+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0 ZXh0Jz5TdWdnZXN0ZWQgY2hhbmdlcyB0byBTZWN0aW9uIDc8bzpwPjwvbzpwPjwvc3Bhbj48L3U+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPkZvciB0ZWNo bmlxdWVzIHNpbWlsYXIgdG8g4oCcTXVsdGlzdGFnZSBGaWx0ZXJz4oCdLCB0aGUgdHdvIHBhcmFt ZXRlcnMgLS0gdGhlIG9ic2VydmF0aW9uIGludGVydmFsLCBhbmQgdGhlIG1pbmltdW0gYmFuZHdp ZHRoIHRocmVzaG9sZCBvdmVyIHRoYXQgb2JzZXJ2YXRpb24gaW50ZXJ2YWwgLS0gc2hvdWxkIGJl IHByb2dyYW1tYWJsZSBpbiBhIG5ldHdvcmtpbmcgZGV2aWNlIHRvIGZhY2lsaXRhdGUgaGFuZGxp bmcgb2YgZGlmZmVyZW50IHVzZSBjYXNlcyBhbmQgdHJhZmZpYyBjaGFyYWN0ZXJpc3RpY3MuIDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5k b3d0ZXh0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+RnJvbSBhIGJhbmR3aWR0aCBhbmQgdGltZSBkdXJhdGlv biBwZXJzcGVjdGl2ZSwgaW4gb3JkZXIgdG8gaWRlbnRpZnkgbG9uZy1saXZlZCBsYXJnZSBmbG93 cywgd2UgZGVmaW5lIGFuIG9ic2VydmF0aW9uIGludGVydmFsIGFuZCBvYnNlcnZlIHRoZSBiYW5k d2lkdGggb2YgdGhlIGZsb3cgb3ZlciB0aGF0IG9ic2VydmF0aW9uIGludGVydmFsLiBBIGZsb3cg dGhhdCBleGNlZWRzIGEgY2VydGFpbiBtaW5pbXVtIGJhbmR3aWR0aCB0aHJlc2hvbGQgb3ZlciB0 aGF0IG9ic2VydmF0aW9uIGludGVydmFsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPndvdWxkIGJlIGNvbnNpZGVyZWQgYSBs b25nLWxpdmVkIGxhcmdlIGZsb3cuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5Gb3IgZXhhbXBs ZSwgYSBmbG93IHdoaWNoIGlzIGF0IG9yIGFib3ZlIDEwIE1icHMgZm9yIGEgdGltZSBwZXJpb2Qg b2YgYXQgbGVhc3QgMzAgc2Vjb25kcyBjb3VsZCBiZSBkZWNsYXJlZCBhIGxvbmctbGl2ZWQgbGFy Z2UgZmxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6d2luZG93dGV4dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48dT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPlN1Z2dlc3RlZCBjaGFuZ2VzIHRv IFNlY3Rpb24gOCBhbmQgU2VjdGlvbiA5PG86cD48L286cD48L3NwYW4+PC91PjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5UaGUgcGFyYW1ldGVycyBkZXNj cmliZWQgaW4gc2VjdGlvbiA3PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5UaGUgcGFyYW1ldGVy cyBJIGRlc2NyaWJlZCBhYm92ZSBhcmUgY2FwdHVyZWQgaW4gc2VjdGlvbnMgMi4xLjIvNi4xIG9m IHRoZSBkcmFmdCBiZWxvdy4gT3RoZXIgZGV0YWlscyBhcmUgYWxzbyBjYXB0dXJlZCBpbiB0aGUg ZHJhZnQgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOndpbmRvd3RleHQnPjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQta3Jpc2huYW4taXBmaXgtZmxvdy1hd2FyZS1wYWNrZXQtc2FtcGxpbmcvP2lu Y2x1ZGVfdGV4dD0xIj48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4dCc+aHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rcmlzaG5hbi1pcGZpeC1mbG93LWF3YXJlLXBhY2tl dC1zYW1wbGluZy8/aW5jbHVkZV90ZXh0PTE8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93 dGV4dCc+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5SYW1raTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5k b3d0ZXh0Jz4gPGEgaHJlZj0ibWFpbHRvOmlwZml4LWJvdW5jZXNAaWV0Zi5vcmciPmlwZml4LWJv dW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86aXBmaXgtYm91bmNlc0BpZXRmLm9y ZyI+bWFpbHRvOmlwZml4LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YgPC9i PnJhbWtpIEtyaXNobmFuPGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDI0LCAyMDEz IDg6MTMgQU08YnI+PGI+VG86PC9iPiBTYWx2YXRvcmUgRCdBbnRvbmlvOyA8YSBocmVmPSJtYWls dG86dGFuamFAY2FpZGEub3JnIj50YW5qYUBjYWlkYS5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86 bG9yZW56by5wZWx1c29AdW5pbmEuaXQiPmxvcmVuem8ucGVsdXNvQHVuaW5hLml0PC9hPjxicj48 Yj5DYzo8L2I+IElQRklYIFdvcmtpbmcgR3JvdXA8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbSVBG SVhdIFI6IFI6IExhc3QgQ2FsbCBFeHBpcmVkOiAmbHQ7ZHJhZnQtaWV0Zi1pcGZpeC1mbG93LXNl bGVjdGlvbi10ZWNoLTE0LnR4dCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPkRlYXIgQXV0aG9ycyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOndp bmRvd3RleHQnPkkgaGFkIGEgZ29vZCBkaXNjdXNzaW9uIHdpdGggSnVlcmdlbiBvbiB0aGlzIHRv cGljLiBIZSBzdWdnZXN0ZWQgdGhhdCBJIHJlYWNoIG91dCB0byB5b3UgZm9sa3MuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHU+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjp3aW5kb3d0ZXh0Jz5TdWdnZXN0ZWQgY2hhbmdlcyB0byBTZWN0aW9uIDYuNDxvOnA+ PC9vOnA+PC9zcGFuPjwvdT48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6d2lu ZG93dGV4dCc+QW4gZXhhbXBsZSBpcyB0aGUgJm5ic3A7JnF1b3Q7U2FtcGxlIGFuZCBIb2xkJnF1 b3Q7IGFsZ29yaXRobSBbRXNWYTAxXSwgb3Igc2ltaWxhciB0ZWNobmlxdWVzLCB0aGF0IHRyeSB0 byBwcmVmZXIgbG9uZy1saXZlZCBsYXJnZSB2b2x1bWUgZmxvd3MgaW4gdGhlIHNlbGVjdGlvbi4g V2hlbiBhIHBhY2tldCBhcnJpdmVzLCB0aGVzZSBwYWNrZXQgc2VsZWN0aW9uIHRlY2huaXF1ZXMg YXJlIGFwcGxpZWQgb25seSBpZiBhIGZsb3cgcmVjb3JkIGZvciB0aGUgcGFja2V0IGRvZXMgbm90 IGV4aXN0LiBUaGVzZSBwYWNrZXQgc2VsZWN0aW9uIHRlY2huaXF1ZXMgY291bGQgaGF2ZSBmYWxz ZSBwb3NpdGl2ZXMgYnV0IG5vIGZhbHNlIG5lZ2F0aXZlczsgaS5lLiBmbG93cyB3aGljaCBhcmUg bm90IGxvbmctbGl2ZWQgbGFyZ2UgZmxvd3MgbWF5IGJlIHNlbGVjdGVkIGFuZCBsZWFybnQgaW4g dGhlIGZsb3cgY2FjaGUuIFRoZSBmbG93cyB3aGljaCBhcmUgbm90IGxvbmctbGl2ZWQgbGFyZ2Ug Zmxvd3MgYXJlIGxhdGVyIHB1cmdlZCBmcm9tIHRoZSBmbG93IGNhY2hlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjx1PjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6d2luZG93dGV4dCc+U3VnZ2VzdGVkIGNoYW5nZXMgdG8gU2VjdGlvbiA3LjI8bzpwPjwvbzpw Pjwvc3Bhbj48L3U+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3Rl eHQnPkZvciB0ZWNobmlxdWVzIHNpbWlsYXIgdG8g4oCcU2FtcGxlIGFuZCBIb2xk4oCdLCB0aGUg dHdvIHBhcmFtZXRlcnMgLS0gdGhlIG9ic2VydmF0aW9uIGludGVydmFsLCBhbmQgdGhlIG1pbmlt dW0gYmFuZHdpZHRoIHRocmVzaG9sZCBvdmVyIHRoYXQgb2JzZXJ2YXRpb24gaW50ZXJ2YWwgLS0g c2hvdWxkIGJlIHByb2dyYW1tYWJsZSBpbiBhIG5ldHdvcmtpbmcgZGV2aWNlIHRvIGZhY2lsaXRh dGUgaGFuZGxpbmcgb2YgZGlmZmVyZW50IHVzZSBjYXNlcyBhbmQgdHJhZmZpYyBjaGFyYWN0ZXJp c3RpY3MuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+RnJvbSBhIGJhbmR3aWR0aCBhbmQgdGlt ZSBkdXJhdGlvbiBwZXJzcGVjdGl2ZSwgaW4gb3JkZXIgdG8gaWRlbnRpZnkgbG9uZy1saXZlZCBs YXJnZSBmbG93cywgd2UgZGVmaW5lIGFuIG9ic2VydmF0aW9uIGludGVydmFsIGFuZCBvYnNlcnZl IHRoZSBiYW5kd2lkdGggb2YgdGhlIGZsb3cgb3ZlciB0aGF0IG9ic2VydmF0aW9uIGludGVydmFs LiBBIGZsb3cgdGhhdCBleGNlZWRzIGEgY2VydGFpbiBtaW5pbXVtIGJhbmR3aWR0aCB0aHJlc2hv bGQgb3ZlciB0aGF0IG9ic2VydmF0aW9uIGludGVydmFsPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPndvdWxkIGJlIGNvbnNp ZGVyZWQgYSBsb25nLWxpdmVkIGxhcmdlIGZsb3cuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5G b3IgZXhhbXBsZSwgYSBmbG93IHdoaWNoIGlzIGF0IG9yIGFib3ZlIDEwIE1icHMgZm9yIGEgdGlt ZSBwZXJpb2Qgb2YgYXQgbGVhc3QgMzAgc2Vjb25kcyBjb3VsZCBiZSBkZWNsYXJlZCBhIGxvbmct bGl2ZWQgbGFyZ2UgZmxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48dT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPlN1Z2dlc3RlZCBj aGFuZ2VzIHRvIFNlY3Rpb24gOCBhbmQgU2VjdGlvbiA5PG86cD48L286cD48L3NwYW4+PC91Pjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5UaGUgcGFyYW1l dGVycyBkZXNjcmliZWQgaW4gc2VjdGlvbiA3LjIuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+ VGhlIHBhcmFtZXRlcnMgSSBkZXNjcmliZWQgYWJvdmUgYXJlIGNhcHR1cmVkIGluIHNlY3Rpb24g Mi4xLjIgb2YgdGhlIGRyYWZ0IGJlbG93LiBPdGhlciBkZXRhaWxzIGFyZSBhbHNvIGNhcHR1cmVk IGluIHRoZSBkcmFmdCBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1rcmlzaG5hbi1pcGZpeC1mbG93LWF3YXJlLXBhY2tldC1zYW1w bGluZy8/aW5jbHVkZV90ZXh0PTEiPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0Jz5odHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtyaXNobmFuLWlwZml4LWZsb3ctYXdh cmUtcGFja2V0LXNhbXBsaW5nLz9pbmNsdWRlX3RleHQ9MTwvc3Bhbj48L2E+PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjp3aW5kb3d0ZXh0Jz5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPlJhbSAoYWthIFJhbWtpKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3Jt YWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29s b3I6d2luZG93dGV4dCc+IDxhIGhyZWY9Im1haWx0bzppcGZpeC1ib3VuY2VzQGlldGYub3JnIj5p cGZpeC1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmlwZml4LWJvdW5jZXNA aWV0Zi5vcmciPm1haWx0bzppcGZpeC1ib3VuY2VzQGlldGYub3JnPC9hPl0gPGI+T24gQmVoYWxm IE9mIDwvYj5TYWx2YXRvcmUgRCdBbnRvbmlvPGJyPjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgQXBy aWwgMjAsIDIwMTMgNTowNiBQTTxicj48Yj5Ubzo8L2I+ICdCZW5vaXQgQ2xhaXNlJzxicj48Yj5D Yzo8L2I+ICdJRVRGIGRpc2N1c3Npb24gbGlzdCc7IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRm LWlwZml4LWZsb3ctc2VsZWN0aW9uLXRlY2hAdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtaXBm aXgtZmxvdy1zZWxlY3Rpb24tdGVjaEB0b29scy5pZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0 bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmciPmFwcHMtZGlzY3Vzc0BpZXRmLm9yZzwvYT47ICdHZW5l cmFsIEFyZWEgUmV2aWV3IFRlYW0nOyAnUyBNb29uZXNhbXknOyA8YSBocmVmPSJtYWlsdG86aXBm aXgtY2hhaXJzQHRvb2xzLmlldGYub3JnIj5pcGZpeC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+ OyA8YSBocmVmPSJtYWlsdG86aXBmaXhAaWV0Zi5vcmciPmlwZml4QGlldGYub3JnPC9hPjsgPGEg aHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciPmllc2dAaWV0Zi5vcmc8L2E+OyAnSm9lbCBNLiBI YWxwZXJuJzsgJ0EuIEplYW4gTWFob25leSc8YnI+PGI+U3ViamVjdDo8L2I+IFtJUEZJWF0gUjog UjogTGFzdCBDYWxsIEV4cGlyZWQ6ICZsdDtkcmFmdC1pZXRmLWlwZml4LWZsb3ctc2VsZWN0aW9u LXRlY2gtMTQudHh0Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5EZWFyIEJlbm9pdCwgYWxsPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBzdWJtaXR0ZWQgdjE2IG9mIHRoZSBJbnRl cm5ldCBEcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIG1v ZGlmaWVkIHNlY3Rpb24gOS4xLjEgb24gdGhlIG1haW50ZW5hbmNlIG9mIHRoZSBmbG93U2VsZWN0 b3JBbGdvcml0aG0gcmVnaXN0cnkgYW5kIGZpeGVkIHRoZSBlZGl0b3JpYWwgaXNzdWUgaW4gc2Vj dGlvbiAmbmJzcDs2LjEuMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PkkgaGF2ZSBhbHNvIHVzZWQgTVVTVCBpbiBzZWN0aW9uIDYuMTxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1HQiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t R0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5TYWx2YXRvcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxl PSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9SVQgc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIiwic2Fucy1zZXJpZiI7Y29s b3I6d2luZG93dGV4dCc+RGE6PC9zcGFuPjwvYj48c3BhbiBsYW5nPUlUIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRv d3RleHQnPiBCZW5vaXQgQ2xhaXNlIFs8YSBocmVmPSJtYWlsdG86YmNsYWlzZUBjaXNjby5jb20i Pm1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbTwvYT5dIDxicj48Yj5JbnZpYXRvOjwvYj4gbHVuZWTD rCAxNSBhcHJpbGUgMjAxMyAxMTo0Mzxicj48Yj5BOjwvYj4gU2FsdmF0b3JlIEQnQW50b25pbzxi cj48Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWlwZml4LWZsb3ctc2VsZWN0 aW9uLXRlY2hAdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtaXBmaXgtZmxvdy1zZWxlY3Rpb24t dGVjaEB0b29scy5pZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzppcGZpeC1jaGFpcnNAdG9v bHMuaWV0Zi5vcmciPmlwZml4LWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT47ICdTIE1vb25lc2Ft eSc7IDxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmciPmFwcHMtZGlzY3Vzc0Bp ZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYub3JnIj5pZXNnQGlldGYub3Jn PC9hPjsgJ0pvZWwgTS4gSGFscGVybic7ICdBLiBKZWFuIE1haG9uZXknOyAnR2VuZXJhbCBBcmVh IFJldmlldyBUZWFtJzsgJ0lFVEYgZGlzY3Vzc2lvbiBsaXN0JzsgPGEgaHJlZj0ibWFpbHRvOnJh aHVscEBjaXNjby5jb20iPnJhaHVscEBjaXNjby5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86aXBm aXhAaWV0Zi5vcmciPmlwZml4QGlldGYub3JnPC9hPjxicj48Yj5PZ2dldHRvOjwvYj4gUmU6IFI6 IExhc3QgQ2FsbCBFeHBpcmVkOiAmbHQ7ZHJhZnQtaWV0Zi1pcGZpeC1mbG93LXNlbGVjdGlvbi10 ZWNoLTE0LnR4dCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0I+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0I+U2FsdmF0b3JlPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQnPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+RGVhciBhbGwsPC9zcGFuPjxzcGFuIGxhbmc9RU4tR0I+PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9RU4tR0I+PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ QSBuZXcgdmVyc2lvbiBvZiB0aGUgSW50ZXJuZXQgRHJhZnQgb24gRmxvdyBTZWxlY3Rpb24gVGVj aG5pcXVlcyBoYXMgYmVlbiBzdWJtaXR0ZWQuIEl0IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgY2hh bmdlczo8L3NwYW4+PHNwYW4gbGFuZz1FTi1HQj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omww IGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPUVOLUdCIHN0eWxl PSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48c3BhbiBzdHlsZT0nbXNvLWxp c3Q6SWdub3JlJz4tPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPkEgbmV3IHNlY3Rpb24gaWxsdXN0cmF0aW5nIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gSW50 ZXJtZWRpYXRlIEZsb3cgU2VsZWN0aW9uIFByb2Nlc3MgYW5kIEludGVybWVkaWF0ZSBTZWxlY3Rp b24gUHJvY2VzcyBoYXMgYmVlbiBhZGRlZCw8L3NwYW4+PHNwYW4gbGFuZz1FTi1HQj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Jz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4tPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQg IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFu Zz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBzZW50ZW5jZSAmcXVvdDtJbiBvcmRlciB0byBi ZSBjb21wbGlhbnQgd2l0aCB0aGlzIGRvY3VtZW50LCBhdCBsZWFzdCB0aGUgUHJvcGVydHkgJm5i c3A7TWF0Y2ggRmlsdGVyaW5nIE1VU1QgYmUgaW1wbGVtZW50ZWQuJnF1b3Q7IGhhcyBiZWVuIHJl bW92ZWQgaW4gU2VjdGlvbiAxLDwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxh bmc9RU4tR0Igc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxzcGFu IHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMg TmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPUVOLUdC IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+4oCcTVVTVOKAnSBoYXMgYmVlbiByZXBsYWNlZCB3aXRoIOKAnFNI T1VMROKAnSBpbiBTZWN0aW9uIDUuMSw8L3NwYW4+PHNwYW4gbGFuZz1FTi1HQj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9ibG9ja3F1b3RlPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO LUdCPkFjdHVhbGx5LCB0aGUgZmVlZGJhY2sgd2FzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBsYW5nPUVO LUdCPkluIFNlY3Rpb24gMTogPGJyPjxicj4mbmJzcDsgJnF1b3Q7SW4gb3JkZXIgdG8gYmUgY29t cGxpYW50IHdpdGggdGhpcyBkb2N1bWVudCwgYXQgbGVhc3QgdGhlIFByb3BlcnR5IDxicj4mbmJz cDsmbmJzcDsgTWF0Y2ggRmlsdGVyaW5nIE1VU1QgYmUgaW1wbGVtZW50ZWQuJnF1b3Q7IDxicj48 YnI+VGhlIGFib3ZlIHRleHQgaXMgcmVwZWF0ZWQgaW4gU2VjdGlvbiA1LjEuJm5ic3A7IEkgc3Vn Z2VzdCByZW1vdmluZyB0aGlzIHNlbnRlbmNlIGFzIGl0IGRvZXMgbm90IHNlZW0gcmVsYXRlZCB0 byBzY29wZS4gPGJyPjxicj5NeSByZWFkaW5nIG9mIHRoZSAmcXVvdDtNVVNUJnF1b3Q7IGlzIHRo YXQgaXQgaXMgYmVpbmcgdXNlZCBmb3IgY29tcGxpYW5jZSBpbnN0ZWFkIG9mIHRoZSByZWFzb25z IGRlc2NyaWJlZCBpbiBSRkMgMjExOS4mbmJzcDsgSSBzdWdnZXN0IHJldmlld2luZyB0aGUgdXNh Z2Ugb2YgUkZDIDIxMTkga2V5IHdvcmRzIGluIFNlY3Rpb24gNS4xLiA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0I+U28gdGhlIHNvbHV0aW9u IGlzIG5vdCB0byBjaGFuZ2UgTVVTVCB0byBTSE9VTEQuPGJyPlRoZSBxdWVzdGlvbiBpcyB3aGV0 aGVyICZxdW90O01VU1QmcXVvdDsgdmVyc3VzICZxdW90O211c3QmcXVvdDsgbXVzdCBiZSB1c2Vk Ljxicj5JIHVuZGVyc3RhbmQgdGhlIGNvbmNlcm4uIEZvciBjb21wbGlhbmNlIHJlYXNvbiB3aXRo IHRoZSBQU0FNUCBSRkMgNTQ3NSAod2hpY2ggaXMgY2xvc2VseSByZWxhdGVkKSAuLi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PGgyPjxhIG5hbWU9c2VjdGlvbi03PjwvYT48c3BhbiBsYW5nPUVOLUdC PjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU0NzUjc2VjdGlvbi03Ij48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Nzwvc3Bhbj48L2E+PC9zcGFu PjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPi4mbmJz cDsgUGFyYW1ldGVycyBmb3IgdGhlIERlc2NyaXB0aW9uIG9mIFNlbGVjdGlvbiBUZWNobmlxdWVz PG86cD48L286cD48L3NwYW4+PC9oMj48cHJlPjxzcGFuIGxhbmc9RU4tR0I+Jm5ic3A7Jm5ic3A7 IFRoaXMgc2VjdGlvbiBnaXZlcyBhbiBvdmVydmlldyBvZiBkaWZmZXJlbnQgYWx0ZXJuYXRpdmUg c2VsZWN0aW9uPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBsYW5nPUVOLUdCPiZu YnNwOyZuYnNwOyBzY2hlbWVzIGFuZCB0aGVpciByZXF1aXJlZCBwYXJhbWV0ZXJzLiZuYnNwOyBJ biBvcmRlciB0byBiZSBjb21wbGlhbnQgd2l0aDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+ PHNwYW4gbGFuZz1FTi1HQj4mbmJzcDsmbmJzcDsgUFNBTVAsIGF0IGxlYXN0IG9uZSBvZiBwcm9w b3NlZCBzY2hlbWVzIE1VU1QgYmUgaW1wbGVtZW50ZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+ PHByZT48c3BhbiBsYW5nPUVOLUdCPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCPi4uLiBJIHdvdWxkIGtlZXAgdGhlIGluaXRp YWwgJnF1b3Q7TVVTVCZxdW90OyBmcm9tIHRoZSBwcmV2aW91cyBkcmFmdCB2ZXJzaW9uLiA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCc+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4tPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4w cHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g bGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPuKAnFRoZSBmbG93U2VsZWN0b3JBbGdvcml0aG0g cmVnaXN0cnkgaXMgbWFpbnRhaW5lZCBieSBJQU5BLiZxdW90OyBoYXMgYmVlbiByZXBsYWNlZCB3 aXRoIOKAnElBTkEgaXMgcmVxdWVzdGVkIHRvIGNyZWF0ZSB0aGUgZmxvd1NlbGVjdG9yQWxnb3Jp dGhtIHJlZ2lzdHJ5LuKAnTwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9 RU4tR0Igc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxzcGFuIHN0 eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3 IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPUVOLUdCIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+VGhlIHNlbnRlbmNlICZxdW90O1RoZSByZWdpc3RyeSBjYW4gYmUgdXBk YXRlZCB3aGVuIHNwZWNpZmljYXRpb25zIG9mIHRoZSBuZXcmbmJzcDsgdGVjaG5pcXVlKHMpIGFu ZCBhbnkgbmV3IEluZm9ybWF0aW9uIEVsZW1lbnRzIGFyZSBwcm92aWRlZC4mcXVvdDsgaGFzIGJl ZW4gcmVtb3ZlZCBzaW5jZSBpdCBkaWQgbm90IGNsYXJpZnkgaG93IHRoZSByZWdpc3RyeSB3aWxs IGJlIG1hbmFnZWQuPC9zcGFuPjxzcGFuIGxhbmc9RU4tR0I+PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz1FTi1H QiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PHNwYW4gc3R5bGU9 J21zby1saXN0Oklnbm9yZSc+LTxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9t YW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz4mbmJzcDtTZWN0aW9uIDYuMS4xIOKAnFByb3BlcnR5IE1hdGNoIEZpbHRlcmlu Z+KAnSBoYXMgYmVlbiBjaGFuZ2VkIGJ5IGFkZGluZyBzb21lIHRleHQgb24gaG93IFByb3BlcnR5 IE1hdGNoIEZpbHRlcmluZyBjYW4gYmUgJm5ic3A7dXNlZCBieSBhbiBJbnRlcm1lZGlhdGUgRmxv dyBTZWxlY3Rpb24gUHJvY2VzcyBpbiB0aGUgTWV0ZXJpbmcgUHJvY2VzcywgaW4gdGhlICZuYnNw O0V4cG9ydGluZyBQcm9jZXNzIGFuZCB3aXRoaW4gYW4gSVBGSVggTWVkaWF0b3IuPC9zcGFuPjxz cGFuIGxhbmc9RU4tR0I+PG86cD48L286cD48L3NwYW4+PC9wPjwvYmxvY2txdW90ZT48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBsYW5nPUVOLUdC PldoZW4gcHVibGlzaGluZyBhIG5ldyB2ZXJzaW9uLCBwbGVhc2UgY29ycmVjdCB0aGlzIGVkaXRv cmlhbCBpc3N1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHByZT48c3BhbiBsYW5nPUVOLUdCPiZu YnNwOyZxdW90OyAuLi4gYW5kIEZsb3cgZHVyYXRpb24uIGluPG86cD48L286cD48L3NwYW4+PC9w cmU+PHByZT48c3BhbiBsYW5nPUVOLUdCPiZuYnNwOyZuYnNwOyB0aGUgQW4gZXhhbXBsZSBpcyB0 aGUgc2VsZWN0aW9uIG9mIHRoZSBsYXJnZXN0IC4uLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFu IGxhbmc9RU4tR0I+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9RU4tR0I+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QmVzdCByZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5n PUVOLUdCPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPlNhbHZhdG9yZTwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+ PHNwYW4gbGFuZz1JVCBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+RGE6PC9zcGFuPjwvYj48c3Bh biBsYW5nPUlUIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4gQmVub2l0IENsYWlzZSBbPGEgaHJl Zj0ibWFpbHRvOmJjbGFpc2VAY2lzY28uY29tIj5tYWlsdG86YmNsYWlzZUBjaXNjby5jb208L2E+ XSA8YnI+PGI+SW52aWF0bzo8L2I+IGx1bmVkw6wgOCBhcHJpbGUgMjAxMyAxNToyMTxicj48Yj5B OjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtaXBmaXgtZmxvdy1zZWxlY3Rpb24tdGVj aEB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1pcGZpeC1mbG93LXNlbGVjdGlvbi10ZWNoQHRv b2xzLmlldGYub3JnPC9hPjxicj48Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzppcGZpeC1jaGFp cnNAdG9vbHMuaWV0Zi5vcmciPmlwZml4LWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT48YnI+PGI+ T2dnZXR0bzo8L2I+IEZ3ZDogTGFzdCBDYWxsIEV4cGlyZWQ6ICZsdDtkcmFmdC1pZXRmLWlwZml4 LWZsb3ctc2VsZWN0aW9uLXRlY2gtMTQudHh0Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1HQj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9RU4tR0I+RGVhciBhdXRob3JzLDxicj48YnI+VGhlIElFVEYgbGFzdCBjYWxs IGhhcyBmaW5pc2hlZC48YnI+Q2FuIHlvdSBwbGVhc2UgdXBkYXRlIHlvdXIgZHJhZnQgYmFzZWQg b24gdGhlIGZlZWRiYWNrIHJlY2VpdmVkLjxicj5UaGVuIEkgd2lsbCBwcm9ncmVzcyBpdC48YnI+ PGJyPlJlZ2FyZHMsIEJlbm9pdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLUdCPjxicj48YnI+LS0tLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLS0tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHRhYmxlIGNsYXNzPU1zb05vcm1hbFRh YmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MD48dHI+PHRkIG5vd3JhcCB2 YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9y bWFsIGFsaWduPXJpZ2h0IHN0eWxlPSd0ZXh0LWFsaWduOnJpZ2h0Jz48Yj5TdWJqZWN0OiA8L2I+ PG86cD48L286cD48L3A+PC90ZD48dGQgc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48 cCBjbGFzcz1Nc29Ob3JtYWw+TGFzdCBDYWxsIEV4cGlyZWQ6ICZsdDtkcmFmdC1pZXRmLWlwZml4 LWZsb3ctc2VsZWN0aW9uLXRlY2gtMTQudHh0Jmd0OzxvOnA+PC9vOnA+PC9wPjwvdGQ+PC90cj48 dHI+PHRkIG5vd3JhcCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+ PHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPXJpZ2h0IHN0eWxlPSd0ZXh0LWFsaWduOnJpZ2h0Jz48 Yj5EYXRlOiA8L2I+PG86cD48L286cD48L3A+PC90ZD48dGQgc3R5bGU9J3BhZGRpbmc6MGluIDBp biAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+TW9uLCAwMSBBcHIgMjAxMyAwMDoyODo0NiAt MDcwMDxvOnA+PC9vOnA+PC9wPjwvdGQ+PC90cj48dHI+PHRkIG5vd3JhcCB2YWxpZ249dG9wIHN0 eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPXJp Z2h0IHN0eWxlPSd0ZXh0LWFsaWduOnJpZ2h0Jz48Yj5Gcm9tOiA8L2I+PG86cD48L286cD48L3A+ PC90ZD48dGQgc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3Jt YWw+RHJhZnRUcmFja2VyIE1haWwgU3lzdGVtIDxhIGhyZWY9Im1haWx0bzppZXNnLXNlY3JldGFy eUBpZXRmLm9yZyI+Jmx0O2llc2ctc2VjcmV0YXJ5QGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpw PjwvcD48L3RkPjwvdHI+PHRyPjx0ZCBub3dyYXAgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzow aW4gMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1yaWdodCBzdHlsZT0ndGV4 dC1hbGlnbjpyaWdodCc+PGI+VG86IDwvYj48bzpwPjwvbzpwPjwvcD48L3RkPjx0ZCBzdHlsZT0n cGFkZGluZzowaW4gMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48YSBocmVmPSJtYWls dG86aWVzZ0BpZXRmLm9yZyI+aWVzZ0BpZXRmLm9yZzwvYT4sIDxhIGhyZWY9Im1haWx0bzppcGZp eC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPmlwZml4LWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT4s IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWlwZml4LWZsb3ctc2VsZWN0aW9uLXRlY2hAdG9v bHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtaXBmaXgtZmxvdy1zZWxlY3Rpb24tdGVjaEB0b29scy5p ZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD48L3RkPjwvdHI+PHRyPjx0ZCBub3dyYXAgdmFsaWdu PXRvcCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbCBh bGlnbj1yaWdodCBzdHlsZT0ndGV4dC1hbGlnbjpyaWdodCc+PGI+Q0M6IDwvYj48bzpwPjwvbzpw PjwvcD48L3RkPjx0ZCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1z b05vcm1hbD48YSBocmVmPSJtYWlsdG86aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmciPmllc2ctc2Vj cmV0YXJ5QGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPjwvdGQ+PC90cj48L3RhYmxlPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIGxhbmc9RU4t R0I+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwcmU+PHNwYW4gbGFuZz1FTi1HQj5QbGVh c2UgRE8gTk9UIHJlcGx5IHRvIHRoaXMgZW1haWwuPG86cD48L286cD48L3NwYW4+PC9wcmU+PHBy ZT48c3BhbiBsYW5nPUVOLUdCPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNw YW4gbGFuZz1FTi1HQj5JLUQ6ICZsdDtkcmFmdC1pZXRmLWlwZml4LWZsb3ctc2VsZWN0aW9uLXRl Y2gtMTQudHh0Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz1FTi1H Qj5JRCBUcmFja2VyIFVSTDogPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWlwZml4LWZsb3ctc2VsZWN0aW9uLXRlY2gvIj5odHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaXBmaXgtZmxvdy1zZWxlY3Rpb24tdGVjaC88L2E+ PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBsYW5nPUVOLUdCPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz1FTi1HQj5JRVRGIExhc3QgQ2FsbCBo YXMgZW5kZWQsIGFuZCB0aGUgc3RhdGUgaGFzIGJlZW4gY2hhbmdlZCB0bzxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz1FTi1HQj5XYWl0aW5nIGZvciBBRCBHby1BaGVhZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIGxhbmc9RU4tR0I+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBsYW5nPUVOLUdCPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz1FTi1HQj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0I+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNl bnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuIGxhbmc9RU4tR0I+PGhyIHNpemU9 MSB3aWR0aD0iMTAwJSIgbm9zaGFkZSBzdHlsZT0nY29sb3I6I0EwQTBBMCcgYWxpZ249Y2VudGVy Pjwvc3Bhbj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLUdCPk5lc3N1 biB2aXJ1cyBuZWwgbWVzc2FnZ2lvLjxicj5Db250cm9sbGF0byBkYSBBVkcgLSA8YSBocmVmPSJo dHRwOi8vd3d3LmF2Zy5jb20iPnd3dy5hdmcuY29tPC9hPjxicj5WZXJzaW9uZTogMjAxMy4wLjMy NzIgLyBEYXRhYmFzZSBkZWkgdmlydXM6IDMxNjIvNjIzMSAtIERhdGEgZGkgcmlsYXNjaW86IDA3 LzA0LzIwMTM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt YXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gbGFuZz1FTi1HQj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9d2VzdGVybiBzdHlsZT0nbWFyZ2luLWJvdHRvbTowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Jz48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIic+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKjwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz13ZXN0ZXJuIHN0eWxlPSdtYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQnPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiJz5JTCBNRVJJVE8gREVHTEkgU1RVREVOVEkmbmJzcDtWSUVORSBSSUNPTk9TQ0lVVE88L3Nw YW4+PHNwYW4gbGFuZz1FTi1HQj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9d2VzdGVy biBzdHlsZT0nbWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBs YW5nPUVOLUdCPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz13ZXN0ZXJuIHN0 eWxlPSdtYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIGxhbmc9 RU4tR0Igc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5JbCA1IHBlciBt aWxsZSBhbGwnVW5pdmVyc2l0w6AgZGVnbGkgU3R1ZGkgZGkgTmFwb2xpICZxdW90O1BhcnRoZW5v cGUmcXVvdDtpbmNyZW1lbnRhIGxlIGJvcnNlIGRpIHN0dWRpbyBhZ2xpIHN0dWRlbnRpIC0gY29k aWNlIGZpc2NhbGUgPGI+ODAwMTgyNDA2MzI8L2I+IDwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz13ZXN0ZXJuIHN0eWxlPSdtYXJnaW4tYm90dG9t OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIGxhbmc9RU4tR0I+PGEgaHJlZj0iaHR0 cDovL3d3dy51bmlwYXJ0aGVub3BlLml0L2luZGV4LnBocC81eG1pbGxlIj48c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPmh0dHA6Ly93d3cudW5pcGFydGhlbm9w ZS5pdC9pbmRleC5waHAvNXhtaWxsZTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9RU4tR0Ig c3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz1FTi1HQj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9d2VzdGVybiBzdHls ZT0nbWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBsYW5nPUVO LUdCPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz13ZXN0ZXJuIHN0eWxlPSdt YXJnaW4tYm90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIGxhbmc9RU4tR0I+ PGEgaHJlZj0iaHR0cDovL3d3dy51bmlwYXJ0aGVub3BlLml0L2luZGV4LnBocC9pdC9hdnZpc2kt c2l0by1kaS1hdGVuZW8vMjk0My1sYS1wYXJ0aGVub3BlLXByZW1pYS1pbC10dW8tdm90by1kaS1k aXBsb21hLWVkLWlsLXR1by1pbWVnbm8tY29uLWktcHJvdmVudGktZGVsLTUtcGVyLW1pbGxlIj48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPmh0dHA6Ly93d3cu dW5pcGFydGhlbm9wZS5pdC9pbmRleC5waHAvaXQvYXZ2aXNpLXNpdG8tZGktYXRlbmVvLzI5NDMt bGEtcGFydGhlbm9wZS1wcmVtaWEtaWwtdHVvLXZvdG8tZGktZGlwbG9tYS1lZC1pbC10dW8taW1l Z25vLWNvbi1pLXByb3ZlbnRpLWRlbC01LXBlci1taWxsZTwvc3Bhbj48L2E+PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPXdlc3Rlcm4gc3R5bGU9J21hcmdpbi1ib3R0b206MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCc+PHNwYW4gbGFuZz1FTi1HQj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz1FTi1HQiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxicj5RdWVz dGEgaW5mb3JtYXRpdmEgw6ggaW5zZXJpdGEgaW4gYXV0b21hdGljbyBkYWwgc2lzdGVtYSBhbCBm aW5lIGVzY2x1c2l2byBkZWxsYSByZWFsaXp6YXppb25lIGRlaSBmaW5pIGlzdGl0dXppb25hbGkg ZGVsbCdlbnRlLjwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz13ZXN0ZXJuIHN0eWxlPSdtYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQnPjxzcGFuIGxhbmc9RU4tR0I+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIGxhbmc9RU4t R0I+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPXdlc3Rlcm4gc3R5bGU9J21h cmdpbi1ib3R0b206MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gbGFuZz1FTi1HQiBz dHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L3NwYW4+PHNwYW4gbGFuZz1FTi1HQj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9d2VzdGVybiBzdHlsZT0nbWFyZ2luLWJvdHRvbTow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+SUwgTUVSSVRPIERFR0xJIFNUVURFTlRJJm5ic3A7 VklFTkUgUklDT05PU0NJVVRPPC9zcGFuPjxzcGFuIGxhbmc9RU4tR0I+PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPXdlc3Rlcm4gc3R5bGU9J21hcmdpbi1ib3R0b206MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCc+PHNwYW4gbGFuZz1FTi1HQj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9d2VzdGVybiBzdHlsZT0nbWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0Jz48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIic+SWwgNSBwZXIgbWlsbGUgYWxsJ1VuaXZlcnNpdMOgIGRlZ2xpIFN0dWRpIGRp IE5hcG9saSAmcXVvdDtQYXJ0aGVub3BlJnF1b3Q7aW5jcmVtZW50YSBsZSBib3JzZSBkaSBzdHVk aW8gYWdsaSBzdHVkZW50aSAtIGNvZGljZSBmaXNjYWxlIDxiPjgwMDE4MjQwNjMyPC9iPiA8L3Nw YW4+PHNwYW4gbGFuZz1FTi1HQj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9d2VzdGVy biBzdHlsZT0nbWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBs YW5nPUVOLUdCPjxhIGhyZWY9Imh0dHA6Ly93d3cudW5pcGFydGhlbm9wZS5pdC9pbmRleC5waHAv NXhtaWxsZSI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5o dHRwOi8vd3d3LnVuaXBhcnRoZW5vcGUuaXQvaW5kZXgucGhwLzV4bWlsbGU8L3NwYW4+PC9hPjwv c3Bhbj48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIic+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9RU4tR0I+PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPXdlc3Rlcm4gc3R5bGU9J21hcmdpbi1ib3R0b206MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCc+PHNwYW4gbGFuZz1FTi1HQj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9d2VzdGVybiBzdHlsZT0nbWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0Jz48c3BhbiBsYW5nPUVOLUdCPjxhIGhyZWY9Imh0dHA6Ly93d3cudW5pcGFydGhlbm9wZS5p dC9pbmRleC5waHAvaXQvYXZ2aXNpLXNpdG8tZGktYXRlbmVvLzI5NDMtbGEtcGFydGhlbm9wZS1w cmVtaWEtaWwtdHVvLXZvdG8tZGktZGlwbG9tYS1lZC1pbC10dW8taW1lZ25vLWNvbi1pLXByb3Zl bnRpLWRlbC01LXBlci1taWxsZSI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiJz5odHRwOi8vd3d3LnVuaXBhcnRoZW5vcGUuaXQvaW5kZXgucGhwL2l0L2F2dmlz aS1zaXRvLWRpLWF0ZW5lby8yOTQzLWxhLXBhcnRoZW5vcGUtcHJlbWlhLWlsLXR1by12b3RvLWRp LWRpcGxvbWEtZWQtaWwtdHVvLWltZWduby1jb24taS1wcm92ZW50aS1kZWwtNS1wZXItbWlsbGU8 L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz13ZXN0ZXJuIHN0eWxlPSdt YXJnaW4tYm90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIGxhbmc9RU4tR0I+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiJz48YnI+UXVlc3RhIGluZm9ybWF0aXZhIMOoIGluc2VyaXRhIGluIGF1dG9t YXRpY28gZGFsIHNpc3RlbWEgYWwgZmluZSBlc2NsdXNpdm8gZGVsbGEgcmVhbGl6emF6aW9uZSBk ZWkgZmluaSBpc3RpdHV6aW9uYWxpIGRlbGwnZW50ZS48L3NwYW4+PHNwYW4gbGFuZz1FTi1HQj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9d2VzdGVybiBzdHlsZT0nbWFyZ2luLWJvdHRv bTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBsYW5nPUVOLUdCPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t R0I+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2NvbG9yOndpbmRv d3RleHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz13ZXN0ZXJuIHN0eWxl PSdtYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIGxhbmc9RU4t R0Igc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4qKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPC9zcGFuPjxzcGFuIGxhbmc9RU4tR0I+ PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPXdlc3Rlcm4gc3R5bGU9J21hcmdpbi1ib3R0 b206MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPklMIE1FUklUTyBERUdMSSBTVFVERU5USSZu YnNwO1ZJRU5FIFJJQ09OT1NDSVVUTzwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz13ZXN0ZXJuIHN0eWxlPSdtYXJnaW4tYm90dG9tOjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIGxhbmc9RU4tR0I+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPXdlc3Rlcm4gc3R5bGU9J21hcmdpbi1ib3R0b206MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCc+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiInPklsIDUgcGVyIG1pbGxlIGFsbCdVbml2ZXJzaXTDoCBkZWdsaSBTdHVk aSBkaSBOYXBvbGkgJnF1b3Q7UGFydGhlbm9wZSZxdW90O2luY3JlbWVudGEgbGUgYm9yc2UgZGkg c3R1ZGlvIGFnbGkgc3R1ZGVudGkgLSBjb2RpY2UgZmlzY2FsZSA8Yj44MDAxODI0MDYzMjwvYj4g PC9zcGFuPjxzcGFuIGxhbmc9RU4tR0I+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPXdl c3Rlcm4gc3R5bGU9J21hcmdpbi1ib3R0b206MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNw YW4gbGFuZz1FTi1HQj48YSBocmVmPSJodHRwOi8vd3d3LnVuaXBhcnRoZW5vcGUuaXQvaW5kZXgu cGhwLzV4bWlsbGUiPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Iic+aHR0cDovL3d3dy51bmlwYXJ0aGVub3BlLml0L2luZGV4LnBocC81eG1pbGxlPC9zcGFuPjwv YT48L3NwYW4+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiInPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz13ZXN0ZXJuIHN0eWxlPSdtYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQnPjxzcGFuIGxhbmc9RU4tR0I+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPXdlc3Rlcm4gc3R5bGU9J21hcmdpbi1ib3R0b206MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCc+PHNwYW4gbGFuZz1FTi1HQj48YSBocmVmPSJodHRwOi8vd3d3LnVuaXBhcnRoZW5v cGUuaXQvaW5kZXgucGhwL2l0L2F2dmlzaS1zaXRvLWRpLWF0ZW5lby8yOTQzLWxhLXBhcnRoZW5v cGUtcHJlbWlhLWlsLXR1by12b3RvLWRpLWRpcGxvbWEtZWQtaWwtdHVvLWltZWduby1jb24taS1w cm92ZW50aS1kZWwtNS1wZXItbWlsbGUiPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+aHR0cDovL3d3dy51bmlwYXJ0aGVub3BlLml0L2luZGV4LnBocC9pdC9h dnZpc2ktc2l0by1kaS1hdGVuZW8vMjk0My1sYS1wYXJ0aGVub3BlLXByZW1pYS1pbC10dW8tdm90 by1kaS1kaXBsb21hLWVkLWlsLXR1by1pbWVnbm8tY29uLWktcHJvdmVudGktZGVsLTUtcGVyLW1p bGxlPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9d2VzdGVybiBzdHls ZT0nbWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBsYW5nPUVO LUdCPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIic+PGJyPlF1ZXN0YSBpbmZvcm1hdGl2YSDDqCBpbnNlcml0YSBpbiBh dXRvbWF0aWNvIGRhbCBzaXN0ZW1hIGFsIGZpbmUgZXNjbHVzaXZvIGRlbGxhIHJlYWxpenphemlv bmUgZGVpIGZpbmkgaXN0aXR1emlvbmFsaSBkZWxsJ2VudGUuPC9zcGFuPjxzcGFuIGxhbmc9RU4t R0I+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPXdlc3Rlcm4gc3R5bGU9J21hcmdpbi1i b3R0b206MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gbGFuZz1FTi1HQj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Ig c3R5bGU9J2NvbG9yOndpbmRvd3RleHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0n Y29sb3I6d2luZG93dGV4dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPXdl c3Rlcm4gc3R5bGU9J21hcmdpbi1ib3R0b206MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4qKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPXdlc3Rlcm4gc3R5bGU9J21hcmdpbi1ib3R0b206MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5JTCBN RVJJVE8gREVHTEkgU1RVREVOVEkmbmJzcDtWSUVORSBSSUNPTk9TQ0lVVE88L3NwYW4+PG86cD48 L286cD48L3A+PHAgY2xhc3M9d2VzdGVybiBzdHlsZT0nbWFyZ2luLWJvdHRvbTowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz13ZXN0ZXJuIHN0 eWxlPSdtYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxl PSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+SWwgNSBwZXIgbWlsbGUgYWxsJ1Vu aXZlcnNpdMOgIGRlZ2xpIFN0dWRpIGRpIE5hcG9saSAmcXVvdDtQYXJ0aGVub3BlJnF1b3Q7aW5j cmVtZW50YSBsZSBib3JzZSBkaSBzdHVkaW8gYWdsaSBzdHVkZW50aSAtIGNvZGljZSBmaXNjYWxl IDxiPjgwMDE4MjQwNjMyPC9iPiA8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9d2VzdGVy biBzdHlsZT0nbWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48YSBocmVm PSJodHRwOi8vd3d3LnVuaXBhcnRoZW5vcGUuaXQvaW5kZXgucGhwLzV4bWlsbGUiPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+aHR0cDovL3d3dy51bmlwYXJ0 aGVub3BlLml0L2luZGV4LnBocC81eG1pbGxlPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz13ZXN0ZXJuIHN0eWxlPSdtYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXdlc3Rlcm4gc3R5bGU9J21hcmdp bi1ib3R0b206MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PGEgaHJlZj0iaHR0cDovL3d3dy51 bmlwYXJ0aGVub3BlLml0L2luZGV4LnBocC9pdC9hdnZpc2ktc2l0by1kaS1hdGVuZW8vMjk0My1s YS1wYXJ0aGVub3BlLXByZW1pYS1pbC10dW8tdm90by1kaS1kaXBsb21hLWVkLWlsLXR1by1pbWVn bm8tY29uLWktcHJvdmVudGktZGVsLTUtcGVyLW1pbGxlIj48c3BhbiBzdHlsZT0nZm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPmh0dHA6Ly93d3cudW5pcGFydGhlbm9wZS5pdC9pbmRl eC5waHAvaXQvYXZ2aXNpLXNpdG8tZGktYXRlbmVvLzI5NDMtbGEtcGFydGhlbm9wZS1wcmVtaWEt aWwtdHVvLXZvdG8tZGktZGlwbG9tYS1lZC1pbC10dW8taW1lZ25vLWNvbi1pLXByb3ZlbnRpLWRl bC01LXBlci1taWxsZTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+PHAgY2xhc3M9d2VzdGVybiBz dHlsZT0nbWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz4mbmJzcDs8c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxicj5RdWVzdGEgaW5m b3JtYXRpdmEgw6ggaW5zZXJpdGEgaW4gYXV0b21hdGljbyBkYWwgc2lzdGVtYSBhbCBmaW5lIGVz Y2x1c2l2byBkZWxsYSByZWFsaXp6YXppb25lIGRlaSBmaW5pIGlzdGl0dXppb25hbGkgZGVsbCdl bnRlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz13ZXN0ZXJuIHN0eWxlPSdtYXJnaW4t Ym90dG9tOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4dCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_C7634EB63EFD984A978DFB46EA5174F2BFD824EFD2HQ1EXCH01corp_-- From johnsonhammond2@hushmail.com Sat Apr 27 09:49:13 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E23721F96D4 for ; Sat, 27 Apr 2013 09:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyTmKPSepKg1 for ; Sat, 27 Apr 2013 09:49:13 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3C821F96CD for ; Sat, 27 Apr 2013 09:49:13 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id CA37DE7C28 for ; Sat, 27 Apr 2013 16:49:12 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp2.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 16:49:12 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 87F7214DBDE; Sat, 27 Apr 2013 16:49:12 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 12:49:12 -0400 To: ipfix@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427164912.87F7214DBDE@smtp.hushmail.com> Subject: [IPFIX] Biggest Fake Conference in Computer Science X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 18:26:05 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From n.brownlee@auckland.ac.nz Sun Apr 28 19:10:08 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F60F21F8ADC for ; Sun, 28 Apr 2013 19:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eteAeWXjuVn0 for ; Sun, 28 Apr 2013 19:10:06 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id F045221F86EB for ; Sun, 28 Apr 2013 19:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1367201406; x=1398737406; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=eXyWVkuWKq8e/MFeiWwk8NWXo4CoSPOESkOub+aVW0c=; b=X8eMd6FGJ9CJUmIqTKjBXO+/KFz5jYZvQ9bR9kjKXSlLQZhK8f+c/WJp xj5j1c4yzlNhLgbk2VLPavBDzI/BVU9a3Xaa/dDD6Tcx7FfVhHXHDfQNL dDWFnZtjO6BOzRHkakZp7ssbAQ/PpMybgDNLf/r8i1v99bXj52JRJSu82 w=; X-IronPort-AV: E=Sophos;i="4.87,570,1363086000"; d="scan'208";a="183527431" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 29 Apr 2013 14:10:03 +1200 Message-ID: <517DD67A.4000100@auckland.ac.nz> Date: Mon, 29 Apr 2013 14:10:02 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ramki Krishnan References: <20130401072846.32360.9502.idtracker@ietfa.amsl.com> <5162C44B.5030904@cisco.com> <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it> <516BCB97.9040404@cisco.com> <001001ce3e24$0a931840$1fb948c0$@dantonio@uniparthenope.it> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "lorenzo.peluso@unina.it" , "tanja@caida.org" , IPFIX Working Group Subject: Re: [IPFIX] R: R: Last Call Expired: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 02:10:08 -0000 Hi Ramki et al: The IETF Last Call for this draft finished on 8 April 13, it's been revised following feedback since then. It already has short sections about flow-dependent packet selection, including a reference to [EsVa01] Estan, C. and G,. Varghese, "New Directions in Traffic Measurement and Accounting: Focusing on the Elephants, Ignoring the Mice", ACM SIGCOMM Internet Measurement Workshop 2001, San Francisco (CA), November 2001 I regard that as the seminal paper for this particular topic; it was followed in 2004 by a SIGCOMM paper, "Building a better NetFlow" by Estan, Keys, Moore and Varghese. At this point I'd like to see this draft carried through its IESG consideration without the distraction (and delay) brought on by attempting to define parameters for flow-dependent selection in the draft at this very late stage. Better to continue discussion on the list so as to reach a firm consensus on them. When we have that, they could be easily added as requests to IANA for Information Elements. Again, I note that an IPR has been declared for draft-krishnan-opsawg-large-flow-load-balancing-07. That draft seems to cover much the same material as that in draft-krishnan-ipfix-flow-aware-packet-sampling but there's no IPR declared (so far) for the -ipfix- draft. Can you comment on that, please? Cheers, Nevil (IPFIX co-chair) On 25/04/13 2:02 PM, ramki Krishnan wrote: > Dear Authors, > > The technique I am suggesting is Multistage Filters in [EsVa01] and not Sample and Hold. Apologies for the error. I have fixed the text my suggested changes will be in an addition to what is there currently. > > I had a good discussion with Juergen on this topic. He suggested that I reach out to you folks at the earliest. > > Probably a separate sub-section in section 6 ??? > An example is Multistage Filters [EsVa01], or similar techniques, that try to prefer long-lived large volume flows in the selection. When a packet arrives, these packet selection techniques are applied only if a flow record for the packet does not exist. These packet selection techniques could have false positives but no false negatives; i.e. flows which are not long-lived large flows may be selected and learnt in the flow cache. The flows which are not long-lived large flows are later purged from the flow cache. > > Suggested changes to Section 7 > For techniques similar to Multistage Filters, the two parameters -- the observation interval, and the minimum bandwidth threshold over that observation interval -- should be programmable in a networking device to facilitate handling of different use cases and traffic characteristics. > > From a bandwidth and time duration perspective, in order to identify long-lived large flows, we define an observation interval and observe the bandwidth of the flow over that observation interval. A flow that exceeds a certain minimum bandwidth threshold over that observation interval > would be considered a long-lived large flow. > > For example, a flow which is at or above 10 Mbps for a time period of at least 30 seconds could be declared a long-lived large flow. > > Suggested changes to Section 8 and Section 9 > The parameters described in section 7 > > The parameters I described above are captured in sections 2.1.2/6.1 of the draft below. Other details are also captured in the draft below. > http://datatracker.ietf.org/doc/draft-krishnan-ipfix-flow-aware-packet-sampling/?include_text=1 > > Thanks, > Ramki > > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of ramki Krishnan > Sent: Wednesday, April 24, 2013 8:13 AM > To: Salvatore D'Antonio; tanja@caida.org; lorenzo.peluso@unina.it > Cc: IPFIX Working Group > Subject: Re: [IPFIX] R: R: Last Call Expired: > > Dear Authors, > > I had a good discussion with Juergen on this topic. He suggested that I reach out to you folks. > > Suggested changes to Section 6.4 > An example is the "Sample and Hold" algorithm [EsVa01], or similar techniques, that try to prefer long-lived large volume flows in the selection. When a packet arrives, these packet selection techniques are applied only if a flow record for the packet does not exist. These packet selection techniques could have false positives but no false negatives; i.e. flows which are not long-lived large flows may be selected and learnt in the flow cache. The flows which are not long-lived large flows are later purged from the flow cache. > > Suggested changes to Section 7.2 > For techniques similar to Sample and Hold, the two parameters -- the observation interval, and the minimum bandwidth threshold over that observation interval -- should be programmable in a networking device to facilitate handling of different use cases and traffic characteristics. > > From a bandwidth and time duration perspective, in order to identify long-lived large flows, we define an observation interval and observe the bandwidth of the flow over that observation interval. A flow that exceeds a certain minimum bandwidth threshold over that observation interval > would be considered a long-lived large flow. > > For example, a flow which is at or above 10 Mbps for a time period of at least 30 seconds could be declared a long-lived large flow. > > Suggested changes to Section 8 and Section 9 > The parameters described in section 7.2. > > The parameters I described above are captured in section 2.1.2 of the draft below. Other details are also captured in the draft below. > http://datatracker.ietf.org/doc/draft-krishnan-ipfix-flow-aware-packet-sampling/?include_text=1 > > Thanks, > Ram (aka Ramki) > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of Salvatore D'Antonio > Sent: Saturday, April 20, 2013 5:06 PM > To: 'Benoit Claise' > Cc: 'IETF discussion list'; draft-ietf-ipfix-flow-selection-tech@tools.ietf.org; apps-discuss@ietf.org; 'General Area Review Team'; 'S Moonesamy'; ipfix-chairs@tools.ietf.org; ipfix@ietf.org; iesg@ietf.org; 'Joel M. Halpern'; 'A. Jean Mahoney' > Subject: [IPFIX] R: R: Last Call Expired: > > Dear Benoit, all > > I submitted v16 of the Internet Draft. > > I modified section 9.1.1 on the maintenance of the flowSelectorAlgorithm registry and fixed the editorial issue in section 6.1.1 > > I have also used MUST in section 6.1 > > Best regards, > > Salvatore > > > Da: Benoit Claise [mailto:bclaise@cisco.com] > Inviato: luned 15 aprile 2013 11:43 > A: Salvatore D'Antonio > Cc: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org; ipfix-chairs@tools.ietf.org; 'S Moonesamy'; apps-discuss@ietf.org; iesg@ietf.org; 'Joel M. Halpern'; 'A. Jean Mahoney'; 'General Area Review Team'; 'IETF discussion list'; rahulp@cisco.com; ipfix@ietf.org > Oggetto: Re: R: Last Call Expired: > > Salvatore > Dear all, > > A new version of the Internet Draft on Flow Selection Techniques has been submitted. It contains the following changes: > > - A new section illustrating the difference between Intermediate Flow Selection Process and Intermediate Selection Process has been added, > > - The sentence "In order to be compliant with this document, at least the Property Match Filtering MUST be implemented." has been removed in Section 1, > > - MUST has been replaced with SHOULD in Section 5.1, > Actually, the feedback was: > In Section 1: > > "In order to be compliant with this document, at least the Property > Match Filtering MUST be implemented." > > The above text is repeated in Section 5.1. I suggest removing this sentence as it does not seem related to scope. > > My reading of the "MUST" is that it is being used for compliance instead of the reasons described in RFC 2119. I suggest reviewing the usage of RFC 2119 key words in Section 5.1. > So the solution is not to change MUST to SHOULD. > The question is whether "MUST" versus "must" must be used. > I understand the concern. For compliance reason with the PSAMP RFC 5475 (which is closely related) ... > 7. Parameters for the Description of Selection Techniques > > This section gives an overview of different alternative selection > > schemes and their required parameters. In order to be compliant with > > PSAMP, at least one of proposed schemes MUST be implemented. > > > ... I would keep the initial "MUST" from the previous draft version. > > - The flowSelectorAlgorithm registry is maintained by IANA." has been replaced with IANA is requested to create the flowSelectorAlgorithm registry. > > - The sentence "The registry can be updated when specifications of the new technique(s) and any new Information Elements are provided." has been removed since it did not clarify how the registry will be managed. > > - Section 6.1.1 Property Match Filtering has been changed by adding some text on how Property Match Filtering can be used by an Intermediate Flow Selection Process in the Metering Process, in the Exporting Process and within an IPFIX Mediator. > When publishing a new version, please correct this editorial issue. > > " ... and Flow duration. in > > the An example is the selection of the largest ..." > > > Best regards, > > Salvatore > > Da: Benoit Claise [mailto:bclaise@cisco.com] > Inviato: luned 8 aprile 2013 15:21 > A: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org > Cc: ipfix-chairs@tools.ietf.org > Oggetto: Fwd: Last Call Expired: > > Dear authors, > > The IETF last call has finished. > Can you please update your draft based on the feedback received. > Then I will progress it. > > Regards, Benoit > > > -------- Original Message -------- > Subject: > > Last Call Expired: > > Date: > > Mon, 01 Apr 2013 00:28:46 -0700 > > From: > > DraftTracker Mail System > > To: > > iesg@ietf.org, ipfix-chairs@tools.ietf.org, draft-ietf-ipfix-flow-selection-tech@tools.ietf.org > > CC: > > iesg-secretary@ietf.org > > > > Please DO NOT reply to this email. > > > > I-D: > > ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ > > > > IETF Last Call has ended, and the state has been changed to > > Waiting for AD Go-Ahead. > > > > > > > > > ________________________________ > Nessun virus nel messaggio. > Controllato da AVG - www.avg.com > Versione: 2013.0.3272 / Database dei virus: 3162/6231 - Data di rilascio: 07/04/2013 > > > ******************************************************************************************************* > > IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO > > > > Il 5 per mille all'Universit degli Studi di Napoli "Parthenope"incrementa le borse di studio agli studenti - codice fiscale 80018240632 > > http://www.uniparthenope.it/index.php/5xmille > > > > http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille > > > Questa informativa inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente. > > > > > ******************************************************************************************************* > > IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO > > > > Il 5 per mille all'Universit degli Studi di Napoli "Parthenope"incrementa le borse di studio agli studenti - codice fiscale 80018240632 > > http://www.uniparthenope.it/index.php/5xmille > > > > http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille > > > Questa informativa inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente. > > > > > > > ******************************************************************************************************* > > IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO > > > > Il 5 per mille all'Universit degli Studi di Napoli "Parthenope"incrementa le borse di studio agli studenti - codice fiscale 80018240632 > > http://www.uniparthenope.it/index.php/5xmille > > > > http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille > > > Questa informativa inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente. > > > > > > ******************************************************************************************************* > > IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO > > > > Il 5 per mille all'Universit degli Studi di Napoli "Parthenope"incrementa le borse di studio agli studenti - codice fiscale 80018240632 > > http://www.uniparthenope.it/index.php/5xmille > > > > http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille > > > Questa informativa inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente. > > > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From ramk@Brocade.com Sun Apr 28 21:15:23 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C1121F9832 for ; Sun, 28 Apr 2013 21:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.666 X-Spam-Level: X-Spam-Status: No, score=-0.666 tagged_above=-999 required=5 tests=[IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxOnLEXKqNto for ; Sun, 28 Apr 2013 21:15:22 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0B23221F9820 for ; Sun, 28 Apr 2013 21:15:21 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r3T4CELv013590; Sun, 28 Apr 2013 21:15:15 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1c1a2ur4s9-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 28 Apr 2013 21:15:15 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sun, 28 Apr 2013 21:15:14 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::8c73:93bf:41b4:1443]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Sun, 28 Apr 2013 21:15:14 -0700 From: ramki Krishnan To: Nevil Brownlee Date: Sun, 28 Apr 2013 21:15:11 -0700 Thread-Topic: [IPFIX] R: R: Last Call Expired: Thread-Index: Ac5EfqwkwMK0UG6uQ/+WkfP12+pAvAAEGWAg Message-ID: References: <20130401072846.32360.9502.idtracker@ietfa.amsl.com> <5162C44B.5030904@cisco.com> <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it> <516BCB97.9040404@cisco.com> <001001ce3e24$0a931840$1fb948c0$@dantonio@uniparthenope.it> <517DD67A.4000100@auckland.ac.nz> In-Reply-To: <517DD67A.4000100@auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-29_02:2013-04-28, 2013-04-29, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1304280349 Cc: Ning So , "lorenzo.peluso@unina.it" , "tanja@caida.org" , IPFIX Working Group Subject: Re: [IPFIX] R: R: Last Call Expired: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 04:15:23 -0000 Hi Nevil, Thanks for the response, I will follow up separately on this item. After further discussions in OPSAWG, all IPR related material has been remo= ved from "draft-krishnan-opsawg-large-flow-load-balancing". The latest draf= t, version 8, reflects this. The IPR update, which will happen in the next = couple of days, will reflect this. I have also made sure that all IPR related material has been removed from d= raft-krishnan-ipfix-flow-aware-packet-sampling. Thanks, Ramki -----Original Message----- From: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] Sent: Sunday, April 28, 2013 7:10 PM To: ramki Krishnan Cc: Salvatore D'Antonio; tanja@caida.org; lorenzo.peluso@unina.it; IPFIX Wo= rking Group Subject: Re: [IPFIX] R: R: Last Call Expired: Hi Ramki et al: The IETF Last Call for this draft finished on 8 April 13, it's been revised= following feedback since then. It already has short sections about flow-dependent packet selection, includ= ing a reference to [EsVa01] Estan, C. and G,. Varghese, "New Directions in Traffic Measurement and Accounting: Focusing on the Elephants, Ignoring the Mice", ACM SIGCOMM Internet Measurement Workshop 2001, San Francisco (CA), November 2001 I regard th= at as the seminal paper for this particular topic; it was followed in 2004 = by a SIGCOMM paper, "Building a better NetFlow" by Estan, Keys, Moore and V= arghese. At this point I'd like to see this draft carried through its IESG considera= tion without the distraction (and delay) brought on by attempting to define= parameters for flow-dependent selection in the draft at this very late sta= ge. Better to continue discussion on the list so as to reach a firm consen= sus on them. When we have that, they could be easily added as requests to = IANA for Information Elements. Again, I note that an IPR has been declared for draft-krishnan-opsawg-large-flow-load-balancing-07. That draft seems to cover much the same material as that in draft-krishnan-ipfix-flow-aware-packet-sampling but there's no IPR declared (so far) for the -ipfix- draft. Can you comment on that, please? Cheers, Nevil (IPFIX co-chair) On 25/04/13 2:02 PM, ramki Krishnan wrote: > Dear Authors, > > The technique I am suggesting is "Multistage Filters" in [EsVa01] and not= "Sample and Hold". Apologies for the error. I have fixed the text - my sug= gested changes will be in an addition to what is there currently. > > I had a good discussion with Juergen on this topic. He suggested that I r= each out to you folks at the earliest. > > Probably a separate sub-section in section 6 ??? > An example is "Multistage Filters" [EsVa01], or similar techniques, that = try to prefer long-lived large volume flows in the selection. When a packet= arrives, these packet selection techniques are applied only if a flow reco= rd for the packet does not exist. These packet selection techniques could h= ave false positives but no false negatives; i.e. flows which are not long-l= ived large flows may be selected and learnt in the flow cache. The flows wh= ich are not long-lived large flows are later purged from the flow cache. > > Suggested changes to Section 7 > For techniques similar to "Multistage Filters", the two parameters -- the= observation interval, and the minimum bandwidth threshold over that observ= ation interval -- should be programmable in a networking device to facilita= te handling of different use cases and traffic characteristics. > > From a bandwidth and time duration perspective, in order to identify > long-lived large flows, we define an observation interval and observe the= bandwidth of the flow over that observation interval. A flow that exceeds = a certain minimum bandwidth threshold over that observation interval would = be considered a long-lived large flow. > > For example, a flow which is at or above 10 Mbps for a time period of at = least 30 seconds could be declared a long-lived large flow. > > Suggested changes to Section 8 and Section 9 The parameters described > in section 7 > > The parameters I described above are captured in sections 2.1.2/6.1 of th= e draft below. Other details are also captured in the draft below. > http://datatracker.ietf.org/doc/draft-krishnan-ipfix-flow-aware-packet > -sampling/?include_text=3D1 > > Thanks, > Ramki > > From: ipfix-bounces@ietf.org > [mailto:ipfix-bounces@ietf.org] On Behalf Of ramki Krishnan > Sent: Wednesday, April 24, 2013 8:13 AM > To: Salvatore D'Antonio; tanja@caida.org; > lorenzo.peluso@unina.it > Cc: IPFIX Working Group > Subject: Re: [IPFIX] R: R: Last Call Expired: > > > Dear Authors, > > I had a good discussion with Juergen on this topic. He suggested that I r= each out to you folks. > > Suggested changes to Section 6.4 > An example is the "Sample and Hold" algorithm [EsVa01], or similar techn= iques, that try to prefer long-lived large volume flows in the selection. W= hen a packet arrives, these packet selection techniques are applied only if= a flow record for the packet does not exist. These packet selection techni= ques could have false positives but no false negatives; i.e. flows which ar= e not long-lived large flows may be selected and learnt in the flow cache. = The flows which are not long-lived large flows are later purged from the fl= ow cache. > > Suggested changes to Section 7.2 > For techniques similar to "Sample and Hold", the two parameters -- the ob= servation interval, and the minimum bandwidth threshold over that observati= on interval -- should be programmable in a networking device to facilitate = handling of different use cases and traffic characteristics. > > From a bandwidth and time duration perspective, in order to identify > long-lived large flows, we define an observation interval and observe the= bandwidth of the flow over that observation interval. A flow that exceeds = a certain minimum bandwidth threshold over that observation interval would = be considered a long-lived large flow. > > For example, a flow which is at or above 10 Mbps for a time period of at = least 30 seconds could be declared a long-lived large flow. > > Suggested changes to Section 8 and Section 9 The parameters described > in section 7.2. > > The parameters I described above are captured in section 2.1.2 of the dra= ft below. Other details are also captured in the draft below. > http://datatracker.ietf.org/doc/draft-krishnan-ipfix-flow-aware-packet > -sampling/?include_text=3D1 > > Thanks, > Ram (aka Ramki) > From: ipfix-bounces@ietf.org > [mailto:ipfix-bounces@ietf.org] On Behalf Of Salvatore D'Antonio > Sent: Saturday, April 20, 2013 5:06 PM > To: 'Benoit Claise' > Cc: 'IETF discussion list'; draft-ietf-ipfix-flow-selection-tech@tools.ie= tf.org; apps-di= scuss@ietf.org; 'General Area Review Team'; '= S Moonesamy'; ipfix-chairs@tools.ietf.org; ipfix@ietf.org; iesg@ietf.org; 'Joel M. Halpern'; 'A. Jean Mahoney' > Subject: [IPFIX] R: R: Last Call Expired: > > > Dear Benoit, all > > I submitted v16 of the Internet Draft. > > I modified section 9.1.1 on the maintenance of the > flowSelectorAlgorithm registry and fixed the editorial issue in > section 6.1.1 > > I have also used MUST in section 6.1 > > Best regards, > > Salvatore > > > Da: Benoit Claise [mailto:bclaise@cisco.com] > Inviato: luned=EC 15 aprile 2013 11:43 > A: Salvatore D'Antonio > Cc: > draft-ietf-ipfix-flow-selection-tech@tools.ietf.org ipfix-flow-selection-tech@tools.ietf.org>; > ipfix-chairs@tools.ietf.org; 'S > Moonesamy'; apps-discuss@ietf.org; > iesg@ietf.org; 'Joel M. Halpern'; 'A. Jean > Mahoney'; 'General Area Review Team'; 'IETF discussion list'; > rahulp@cisco.com; > ipfix@ietf.org > Oggetto: Re: R: Last Call Expired: > > > Salvatore > Dear all, > > A new version of the Internet Draft on Flow Selection Techniques has been= submitted. It contains the following changes: > > - A new section illustrating the difference between Intermediate= Flow Selection Process and Intermediate Selection Process has been added, > > - The sentence "In order to be compliant with this document, at = least the Property Match Filtering MUST be implemented." has been removed = in Section 1, > > - "MUST" has been replaced with "SHOULD" in Section 5.1, > Actually, the feedback was: > In Section 1: > > "In order to be compliant with this document, at least the Property > Match Filtering MUST be implemented." > > The above text is repeated in Section 5.1. I suggest removing this sente= nce as it does not seem related to scope. > > My reading of the "MUST" is that it is being used for compliance instead = of the reasons described in RFC 2119. I suggest reviewing the usage of RFC= 2119 key words in Section 5.1. > So the solution is not to change MUST to SHOULD. > The question is whether "MUST" versus "must" must be used. > I understand the concern. For compliance reason with the PSAMP RFC 5475 (= which is closely related) ... > 7. Parameters for the > Description of Selection Techniques > > This section gives an overview of different alternative selection > > schemes and their required parameters. In order to be compliant > with > > PSAMP, at least one of proposed schemes MUST be implemented. > > > ... I would keep the initial "MUST" from the previous draft version. > > - "The flowSelectorAlgorithm registry is maintained by IANA." ha= s been replaced with "IANA is requested to create the flowSelectorAlgorithm= registry." > > - The sentence "The registry can be updated when specifications = of the new technique(s) and any new Information Elements are provided." ha= s been removed since it did not clarify how the registry will be managed. > > - Section 6.1.1 "Property Match Filtering" has been changed by = adding some text on how Property Match Filtering can be used by an Interme= diate Flow Selection Process in the Metering Process, in the Exporting Pro= cess and within an IPFIX Mediator. > When publishing a new version, please correct this editorial issue. > > " ... and Flow duration. in > > the An example is the selection of the largest ..." > > > Best regards, > > Salvatore > > Da: Benoit Claise [mailto:bclaise@cisco.com] > Inviato: luned=EC 8 aprile 2013 15:21 > A: > draft-ietf-ipfix-flow-selection-tech@tools.ietf.org ipfix-flow-selection-tech@tools.ietf.org> > Cc: ipfix-chairs@tools.ietf.org > Oggetto: Fwd: Last Call Expired: > > > Dear authors, > > The IETF last call has finished. > Can you please update your draft based on the feedback received. > Then I will progress it. > > Regards, Benoit > > > -------- Original Message -------- > Subject: > > Last Call Expired: > > Date: > > Mon, 01 Apr 2013 00:28:46 -0700 > > From: > > DraftTracker Mail System > > > To: > > iesg@ietf.org, > ipfix-chairs@tools.ietf.org, > draft-ietf-ipfix-flow-selection-tech@tools.ietf.org ipfix-flow-selection-tech@tools.ietf.org> > > CC: > > iesg-secretary@ietf.org > > > > Please DO NOT reply to this email. > > > > I-D: > > ID Tracker URL: > http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ > > > > IETF Last Call has ended, and the state has been changed to > > Waiting for AD Go-Ahead. > > > > > > > > > ________________________________ > Nessun virus nel messaggio. > Controllato da AVG - www.avg.com > Versione: 2013.0.3272 / Database dei virus: 3162/6231 - Data di > rilascio: 07/04/2013 > > > ********************************************************************** > ********************************* > > IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO > > > > Il 5 per mille all'Universit=E0 degli Studi di Napoli > "Parthenope"incrementa le borse di studio agli studenti - codice > fiscale 80018240632 > > http://www.uniparthenope.it/index.php/5xmille > > > > http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la > -parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-prove > nti-del-5-per-mille > > > Questa informativa =E8 inserita in automatico dal sistema al fine esclusi= vo della realizzazione dei fini istituzionali dell'ente. > > > > > ********************************************************************** > ********************************* > > IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO > > > > Il 5 per mille all'Universit=E0 degli Studi di Napoli > "Parthenope"incrementa le borse di studio agli studenti - codice > fiscale 80018240632 > > http://www.uniparthenope.it/index.php/5xmille > > > > http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la > -parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-prove > nti-del-5-per-mille > > > Questa informativa =E8 inserita in automatico dal sistema al fine esclusi= vo della realizzazione dei fini istituzionali dell'ente. > > > > > > > ********************************************************************** > ********************************* > > IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO > > > > Il 5 per mille all'Universit=E0 degli Studi di Napoli > "Parthenope"incrementa le borse di studio agli studenti - codice > fiscale 80018240632 > > http://www.uniparthenope.it/index.php/5xmille > > > > http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la > -parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-prove > nti-del-5-per-mille > > > Questa informativa =E8 inserita in automatico dal sistema al fine esclusi= vo della realizzazione dei fini istituzionali dell'ente. > > > > > > ********************************************************************** > ********************************* > > IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO > > > > Il 5 per mille all'Universit=E0 degli Studi di Napoli > "Parthenope"incrementa le borse di studio agli studenti - codice > fiscale 80018240632 > > http://www.uniparthenope.it/index.php/5xmille > > > > http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la > -parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-prove > nti-del-5-per-mille > > > Questa informativa =E8 inserita in automatico dal sistema al fine esclusi= vo della realizzazione dei fini istituzionali dell'ente. > > > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand